From lnunez@c3isecurity.com Wed Aug 1 08:11:31 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A0E11E810E for ; Wed, 1 Aug 2012 08:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO+SeW9rJKjc for ; Wed, 1 Aug 2012 08:11:30 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF2211E80DC for ; Wed, 1 Aug 2012 08:11:30 -0700 (PDT) Received: by ggnc4 with SMTP id c4so8001427ggn.31 for ; Wed, 01 Aug 2012 08:11:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer:x-gm-message-state; bh=1XJmVGBs/GnywFzUC01vqYiy/5KYitgaJrnO/jAk9oc=; b=JnBkBGw+L22XJE2Yh6OsiJgbNxYh4RIFvmupidWiY1hEh5pSeQriN366nU7xMgXFTQ l1vw9cxBLJpEYRusPySbvoO0cJwp2q9EocyzXDHqe7d4Y8L9Iuk0zvX+IDw9eVsdEWZp 5WWb/ii85MvlEqmsXgIlnwNi8T4Q0502ChExfvGYqL3rUUPliJzojWmKdX5MSZMZM5EW 1qzSXUmYDfC4F7XNhnnPx2ZfPJl9l8989X9ph+vCyedjwlBoIc85W1s79LlwEfdauGRH BySr/Xi1myrDA/wE2HtqZjKjZIL0IIFZOOfXb4T6hltnALWoFb3+lG0vtCpAeoiMt8oo mOJA== Received: by 10.236.177.42 with SMTP id c30mr17089727yhm.37.1343833889761; Wed, 01 Aug 2012 08:11:29 -0700 (PDT) Received: from [192.168.1.32] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id t20sm3033642anl.19.2012.08.01.08.11.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 08:11:28 -0700 (PDT) From: Luis Nunez Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Aug 2012 11:11:28 -0400 Message-Id: To: sacm@ietf.org, mile@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlh7UZmcTVx63U1ACnu82HL5881axVpb0UsJLLvdLfldZ+tNolNkWE/g24M2pl0gqCstAHc Subject: [sacm] VERIS X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 01 Aug 2012 15:11:31 -0000 Anyone familiar with Vocabulary for Event Recording and Incident Sharing = (VERIS)? Is this something that competes with MILE? or does it = complement, cooperate with existing efforts? Information sharing issues are on the rise and I would like to make sure = we are aware of the various efforts under way. We want to as a = community avoid duplication. = http://securityblog.verizonbusiness.com/2012/08/01/announcing-veriscommuni= ty-net/ thanks. -ln= From osantos@cisco.com Wed Aug 1 08:43:39 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8815421F8B38; Wed, 1 Aug 2012 08:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovf8texgGJS8; Wed, 1 Aug 2012 08:43:37 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 52C2621F8B36; Wed, 1 Aug 2012 08:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=osantos@cisco.com; l=10472; q=dns/txt; s=iport; t=1343835817; x=1345045417; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TOhTVkhM9FpsV5s8I3LT87XRbKLCSWngFc6gkm6EgCs=; b=l8efBtreloJMZ/FYmN2d1iEi0YdTNhculf80wm90QfrC1WK6lLwqMU2Q 69b0qxjLyblh8wlrIEzu6naGhGcRa8UpwR5O5YatAMEJjVDTwzWRam+MS JLWMEiwPXOlvwwNrTDGz/dKRuw6VmvsmLXcFXZvfnzRXXiwBln8RMu1UI I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEFAN5NGVCtJXG8/2dsb2JhbAArFwOCSqVeiBMBiFSBB4IgAQEBBBIBGigkDgICAQgHCgQBAQsdBxsXFAkIAgQBDQUIDA6HawspnDGgTwSLRYNogkFgA5FjhHiJcYMigWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,694,1336348800"; d="scan'208,217";a="107458554" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 01 Aug 2012 15:43:36 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q71FhatM003314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Aug 2012 15:43:36 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.33]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 10:43:36 -0500 From: "Omar Santos (osantos)" To: Kyle Maxwell , Luis Nunez Thread-Topic: [mile] VERIS Thread-Index: AQHNb/fxuesp/mqjsEWw3KuN6FC7UJdFZ6CA//+u9NA= Date: Wed, 1 Aug 2012 15:43:34 +0000 Message-ID: <93ED586BE669044CA2F91C5F3BE4FD9017AF76A0@xmb-aln-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.110.37] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19076.006 x-tm-as-result: No--39.601100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_93ED586BE669044CA2F91C5F3BE4FD9017AF76A0xmbalnx09ciscoc_" MIME-Version: 1.0 Cc: "mile@ietf.org" , "sacm@ietf.org" Subject: Re: [sacm] [mile] VERIS X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 01 Aug 2012 15:43:40 -0000 --_000_93ED586BE669044CA2F91C5F3BE4FD9017AF76A0xmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kyle, Thank you! I was going over the documentation (at the link below) and the c= ase studies / other collateral material; and I do see a little overlap with= SACM: http://veriscommunity.net/doku.php If the community is interested, would you mind giving a brief overview of V= ERIS in a few weeks? I can setup a Webex and record the session for those o= f you that cannot make it... Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Kyl= e Maxwell Sent: Wednesday, August 01, 2012 11:25 AM To: Luis Nunez Cc: mile@ietf.org; sacm@ietf.org Subject: Re: [mile] VERIS I'm on the VERIS team here at Verizon, so I can help answer any specific qu= estions you might have. In a general sense, I don't believe VERIS and MILE = really compete but are complementary to each other. On Wed, Aug 1, 2012 at 10:11 AM, Luis Nunez > wrote: Anyone familiar with Vocabulary for Event Recording and Incident Sharing (V= ERIS)? Is this something that competes with MILE? or does it complement, c= ooperate with existing efforts? Information sharing issues are on the rise and I would like to make sure we= are aware of the various efforts under way. We want to as a community avo= id duplication. http://securityblog.verizonbusiness.com/2012/08/01/announcing-veriscommunit= y-net/ -- Kyle Maxwell [kylem@xwell.org] http://www.xwell.org Twitter: @kylemaxwell --_000_93ED586BE669044CA2F91C5F3BE4FD9017AF76A0xmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kyle,

 <= /p>

Thank you! I was going ov= er the documentation (at the link below) and the case studies / other colla= teral material; and I do see a little overlap with SACM:<= /p>

 <= /p>

http:= //veriscommunity.net/doku.php

 <= /p>

If the community is inter= ested, would you mind giving a brief overview of VERIS in a few weeks? I ca= n setup a Webex and record the session for those of you that cannot make it…

 <= /p>

Regards,

 <= /p>

Omar Santos

Incident Manager, PSIRT

Security Research and Ope= rations

Cisco Systems, Inc.<= /o:p>

Email: os@cisco.com<= /o:p>

Phone: +1 919 392 863= 5

PGP Key: 0x3AF27EDC<= /o:p>

 <= /p>

Cisco.com - http://www.ci= sco.com <http://www.cisco.com/>

Cisco Security Advisories= and Notices - http://www.cisco.com/go/psirt

 <= /p>

From: mile-bou= nces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Kyle Maxwell
Sent: Wednesday, August 01, 2012 11:25 AM
To: Luis Nunez
Cc: mile@ietf.org; sacm@ietf.org
Subject: Re: [mile] VERIS

 

I'm on the VERIS team= here at Verizon, so I can help answer any specific questions you might hav= e. In a general sense, I don't believe VERIS and MILE really compete but ar= e complementary to each other. 

On Wed, Aug 1, 2012 at 10:11 AM, Luis Nunez <lnunez@c3isecurity.= com> wrote:

Anyone familiar with Vocabulary for Event Recording = and Incident Sharing (VERIS)?  Is this something that competes with MI= LE? or does it complement, cooperate with existing efforts?

Information sharing issues are on the rise and I would like to make sure we= are aware of the various efforts under way.  We want to as a communit= y avoid duplication.

http://securityblog.verizonbusiness.co= m/2012/08/01/announcing-veriscommunity-net/

--
Kyle Maxwell [kyle= m@xwell.org]
http://www.xwell.org=
Twitter: @kylemaxwell

--_000_93ED586BE669044CA2F91C5F3BE4FD9017AF76A0xmbalnx09ciscoc_-- From lnunez@c3isecurity.com Wed Aug 1 08:45: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 BF3D511E8087 for ; Wed, 1 Aug 2012 08:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.392 X-Spam-Level: X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYZCGYCRNaC3 for ; Wed, 1 Aug 2012 08:45:27 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A92D421F8B36 for ; Wed, 1 Aug 2012 08:45:27 -0700 (PDT) Received: by yhq56 with SMTP id 56so8045313yhq.31 for ; Wed, 01 Aug 2012 08:45:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=MM71n4o6E+5f25kcYBsPYrFvUSdDGzVuq2uDVzEiHF0=; b=fNuajhqXKX3BM7/VqZaUKvN6pflTEajfSylzA26pBP30kvMBTUqV4UO/rks9feqFvd fPY3CMzj8qK7nKVPFWkCP1MSNfhFsrkbCUiEvU6FD1EyVoRJYNqH6oNvxkrnAXCBDaRS A+D11b7n+QEpV/0l55ifUsLnDtrET0XTAeUQWz0wL35mZ6crphsgKc+dliZbfXMNCnzP w3MycG2+ccPn3SuQoSpLaoyGcnGuHSOXJsfrWNX2RDsgmQ7jXhdihz720ylrFEdpLmDf gPp468iM6dVtmKSvuJaOIiYGOLS/E7wKsqQApGEVBfF7aLLmeiWB+s3hqZLtgI8vighK 7Z5w== Received: by 10.101.3.19 with SMTP id f19mr5316082ani.58.1343835927218; Wed, 01 Aug 2012 08:45:27 -0700 (PDT) Received: from [192.168.1.32] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id q17sm117657anm.12.2012.08.01.08.45.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 08:45:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_18E8B76E-1444-42BF-ACD2-0EF5B64F1831" From: Luis Nunez In-Reply-To: Date: Wed, 1 Aug 2012 11:45:22 -0400 Message-Id: <1A341665-F6E2-40F6-9DB0-7ABB62ED3190@c3isecurity.com> References: To: Kyle Maxwell X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlS5JZsIBTKkPlQz+DpEeGNnCsxtfFlNc3knbWa7yXCg4fnwPqB8ex0G2Sxd2XcEwwOh3Vq Cc: mile@ietf.org, sacm@ietf.org Subject: Re: [sacm] [mile] VERIS X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 01 Aug 2012 15:45:29 -0000 --Apple-Mail=_18E8B76E-1444-42BF-ACD2-0EF5B64F1831 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Kyle, thanks for the info and offer to field questions. Maybe at some point = it would worth while to see the connections and relationships of VERIS = and MILE. Some of the things we as a community grapple with is how the = various frameworks/specifications interact and work together. thanks. -ln On Aug 1, 2012, at 11:25 AM, Kyle Maxwell wrote: > I'm on the VERIS team here at Verizon, so I can help answer any = specific questions you might have. In a general sense, I don't believe = VERIS and MILE really compete but are complementary to each other.=20 >=20 > On Wed, Aug 1, 2012 at 10:11 AM, Luis Nunez = wrote: > Anyone familiar with Vocabulary for Event Recording and Incident = Sharing (VERIS)? Is this something that competes with MILE? or does it = complement, cooperate with existing efforts? >=20 > Information sharing issues are on the rise and I would like to make = sure we are aware of the various efforts under way. We want to as a = community avoid duplication. >=20 > = http://securityblog.verizonbusiness.com/2012/08/01/announcing-veriscommuni= ty-net/ >=20 > --=20 > Kyle Maxwell [kylem@xwell.org] > http://www.xwell.org > Twitter: @kylemaxwell >=20 --Apple-Mail=_18E8B76E-1444-42BF-ACD2-0EF5B64F1831 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Hi Kyle,
thanks for the info and offer to field questions.  Maybe at some point it would worth while to see the connections and relationships of VERIS and MILE.  Some of the things we as a community grapple with is how the various frameworks/specifications interact and work together.

thanks.

-ln
On Aug 1, 2012, at 11:25 AM, Kyle Maxwell wrote:

I'm on the VERIS team here at Verizon, so I can help answer any specific questions you might have. In a general sense, I don't believe VERIS and MILE really compete but are complementary to each other. 

On Wed, Aug 1, 2012 at 10:11 AM, Luis Nunez <lnunez@c3isecurity.com> wrote:
Anyone familiar with Vocabulary for Event Recording and Incident Sharing (VERIS)?  Is this something that competes with MILE? or does it complement, cooperate with existing efforts?

Information sharing issues are on the rise and I would like to make sure we are aware of the various efforts under way.  We want to as a community avoid duplication.

http://securityblog.verizonbusiness.com/2012/08/01/announcing-veriscommunity-net/

--
Kyle Maxwell [kylem@xwell.org]
http://www.xwell.org
Twitter: @kylemaxwell


--Apple-Mail=_18E8B76E-1444-42BF-ACD2-0EF5B64F1831-- From kathleen.moriarty@emc.com Wed Aug 1 08:45:39 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D704811E80D7; Wed, 1 Aug 2012 08:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS2WNIE-qHgK; Wed, 1 Aug 2012 08:45:39 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id D04B411E8087; Wed, 1 Aug 2012 08:45:38 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q71FjZhx019632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 11:45:36 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Wed, 1 Aug 2012 11:45:20 -0400 Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q71Fg7Vh012010; Wed, 1 Aug 2012 11:45:18 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub36.corp.emc.com ([::1]) with mapi; Wed, 1 Aug 2012 11:43:21 -0400 From: To: , , Date: Wed, 1 Aug 2012 11:43:21 -0400 Thread-Topic: [sacm] VERIS Thread-Index: Ac1v+AEHmq/saP/lRRWbdnxHU/whoQAAfd3H 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] VERIS X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 01 Aug 2012 15:45:40 -0000 Hi Luis, Veris actually compliments the work in MILE. They have done some really go= od work and would great to see some of their lessons learned benefit the MI= LE work (if/where possible). I think we have a few people on list from Ver= izon following the work. Their input would be very helpful in the update t= o RFC5070 as well as if they think we need to extend to hit other important= use cases. There are a number of complimentary efforts that would be very nice to see = come together so that we could have a consistent way to share and communica= te incident information, learning from all of the hands-on experience. We = hit on this a little yesterday where we need to figure out if we include so= me additional high-level information in IODEF (the example was for malware)= is needed and then we point to more detailed information. We do want to t= arget relevant use cases of data that people share who would be using this = work. Veris may have some other areas that could be very useful. The hurd= le with any proprietary format is the same that we ran into with the MITRE = work, we need to be able to have normative references and be clear on IP co= ncerns. If work is brought into the IETF, that makes it clear and would be= easier to unify the solutions. This will be up to the other organizations= and if they are interested in bringing the work into MILE. We do want to make sure that we map back to use cases as we extend IODEF to= ensure we are creating work that will be useful to the community (share th= e right things). The VERIS work has put a lot of thought into this for the= ir customers as I am sure the other vendor formats have as well. Other related spaces where work has been done include malware (Mandiant's O= penIOC) and forensics (x.dexf from Korea and also work from Google, AFF). = The work from Korea transferred the IP, so we can build on that. Hopefully= , we can help the community by combining efforts using open standards enabl= ing vendors to implement interoperable solutions. Thanks, Kathleen ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Luis Nunez= [lnunez@c3isecurity.com] Sent: Wednesday, August 01, 2012 11:11 AM To: sacm@ietf.org; mile@ietf.org Subject: [sacm] VERIS Anyone familiar with Vocabulary for Event Recording and Incident Sharing (V= ERIS)? Is this something that competes with MILE? or does it complement, c= ooperate with existing efforts? Information sharing issues are on the rise and I would like to make sure we= are aware of the various efforts under way. We want to as a community avo= id duplication. http://securityblog.verizonbusiness.com/2012/08/01/announcing-veriscommunit= y-net/ thanks. -ln _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From kathleen.moriarty@emc.com Wed Aug 1 08:48:10 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B009D11E8091; Wed, 1 Aug 2012 08:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ff-5lj2DTJGG; Wed, 1 Aug 2012 08:48:09 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4B60711E8087; Wed, 1 Aug 2012 08:48:08 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q71Fm0Fq009362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 11:48:03 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 1 Aug 2012 11:47:37 -0400 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q71Flbk3014547; Wed, 1 Aug 2012 11:47:37 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Wed, 1 Aug 2012 11:47:37 -0400 From: To: , Date: Wed, 1 Aug 2012 11:46:29 -0400 Thread-Topic: [mile] VERIS Thread-Index: Ac1v/L6BrnMbNx8ZSgGmxjVn2wpnLgAABJkJ Message-ID: References: , <1A341665-F6E2-40F6-9DB0-7ABB62ED3190@c3isecurity.com> In-Reply-To: <1A341665-F6E2-40F6-9DB0-7ABB62ED3190@c3isecurity.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] VERIS X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 01 Aug 2012 15:48:10 -0000 We could also add a spot on the agenda for the next meeting as well. That = will be a few months out in Atlanta (as we are meeting now in Vancouver and= had the MILE session last night). A webex is a great idea as well. Thank you! Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Luis Nunez= [lnunez@c3isecurity.com] Sent: Wednesday, August 01, 2012 11:45 AM To: Kyle Maxwell Cc: mile@ietf.org; sacm@ietf.org Subject: Re: [mile] VERIS Hi Kyle, thanks for the info and offer to field questions. Maybe at some point it w= ould worth while to see the connections and relationships of VERIS and MILE= . Some of the things we as a community grapple with is how the various fra= meworks/specifications interact and work together. thanks. -ln On Aug 1, 2012, at 11:25 AM, Kyle Maxwell wrote: I'm on the VERIS team here at Verizon, so I can help answer any specific qu= estions you might have. In a general sense, I don't believe VERIS and MILE = really compete but are complementary to each other. On Wed, Aug 1, 2012 at 10:11 AM, Luis Nunez > wrote: Anyone familiar with Vocabulary for Event Recording and Incident Sharing (V= ERIS)? Is this something that competes with MILE? or does it complement, c= ooperate with existing efforts? Information sharing issues are on the rise and I would like to make sure we= are aware of the various efforts under way. We want to as a community avo= id duplication. http://securityblog.verizonbusiness.com/2012/08/01/announcing-veriscommunit= y-net/ -- Kyle Maxwell [kylem@xwell.org] http://www.xwell.org Twitter: @kylemaxwell From lnunez@c3isecurity.com Wed Aug 1 11:24: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 DFEC611E8396 for ; Wed, 1 Aug 2012 11:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.475 X-Spam-Level: X-Spam-Status: No, score=-4.475 tagged_above=-999 required=5 tests=[AWL=1.124, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK3JNVRUtQok for ; Wed, 1 Aug 2012 11:24:39 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF67A11E83B0 for ; Wed, 1 Aug 2012 11:24:38 -0700 (PDT) Received: by ghbg16 with SMTP id g16so8211113ghb.31 for ; Wed, 01 Aug 2012 11:24:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=X9K5w0a38Rn00upwMs8GmLa8XHdDX5Q9qytcHe+KY8M=; b=QKHg3b+U3/ydTJHff+TWm8MQCMLOQmy8cXFzvnlJ+XfmEfXee6/RIy1uB2tARYYb8u aAq/Xy0SZIu8einEsZzzWUAB1VYEa/9nFLu73b77GLEaR/nKrBsY/U1QkoKdgw6MNhaN P/NjmLuCaNpFfLeW5Xe/J+qKlWSVt9uphsz4m2e/YRzyKOwbW052YlLhw3VdcYgG31oJ sa59XZmD1XJIjzQAkzhdpd67CdPfzgV7Ii5OCP0kGl6Mib3t5ogOd5RimR3ZbVPIjKN/ W1JeOsf0t7YJJEVxrB1BsN42c80xKThWsG9jiZk2wffG8yVdHTiR15OGN0+tnfFsV8yZ ry6g== Received: by 10.101.3.19 with SMTP id f19mr5468034ani.58.1343845478164; Wed, 01 Aug 2012 11:24:38 -0700 (PDT) Received: from [192.168.1.33] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id q17sm484820anm.12.2012.08.01.11.24.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 11:24:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Luis Nunez In-Reply-To: Date: Wed, 1 Aug 2012 14:24:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Waltermire, David A." X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlTqCQdKIpEtb12Q4+qF7aaqpfIfVo/oQptaNvsljUiXtovhBRSkGWa4M0Uq18oF3bSnnso Cc: mile@ietf.org, sacm@ietf.org Subject: Re: [sacm] Agenda and Remote Participation Info for the SACM BOF X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 01 Aug 2012 18:24:41 -0000 Kent, Dave, can you add to the agenda the IPR issue with the specifications. I = think we need to inform the community what the issue is. It came up in = the MILE session and it directly impacts this group. If someone could = clearly articulate what the issue is, we can at least have a common = understanding among the community. Thanks. -ln On Jul 30, 2012, at 9:15 PM, Waltermire, David A. wrote: > As a reminder, the Security Automation and Continuous Monitoring = (SACM) effort is going to have a Side meeting at the IETF 84 meeting in = Vancouver later this week. A description of the meeting, the date/time, = web meeting details, and the agenda for the meeting follow. >=20 > SACM Side Meeting IETF 84 >=20 > Security Automation and Continuous Monitoring =96 SACM (pronounced as = Sack-em) >=20 > Side Meeting Chairs: David Waltermire, Kent Landfield >=20 > Description: A side meeting to continue the discussions around = security automation and continuous monitoring working group development = efforts. In this meeting we will be reviewing the Use Case document and = then focusing on a draft charter for the potential working group. >=20 > Here are the meeting specifics: >=20 > Date: Thursday, August 2, 2012 > Time: 18:30 =96 20:00 PDT > Room: Plaza C >=20 > Thanks to Nancy Cam-Winget for organizing the webex. See conference = call and web meeting details below. >=20 > Agenda:=20 > * Agenda Bashing > * Status of work since last IETF meeting > * Internet Draft Discussions to: > - support the charter/use cases > - other potential future drafts > * Discuss draft WG Charter >=20 > Current Drafts: > - http://www.ietf.org/id/draft-waltermire-sacm-use-cases-01.txt - = draft-waltermire-sacm-use-cases-01 - Analysis of Security Automation and = Continuous Monitoring (SACM) Use Cases > - http://www.ietf.org/id/draft-waltermire-content-repository-00.txt - = draft-waltermire-content-repository-00 - Automated XML Content Data = Exchange and Management >=20 > ________________________________________ > From: Nancy Cam-Winget (ncamwing) [ncamwing@cisco.com] > Sent: Monday, July 30, 2012 8:05 PM > To: Moriarty, Kathleen > Subject: FW: (Forward to attendees) Meeting invitation: SACM BOF >=20 > From: Nancy Cam-Winget = > > Reply-To: "ncamwing@cisco.com" = > > Date: Monday, July 30, 2012 5:04 PM > To: "ncamwing@cisco.com" = > > Subject: (Forward to attendees) Meeting invitation: SACM BOF >=20 > **** You can forward this email invitation to attendees **** >=20 > Hello , >=20 > Nancy Cam-Winget invites you to attend this online meeting. >=20 > Topic: SACM BOF > Date: Thursday, August 2, 2012 > Time: 6:30 pm, Pacific Daylight Time (San Francisco, GMT-07:00) > Meeting Number: 205 870 492 > Meeting Password: sacm >=20 >=20 > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to = https://cisco.webex.com/ciscosales/j.php?ED=3D201187757&UID=3D0&PW=3DNZWYy= NWU2YWY3&RT=3DMiM0 > 2. Enter your name and email address. > 3. Enter the meeting password: sacm > 4. Click "Join Now". >=20 > To view in other time zones or languages, please click the link: > = https://cisco.webex.com/ciscosales/j.php?ED=3D201187757&UID=3D0&PW=3DNZWYy= NWU2YWY3&ORT=3DMiM0 >=20 > ---------------------------------------------------------------- > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes > ---------------------------------------------------------------- >=20 > The affected toll free numbers are: (866) 432-9903 for the San = Jose/Milpitas area and (866) 349-3520 for the RTP area. >=20 > Please dial the local access number for your area from the list below: > - San Jose/Milpitas (408) area: 525-6800 > - RTP (919) area: 392-3330 >=20 > ------------------------------------------------------- > To join the teleconference only > ------------------------------------------------------- > 1. Dial into Cisco WebEx (view all Global Access Numbers at > http://cisco.com/en/US/about/doing_business/conferencing/index.html > 2. Follow the prompts to enter the Meeting Number (listed above) or = Access Code followed by the # sign. >=20 > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 >=20 > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 >=20 > India: +91.80.4350.1111 Germany: +49.619.6773.9002 >=20 > Japan: +81.3.5763.9394 China: +86.10.8515.5666 >=20 > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://cisco.webex.com/ciscosales/mc > 2. On the left navigation bar, click "Support". >=20 > You can contact me at: > ncamwing@cisco.com > 1-408-853 0532 >=20 > To add this meeting to your calendar program (for example Microsoft = Outlook), click this link: > = https://cisco.webex.com/ciscosales/j.php?ED=3D201187757&UID=3D0&ICS=3DMI&L= D=3D1&RD=3D2&ST=3D1&SHA2=3DTkz-bhelFlmrhUuPkK7v2d/0gsYehkMU1WW8szSvQnM=3D&= RT=3DMiM0 >=20 > The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going to = https://cisco.webex.com/ciscosales/systemdiagnosis.php. >=20 >=20 >=20 >=20 > http://www.webex.com >=20 > CCP:+14085256800x205870492# >=20 > IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From Kent_Landfield@mcafee.com Wed Aug 1 17:55:29 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC9D21F8919 for ; Wed, 1 Aug 2012 17:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PTQuJTryShY for ; Wed, 1 Aug 2012 17:55:28 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id A9CB721F88C2 for ; Wed, 1 Aug 2012 17:55:17 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 0276_5e4b_73fb36a4_e917_436a_bdf4_1ea1e4fc12c9; Wed, 01 Aug 2012 19:55:16 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Wed, 1 Aug 2012 19:55:06 -0500 From: To: Date: Wed, 1 Aug 2012 19:56:02 -0500 Thread-Topic: SACM IETF 84 Presentation Thread-Index: Ac1wSXSZxAdEXNIWS5WQE2NEmeZ7KQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_CC3F1CBE38B4Fkentlandfieldmcafeecom_" MIME-Version: 1.0 Cc: scap-dev@nist.gov Subject: [sacm] SACM IETF 84 Presentation X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:55:29 -0000 --_004_CC3F1CBE38B4Fkentlandfieldmcafeecom_ Content-Type: multipart/alternative; boundary="_000_CC3F1CBE38B4Fkentlandfieldmcafeecom_" --_000_CC3F1CBE38B4Fkentlandfieldmcafeecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Here are the slides Dave and I will be using tomorrow during the SACM Side= Meeting. We look forward to seeing / hearing you there. Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com --_000_CC3F1CBE38B4Fkentlandfieldmcafeecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,=

Here are the slides  Dave and I will be usin= g tomorrow during the SACM Side Meeting. We look forward to seeing / hearin= g you there.

Thanks.

Kent Lan= dfield
<= br>McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: = www.mcafe= e.com
--_000_CC3F1CBE38B4Fkentlandfieldmcafeecom_-- --_004_CC3F1CBE38B4Fkentlandfieldmcafeecom_ Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="SACM-slides-ietf-84.pptx" Content-Description: SACM-slides-ietf-84.pptx Content-Disposition: attachment; filename="SACM-slides-ietf-84.pptx"; size=96219; creation-date="Thu, 02 Aug 2012 00:55:05 GMT"; modification-date="Thu, 02 Aug 2012 00:55:05 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDatx5aWwIAAKIZAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM md9v2jAQx98n7X+I/DoRY7Z1XUXow3487Ueldn+AmxzgLbEt27Dy3++SUIgQaxqM5b6ATLi7z12k r+/s6fVDVSZrMFYomRGWjkkCMleFkIuM/Lr7OrokiXVcFrxUEjKyAUuuZ69fTe82GmyC1tJmZOmc vqLU5kuouE2VBolP5spU3OHSLKjm+R++ADoZjy9orqQD6Uau9kFm088w56vSJV8e8OeWBM1J8qn9 Xx0qI1zrUuTcISitn9Kjdr81LA4MRVUHbh4ct7kX8sCkG2sti4OERmo+FzkUKl9VmEaqDVj8btCq EpcC0zO34BxW0f4H1EBph0XVbQlTtGxC2aXQ9s22FD/xHRpRQHLDjfvBKywY1drRLlv6dFFPSHSf d1pxIftgbImE37nF6ljaWbBzk3V8n8o0ic20rVCY2jyrKluCMJUYQvA2yLsYQvAuOsH76AQX0Qk+ RCe4jE7wMToBG8dHiK+KLL4ssvi6yOILI4uvjCy+NLL42sjiiyOLr46TOOoolQP72Fp3FmcXyo7v vgaqnj1ujNL23PvFznEfwVrA3yAEO8d9BA4nYqDNp/+raNz0RuT3Jdy6TQlnr7vbu+6jaCawb3yj Vm47RrQL/yJ0J1qctjuBTmUKs5O3+Z7KFGZr92MKs9f7MYXZ/P2YwnQDfkxh2gM/pjD9gh9TmAbC jynQwOUJ9RKVPNBQ5lmpmFre6T/8t7nn9R/7jsc/8d6IeAjfNHh4p2BgeJ/5eKZeW4809qpgnIAn T9V3EfGSYHjAg6sDqG88CiiOxKbNDcvsHwAAAP//AwBQSwMEFAAGAAgAAAAhAKPsgiYNAQAA4gIA AAsACAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsksFOwzAMhu9IvEPk+5puIITQ0l0Q0m4IlQcwidsG2iRK PLS9PWGHlUqjmgTH2PGf78/v9WY/9OKTYrLeKVgWJQhy2hvrWgWv9dPiHkRidAZ770jBgRJsquur 9Qv1yHkodTYkkVVcUtAxhwcpk+5owFT4QC53Gh8H5HyMrQyoP7AluSrLOxl/akA10RRboyBuzQ2I +hDyy3/RlgMxGmSU2kdahJjJItvsRdQYW2IFxuvnXE7HG0WmBnke6PZyIN80VtOj17uBHJ/xLGnP 5AyZeSQMYY5o+Z9EU+bxf0JgGSKlbOSY+xzQ6nKg3/dhzIy73fDm0PYjzSmtU694D9R+ZyYnm1l9 AQAA//8DAFBLAwQUAAYACAAAACEAY1wjtMEAAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xp ZGU3LnhtbC5yZWxzhI/BasMwEETvhfyD2HskO4dSimVfQiCQU3E+YJHWtogtCa0S6r+vjjYEepwd 5s1O0/0us3hRYhe8hlpWIMibYJ0fNdz7y/ELBGf0FufgScNKDF17+Gh+aMZcQjy5yKJQPGuYco7f SrGZaEGWIZIvzhDSgrnINKqI5oEjqVNVfaq0ZUC7Y4qr1ZCutgbRr7E0/88Ow+AMnYN5LuTzmwrF s7N0wzU8c8FiGilrkHJ7562oZXkfVNuo3dz2DwAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3 AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU5LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhI Uy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7B k4aJGA7NclFfacBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZ akhnuwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP// AwBQSwMEFAAGAAgAAAAhAGNcI7TBAAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNi54 bWwucmVsc4SPwWrDMBBE74X8g9h7JDuHUoplX0IgkFNxPmCR1raILQmtEuq/r442BHqcHebNTtP9 LrN4UWIXvIZaViDIm2CdHzXc+8vxCwRn9Bbn4EnDSgxde/hofmjGXEI8uciiUDxrmHKO30qxmWhB liGSL84Q0oK5yDSqiOaBI6lTVX2qtGVAu2OKq9WQrrYG0a+xNP/PDsPgDJ2DeS7k85sKxbOzdMM1 PHPBYhopa5Bye+etqGV5H1TbqN3c9g8AAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACAA AABwcHQvc2xpZGVzL19yZWxzL3NsaWRlOC54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgie RD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgO zXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sG cZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsD BBQABgAIAAAAIQBjXCO0wQAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTQueG1sLnJl bHOEj8FqwzAQRO+F/IPYeyQ7h1KKZV9CIJBTcT5gkda2iC0JrRLqv6+ONgR6nB3mzU7T/S6zeFFi F7yGWlYgyJtgnR813PvL8QsEZ/QW5+BJw0oMXXv4aH5oxlxCPLnIolA8a5hyjt9KsZloQZYhki/O ENKCucg0qojmgSOpU1V9qrRlQLtjiqvVkK62BtGvsTT/zw7D4Aydg3ku5PObCsWzs3TDNTxzwWIa KWuQcnvnrahleR9U26jd3PYPAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAhAAAAcHB0 L3NsaWRlcy9fcmVscy9zbGlkZTEwLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJ tm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFf acBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp /s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAG AAgAAAAhAGNcI7TBAAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMy54bWwucmVsc4SP wWrDMBBE74X8g9h7JDuHUoplX0IgkFNxPmCR1raILQmtEuq/r442BHqcHebNTtP9LrN4UWIXvIZa ViDIm2CdHzXc+8vxCwRn9Bbn4EnDSgxde/hofmjGXEI8uciiUDxrmHKO30qxmWhBliGSL84Q0oK5 yDSqiOaBI6lTVX2qtGVAu2OKq9WQrrYG0a+xNP/PDsPgDJ2DeS7k85sKxbOzdMM1PHPBYhopa5By e+etqGV5H1TbqN3c9g8AAP//AwBQSwMEFAAGAAgAAAAhAKALh2sOAQAASgMAACAAAABwcHQvc2xp ZGVzL19yZWxzL3NsaWRlMi54bWwucmVsc8STUUvDMBCA3wX/Q7h3k26trpOle1FhoC8yf0BIr21Y mpQks+2/NwiODqYyGfiQh8sl333cJav10Gryjs4razjMaAIEjbSlMjWHt+3TTQ7EB2FKoa1BDiN6 WBfXV6tX1CLES75RnSeRYjyHJoTunjEvG2yFp7ZDEzOVda0IMXQ164TciRrZPEnumJsyoDhikk3J wW3KFMh27GLl39m2qpTEByv3LZpwogRrIslpZXYRKlyN4YDt+54qDNWnpKskiytdLpY0DOHr8Ist o8fjENAZoYGdFs7+TzjL/yI8u6Sw16rEZzHa/aFtHChlk30/DTIaH8h3rZxf0uy82d+mi/zn2bOj H1B8AAAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMv c2xpZGUxLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd 5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457 pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTzjwrF g7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAA NwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNS54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2I SFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0O wZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF 2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD/ /wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAhAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEx LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiP g3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457pdj0NCLL EMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8 c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhANQ8OiIaAQAA0QIAACEA AABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTIueG1sLnJlbHPMks9KxDAQh++C71ByT9KuICLb7kWF Bb3I+gBDMm3DtknJTG379gYR7cKqFw8eJ3+++X2TbHdz32WvGMkFX4pC5SJDb4J1vinFy+FB3oiM GLyFLngsxYIkdtXlxfYZO+B0iVo3UJYonkrRMg+3WpNpsQdSYUCfduoQe+BUxkYPYI7QoN7k+bWO a4aoTpjZ3pYi7m0hssMypM6/s0NdO4N3wYw9ej7TQlPnLD7CEkZOWIgNcimUWq/TuihUii/0+WSb v0zWJsfYOX/8yvUhPE2Tcsj1+/ic1TZCzXKCjjH2LqIkML0cCaUBQpJ5oXj+1HsKNs3ufk6HPXyr cvVPVEzwnJ5ORhwCOQ5xkXn+s44++YjVGwAAAP//AwBQSwMEFAAGAAgAAAAhAGyQGG3BAAAANwEA ACEAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMjAueG1sLnJlbHOEj0GrwjAQhO+C/yHs3aQ+QUSa 9iKC8E6iP2BJtm2wTUI2Pl7/vTlWEDzODvPNTt3+T6P4o8QueA1bWYEgb4J1vtdwv503BxCc0Vsc gycNMzG0zXpVX2nEXEI8uMiiUDxrGHKOR6XYDDQhyxDJF6cLacJcZOpVRPPAntRPVe1VWjKgeWOK i9WQLnYL4jbH0vydHbrOGToF85zI5w8Vikdn6Rfn8MwFi6mnrEHK5Z2XYifL+6CaWr3NbV4AAAD/ /wMAUEsDBBQABgAIAAAAIQDy9vMBCgEAAJECAAAhAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTE5 LnhtbC5yZWxztJLPSgMxEIfvgu8QcjfZVhEpzdaDCgW9SH2AIZndDc2fJZO63bc3KxRbaPGix0mY b775McvV3jv2iYlsDIrPRMUZBh2NDa3iH5uXmwfOKEMw4GJAxUckvqqvr5bv6CCXJupsT6xQAine 5dwvpCTdoQcSscdQfpqYPORSplb2oLfQopxX1b1MxwxenzDZ2iie1mbG2Wbsy+Tf2bFprManqHce Qz4zQpKzBl9hjLtcsJBazIoLcfxOx8WdKPpcnjeb/6VZV3ZMzobtj9e0MJU0h2EQFnPznZ8H6zwE 6SxlG5ooCbQ/9LxFU4J63mdMAS563/6z96SY42ISezx4XzaUJ4dUfwEAAP//AwBQSwMEFAAGAAgA AAAhAGNcI7TBAAAANwEAACEAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTgueG1sLnJlbHOEj8Fq wzAQRO+F/IPYeyQ7h1KKZV9CIJBTcT5gkda2iC0JrRLqv6+ONgR6nB3mzU7T/S6zeFFiF7yGWlYg yJtgnR813PvL8QsEZ/QW5+BJw0oMXXv4aH5oxlxCPLnIolA8a5hyjt9KsZloQZYhki/OENKCucg0 qojmgSOpU1V9qrRlQLtjiqvVkK62BtGvsTT/zw7D4Aydg3ku5PObCsWzs3TDNTxzwWIaKWuQcnvn rahleR9U26jd3PYPAAD//wMAUEsDBBQABgAIAAAAIQBjXCO0wQAAADcBAAAhAAAAcHB0L3NsaWRl cy9fcmVscy9zbGlkZTE3LnhtbC5yZWxzhI/BasMwEETvhfyD2HskO4dSimVfQiCQU3E+YJHWtogt Ca0S6r+vjjYEepwd5s1O0/0us3hRYhe8hlpWIMibYJ0fNdz7y/ELBGf0FufgScNKDF17+Gh+aMZc Qjy5yKJQPGuYco7fSrGZaEGWIZIvzhDSgrnINKqI5oEjqVNVfaq0ZUC7Y4qr1ZCutgbRr7E0/88O w+AMnYN5LuTzmwrFs7N0wzU8c8FiGilrkHJ7562oZXkfVNuo3dz2DwAA//8DAFBLAwQUAAYACAAA ACEAY1wjtMEAAAA3AQAAIQAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxNi54bWwucmVsc4SPwWrD MBBE74X8g9h7JDuHUoplX0IgkFNxPmCR1raILQmtEuq/r442BHqcHebNTtP9LrN4UWIXvIZaViDI m2CdHzXc+8vxCwRn9Bbn4EnDSgxde/hofmjGXEI8uciiUDxrmHKO30qxmWhBliGSL84Q0oK5yDSq iOaBI6lTVX2qtGVAu2OKq9WQrrYG0a+xNP/PDsPgDJ2DeS7k85sKxbOzdMM1PHPBYhopa5Bye+et qGV5H1TbqN3c9g8AAP//AwBQSwMEFAAGAAgAAAAhAGNcI7TBAAAANwEAACEAAABwcHQvc2xpZGVz L19yZWxzL3NsaWRlMTUueG1sLnJlbHOEj8FqwzAQRO+F/IPYeyQ7h1KKZV9CIJBTcT5gkda2iC0J rRLqv6+ONgR6nB3mzU7T/S6zeFFiF7yGWlYgyJtgnR813PvL8QsEZ/QW5+BJw0oMXXv4aH5oxlxC PLnIolA8a5hyjt9KsZloQZYhki/OENKCucg0qojmgSOpU1V9qrRlQLtjiqvVkK62BtGvsTT/zw7D 4Aydg3ku5PObCsWzs3TDNTxzwWIaKWuQcnvnrahleR9U26jd3PYPAAD//wMAUEsDBBQABgAIAAAA IQBjXCO0wQAAADcBAAAhAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTE0LnhtbC5yZWxzhI/BasMw EETvhfyD2HskO4dSimVfQiCQU3E+YJHWtogtCa0S6r+vjjYEepwd5s1O0/0us3hRYhe8hlpWIMib YJ0fNdz7y/ELBGf0FufgScNKDF17+Gh+aMZcQjy5yKJQPGuYco7fSrGZaEGWIZIvzhDSgrnINKqI 5oEjqVNVfaq0ZUC7Y4qr1ZCutgbRr7E0/88Ow+AMnYN5LuTzmwrFs7N0wzU8c8FiGilrkHJ7562o ZXkfVNuo3dz2DwAA//8DAFBLAwQUAAYACAAAACEAY1wjtMEAAAA3AQAAIQAAAHBwdC9zbGlkZXMv X3JlbHMvc2xpZGUxMy54bWwucmVsc4SPwWrDMBBE74X8g9h7JDuHUoplX0IgkFNxPmCR1raILQmt Euq/r442BHqcHebNTtP9LrN4UWIXvIZaViDIm2CdHzXc+8vxCwRn9Bbn4EnDSgxde/hofmjGXEI8 uciiUDxrmHKO30qxmWhBliGSL84Q0oK5yDSqiOaBI6lTVX2qtGVAu2OKq9WQrrYG0a+xNP/PDsPg DJ2DeS7k85sKxbOzdMM1PHPBYhopa5Bye+etqGV5H1TbqN3c9g8AAP//AwBQSwMEFAAGAAgAAAAh ALGWPcvEAQAAnQ8AAB8ACAFwcHQvX3JlbHMvcHJlc2VudGF0aW9uLnhtbC5yZWxzIKIEASigAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvJdfS8MwEMDfBb9DybtN0/1xk3V7EWEPgrj5AbL2 1gXbpCRxum9v6Mbsyjx9CHkp3IVefhyXX9PZ4quuoj1oI5TMCIsTEoHMVSFkmZG39dPdhETGclnw SknIyAEMWcxvb2avUHHrXjI70ZjIVZEmIztrmwdKTb6DmptYNSDdylbpmlsX6pI2PH/nJdA0ScZU d2uQ+UXNaFlkRC+LKYnWh8bt/Hdttd2KHB5V/lGDtFe2oKYSBbiCXJdgM9KG5pi9jx0podchUteW IBRsgmKwUBhTFCMNhJEmKMbAJ4ZUFswzNxa0K3sakE7S0E7AUK6hT65GC+mYVmCtO5Pmh623QHsx izdC/jrPI7+IYF60ai7gTim0UWOfFHsBnz2KcwqluPdJYZ35OoZpQ9o+8ZlxmvUnGMs3FazsoXKy Ps9yJ4m1g4VSHWo6Fsp0qOhYKNExVHTMq+iQbyBDZ5R59RqGkaID6tVdGMYAxfAqLwxjiGJ4tReG MUIxvPoLwxijGKFuiwy9LvqXV/9i0nbomDzdX48BeoD92+y/WOiBDmY3bHJCuQ3tRCizoWIL5TVU a6GshkotlNPOSqMXP9XzbwAAAP//AwBQSwMEFAAGAAgAAAAhAGKTUI8jAwAAFBAAABQAAABwcHQv cHJlc2VudGF0aW9uLnhtbOyX3W6bMBSA7yftHZBvp46f2IFEJVW7qVKlToqW9gFcMA2qMch2sqRP v2PiBEOyKrdTcwc+/58Px+b6ZlNxb82kKmuRovB7gDwmsjovxWuKnp/urxLkKU1FTnktWIq2TKGb 2dcv1820kUwxoakGUw/cCDWlKVpq3Ux9X2VLVlH1vW6YAFlRy4pqeJWvfi7pH3BfcT8KgrFf0VIg ay/Psa+LoszYzzpbVRB+50Qy3uahlmWj9t6ac7y5VfRTUnTNFqsXxfR9LbQCOmgGZSue/6JKM/mQ Pyo9WPHKPEVRiGOcjGKMkSenZgV0Q+R/oJskI0c3Mrr+qVCi1kwNwvfWuoDRyHrpybuU3fQf8l3i ZOxk0dq3SVgxJqEjxoeCDtaxIyZD8Qi7JY6HYhJGjnV8LHatk2PxxLGeDMWYEEccBkM5CVzzsNsr WxoBk44sZLrfy7086Pk/IkcCF014hI6E8Jl1rXLEjoCJIz8Brxf/BD13YyHYMP+wl98RvxFx40cn +Lm7Ex3xw9iNHzn97Xbh4t3LNimahBgHAQDPtikaJyRpX/S2gfGjMsmYwBtLuG1ta3bQNGZ7H22d OSvoiusnttELveVsdk2nsDafS/v0ey49Ts3EY+LqeWHo+K4KX/OwAR3KX2FIctgKzVMEGRYwGG7b xReqGIwHOlVNdscK+zTPtLemre7OZ096W8D4aC1O6VkpJGrSe2PSzGeYmLsoNS/z+5Lz1oGZtewH l7tYetPyhwqUq2UGpPAMxoJmgPJWlhRKyZZUwogz5UCKdMqoo/OtEleM7gSZGggy1YGCFFtmlpRx BI+RgVZR+ZgiTGKT+wXhgb9h+w+EhptFOOoQ7nr6grBr4Q8QGm4WIe4QhqM4HF/a8Mwv2YCzDInD MIkSGMmXPjyrDw04y3DcMYyiBNrQZQhj/om+LN73R1d3xjD6KO7km7l+wiEFM9y+gvUSziy4Sc9X IoMBbq6n7an1f50XBoslFDuEYjzqHxifl5DBYgklHSGDB+5Jznf4eQkZLJbQxCE0JnF/2n9eQgZL +08JCAaXYfjRdH+CZ38BAAD//wMAUEsDBBQABgAIAAAAIQBGEeYIAQgAAL0rAAAWAAAAcHB0L3Ns aWRlcy9zbGlkZTE0LnhtbOxaWW/jOBJ+X2D/A6GnGSx86PCJtgOfvQbSHcP2DOaVlmhbiK4l6XQy g/nv+5GS5fhKnEwyOXZfbIqXqj5WFatK9eXiNgzIDePCj6OWYRbLBmGRG3t+tGwZv8yGhbpBhKSR R4M4Yi3jjgnjov3Pf3xJmiLwCFZHoklbxkrKpFkqCXfFQiqKccIijC1iHlKJR74seZz+wK5hULLK 5WoppH5kZOv5OevjxcJ3WT921yGLZLoJZwGVoFys/ERsdkvO2S3hTGAbvXqHpDY4c6eBp/5FMuOM qVZ085Un02TM9fD3mzEnvge8DBLRELAYpWwgm6YfI0xDo7S3fLnZiTZvFzxsf6FN8EZuWwbAv1O/ WESb7FYSN+10t73u6urIXHc1ODK7tHkBKMhfqrhKOTpkx9qwM/NlwIiZc5VOpVh6GbvXgkQx+FTs p+y53282myme1fbJisi7BMhItVU2Lx3UeGzmC2CqwZK33di7U4zP8a87aTMQcirvAqYBAdm0ic3x A/gDqiSURYVfpgbxfC41RkSEshcwClnOYJTtiRIS5pHBrS8kJJBME+b6EKZUdL4AJolTyvZmkTem nE5OvkKxTJsgBnxsiEYzRXXJabLy3SGHVKQof73Xsy8+zgbvXhxJSCMZB9RlqzjwGCd2jv7+FhSn uX3NqRPZX6WkMD8b34NkZecLQbsUQCDRIrfmfsv4o+9YHavW7xa6fdssON16r1C3O2ZhWB0MekPL cWzL/NPAGtNphrE32lgCPB9oX+i7PBbxQhbdOCylalxK4h+MJ7GvNdksZ+bghgYtw6nYZcuu1vUB AlnQp8He0KnlR3GiG4ds7imVWbGccqpZpuPU6mhrccJ2Wr/qtarVaDQMorTMMRtmOZ2B3Tc7ZXAr 0cuafSop0VA92fBJOodCqL3kPMj+IGwLnws5iX9oozKHwc3aeoZaohVh5LX/qPQsq+I4nUJtMKgW HNuxCt2yUy/UK91+rzHsmz2786eW6vvLdMc8ULjpN3/lPmycYsj3enFA1ItNu9JwnBSe+/12rWFX tbTszq/bds2uH8y3zWq9Wq8d9JuWU7GqDdWvdG4ebGiQnKxahl0r151yioyrqXw1k9Bbc670Dbqj jYCmR1Ol4XmCDQAfOZXSTe09+lL6X5mL4Tpy1e1HA9LhjH5MJnaM8cdkYbyGJRPsYxI/Gk9eg3Cl 4KmpeQXdFr8rY6WM+oMX//fRdHYmb0d23N7zr6zjR959zI3prZh7HcCF+TwsqQMaTUjNqlW404SD BidI+Ljr9ljUgnTg9G1xm1PBAl+FJ4+JBIGntfCXa67NPskxJX0mXO4nypySoY5ayE+/9Xr94c/E LFpFc4+iUzfElqZcMt+bHKUG9045wiF1V4CN7DH3GNw5a4RxhG4Igo543QnlgikH5NmbH9mUILxM lUCU5ohTVyHl16K494r3fThzjdgWwyNsboLc5g5jadShQ49TcdBW/NK3XDOuonoE3AY5Q0mU0yXi wPeGfqBdU8GX817AifbLh0N4xqlTvjdNBeGRjvcWiF9axr/CqBDI1P9jdG+A0XTAFXsDrsg8Q2i6 dv/a0/U89KWK3WRMRtOr03AgioQ080ttAdCY6IYfefDydJMGSyAR4MZgixmdT3GDNBAOKGC4RNCB f0Yvoy6/1sezQEDW0UvoWsYGok1wmA1j6grBJxRorBwwNV+RG0TTRDt8InHHrkwxU8FEjtn9GV22 0GhjrhTp3BzaxN2OdhYIflTgfXReNjpf45Bmtzqsma+nv+fNIdjIH74jgaOnIAJBwKebQAORbmai Utgf0/4z5HfGqYc0EL9uPt+0HFELxcAREVCuxgkf/P9eyNkplK3peNA06Rtz5xDOsEXnX8/TOyFZ uLf/+7bnD8K18XCqDatJrpAUvedyjJDz4RQR3A3T2aw1XTLy01VvdPkzsYrlzwPCv9chjQhSPXAX 4iUsKRj+z5ohGRdHEfWRif1QvJ5hAF/gAn9UrMh4PQ98l/RjlUrfQ3D+mBU/uT1MZrZY3TsPOd2P +zF/1z2AZPmJrO0Rq5ZddmkO6h3fG99Gs8lg71hfmM08UZXD8Izc+xGIj8UD+uIgn82+a5P+6zqI YMnnfuDLO4LULekIwYRQ36nIJVxFbdkrRfMT2XSkjAOms4+aYYYIYa1j6j2JfcwOnRGVpD5rm8QL OO83+AaoPkjKXU/wxS3AC6vGU+6Mp/rM6d4fPNQ7tHbPCHdPXmo4zfbzL6PPAzCZsCUyiIwzb09P H79ZzkVBh6tvn0TYMqRvevW99h3FiQ8kztSV8pXH6+TJJ5SL/zkuzgsbuPzd/0N3f6HTG3y7/ETH tJMbx8f6JPBp5LLih2LxXDu1I6iHRguZ5pDluU95m9a6/E2JzxeIH18IhrdNAGv3enlgDJ/hGvxl 9+hN5WHru+yo4lvg8LYCcXFxsYPAOX7/uZpwaAPehNfnOC7KtVHFRPi/V6B0/xltVQS4LRvTHdsC x01x1f0isG63UbV6dRSBmc6w4PQbtUJnWK0UhhXbcXrdeqdnDzZFYC4KUFQ+70UrweyGY9tls1LX tXBgAFRqujfUomtTq+kG/BtNrm50wIkSVDi5sN7oSvChRjlEmLqdgtI9P8SAqnqTUVb+hk+W6tmd IVmZFnd6a94y1FekhR/5kuFbEbKWlOObT8RQNIvyvdhjs7TOMZzEscxrUP9SHVxKriYHZGf0qVZG M5oovm3/FwAA//8DAFBLAwQUAAYACAAAACEAJ6iFpgMGAABMGAAAFgAAAHBwdC9zbGlkZXMvc2xp ZGUxMC54bWzsWetu2zYU/j9g70Do1wbMdZz4FqN2kbhNUSBLi9p9AIaibSISqZKUE28YsEcp9ih5 lD3JvkNJvihOm3UrsGZNgFiWyKNzvvOdC0+ePrtJE7aU1imjh1HryUHEpBYmVno+jN5Nzxr9iDnP dcwTo+UwWkkXPRt9/93TbOCSmGG3dgM+jBbeZ4Nm04mFTLl7YjKp8WxmbMo9vtp5M7b8GlLTpHl4 cNBtplzpqNxvH7LfzGZKyOdG5KnUvhBiZcI9NHcLlblKWvYQaZmVDmLC7h2VRrBMTJKYPl02tVLS lV6+tNkke2PD44vlG8tUDLwipnkKWKJm+aBcFr5qLMNFs7Z9Xknig5uZTUdP+QC2sZthBPBX9Beb +EDeeCaKm2JzVyxe71krFi/2rG5WL4AG65eSVYVFd805rMyZKp9I1lpbVSzl2HpuxJVj2sBOMr8w T1wsK2FkM4nPFsyvMiAjvA3SyqXF8wBJtcUFWCtd12B0+53+QYFI96hbA6XX6x226SlB0zk6omvS pZKCFxRis4G/OTXxihC9xCdpxwcavDzJvZkpz2ZG+4ngCXQ9PsBPKWezOHF+4leJDF4BdnwAhVnK 7XnwmNIxiLR2W5BvsSDhFEJSN95NIhYr64MTmUv9OJEcwVaa5EfPpRNWZURkRib4YEghiF53R5r7 ZRgdtcj8j8r94bOFSYuQBLn3KCsA12fL3SPvx5owqeM33PK3dQT32Fw4HB6BtysvB8cTAe9nea9i +VspkNnmYHqXnI64L3gcrreD9xNMbXUKLsLBJWkDVaoA7nfxu+Zqv9cHX3fICkJZ519KkzK6GEYW ikXkeb48d740s1wSrL2P2+zacsSle59zK4MElxHPz1Qp5WOs3s9cwr3V2+FasM6Ppgvl2LWxV8jq bG5NnrFrlSSwwcS5kMwvJIIrSQyl/cGOm0HyIpACve/l+P733n64X9YmMg/7nV4HEVKFZ6O8QS+7 zM/A4pCgZlwg8E+s4gn5hJ6NF9wygT/D6M/f/yg9Veao/Rh9NApPHhjUayElvK90UT2RFXjC4rLu EbpLReWZcc0MKvdSyWtmZsxJkVvlV7cfODyOsouNuNYxo5BVOje5Y6nRyhtL270BNiLJY8k4s3Im LQq/xIpYJl8XwA9LmnV8J6GrsbFjU8vF1QZhl0mhZivC6BKQLJDprwjDmZrntoTVyu0GosZI1O57 kthah3pm3QmIx09idJRgJLJGrsA2paVjTXDwfa6spO7OIXFYtuUItJUi5BmqqjmfS/dVUXTDtR21 Udr35r41TapMu0NQtw1MLJfoiqlF9xJJq45SjZn/eZp9uVBGtlTao7Exc3BvuQHr9kPFqRpYjzGM vxy+GU5iVLDoQITQ/gkNshcLCnIqQTzLEiX4pUpQoepKPL5sWbfwYWG+yRL3VyTunPQ4eyJJKpyH QzkKCKMiGRuSqto0DnU9viFN+daPHoJ0yBbUHrqArzBpmusKcXRh3giTOJY7GRfVquy/2Kb9Kjfu 6b5qqeb/lpfjcOK9pOxAp4RUOkc1PeClpadDBTW6JcTUC8TKeasu88DwSQU1nW2KTpeN0eQiKGrA PsIcvuHuv9BLsC1PEOHn1ODCK9Vhok7mi9I5L3ScGWxgJ8hHzlHPxgTPigSv4Mmabt8SzycSz5Yf NsSnyhlzzym/0Bx1k2dksmIOR1TyVbyikitYFThFL7hdBTiOfVs+rfnmE8WpflSh/OlWzsvUsb8f behoi2R3d2YTRjfVwBXDE4w+aChDYxQcbIfRr6enx93Dcf+0cdpqnzXaz497jZOzbqdx1jlqt8en /ZPx0YvfIuxptQfCylAbX1Uzaty8MxcGatY4M/NPkN2bxYC5mZlraQO5MWNuHZSD6iVPhlG/fYxX dbvF+CaoFsYxlbKwoBodi8T+zLPXywAuJuLoPMfhVgaXEQhYulmC+ZWirons9bo0POPYjGVTdK7F rDnOMZOggcZM4RgvIxyZ4GyLiZGWmARgroXD+zSMXX361hi/Hon/I+MLdYM65LVCP7oqdcYl/hcw +gsAAP//AwBQSwMEFAAGAAgAAAAhAHI6322kCAAAlxYAABUAAABwcHQvc2xpZGVzL3NsaWRlOS54 bWzUWO1uG7sR/V+g70DoVwLYkmU7si3Evoid69sLpNdB7PsAFHdWS2SX3EtyJStFgb5G/+lZ9Ch9 kp4hd1eS49ymaFqkgR3rgxzOnDNzZpavf3isSrEg57U1l4Px8GggyCibaTO/HPz6cHt4PhA+SJPJ 0hq6HKzID364+uMfXtdTX2YCu42fystBEUI9HY28KqiSfmhrMvgut66SAW/dfJQ5uYTVqhwdHx1N RpXUZtDud1+z3+a5VvTWqqYiE5IRR6UM8NwXuvadtfprrNWOPMzE3XsuXSEydV9m/NfXD46IX5nF T66+r9+7+PUvi/dO6Ax4DYSRFWAZjNov2mXxrcEyvBg92T7vLMnpY+6qq9dyitjE4+UA4K/4f2yS U3oMQqUP1fZTVdw9s1YVPz6zetQdAA/6QzmqFNHn4Rx34TzoUJIY91GlpRJb31n10QtjESeHn8JT vyw6Yxwzm68LEVY1kFHBRWvt0vR9hKTb4iOsna89GJPzV+dHCZHJyeQJKGdnZ8en/C1D8+rkhF+z L50VHJDM1tPweG2zFSM6w1/2Tk4N8vJNE2yug8itCfdKlvD14gj/WjvbxaUP92FVUmQF2MkpHBaV dO8iY9pkSKSetmjfYUEpuYTIHP56PxCZdiGSKHwVbkqSKLY2pHD1lrxyuuZE5ghCjCPaIZO9l05+ +KK5FDOcQsBdoDF25uDLRJ91RH8gheKeg+wJx43UT1TG17v5+y/IOpugqGP2bsnYpvD5xcV40rE1 OZ2cnBzF43q6AKnz4SeyleAXlwMHvwYMtVy886GNsl0Sg/0Su2LpJDLT/9ZIR9GCr5npW91a+T1e n+fOf0Kmx/B+l8V7Uo2DwIknHH61UUTJ5GuTVBPZIKC7IhQk/MoHqjxeywA5to4OAJRV5P0BL9qs g5PGV0jnuGTXRiG9mJGyFQkpVCHLksyc/QzSf0T2u80a8iyN/pSkVNhcYJHw+hMl62JJIkeat8fH OMMKDkgVNGct2sdm7SH5maisD2wBXmsngsapiKOSppFl5zJ5AeGmOc5jN9AxRLCbtTaU5+BdL8gg sKFIiOIkCQLRRxgRzSCQ+Egr7BEoHFknIxouuCYMxUOBNUvrPvLnc2ebWiw14iEjZ8hz37m/YzQ1 OJd5oY3wTV1bF4BKjrdbLvqNLfCIgulJKIAJsSzIUfdelgewpAowEznrTt0DTShpwA1+QiAnmqBL gJ7B31DAk4jhU3b4TPDBOysi5psAOg6W2UIahd2GCJEkDvpwN2tkQNUYDThf0HA+3I+tkJy6B0JB DLVpbONhFItt+hjNsikBiZzPXeStzU1pZLny2r9k2AkmkQ7gOUeTbj1ouYi8WfiYwZQHF4i3dtrD bcRzf/enO9HgjZKeQDzbeoZBqQpNC0LIsDpbcUjGNxXzzFZa3/ntC0YQH2AMcTFvXkacegq33G/W fBAS3pHMkNPkmHGgOFuJBUBhJPbLQyKlcBrjjq1lNtyrd0haahFczP9u6W/W387WLh8xxKQDZETu Gh3yBgnKqHEcKF2lMV21AoDZaMGBl8CjmZXaF8ADcoqqZYwAkKDHGnrDBYkfNqGZURMNIAFQUHMa irt8s66lC1o1pcTExGsI+oDKjRzuc8wnRG+6Wtll6YmLbZFG6r2ngMwt0Mcgi8iCXM+bRHsrjoum hEbJGcoL6Q8xgnc8RLKHXCEW461bfaV/mzX2uqigz+TTUyzThMoyB7WCsKGItufvpu1+yX2nSXW9 Esh9ckFGde1JPGBJQs+2c7QRZhFtClSyKuG3gnboGtqLBKM5JIWg1dAnCCkUGW0taV2vVbt6n0H4 tZmKjNCBmG5kHksIUg9GOBV3Eiwt5hRQVAcvXughsnA/dV4iRWJ2mPlmvb8BfnAnUHDUokuiE+EQ do6VBdQhwtr6KIqQ+2gccXQS42GZCyr2GfY0pnv8uk28UEA65hiMUS8ZkqG0NWdh3MXqFxsOSiSX 3E6SpEXN3hamDRa+QSJ/DiypaL2wxochvSJELKg7GKX+vpv/AL81vVMnQvN4cSBmDcxGy79BI9iW ZRphndMWAeGXD0BlFuCRH5+gx7XFN+y9oxycM4BNDV1YFlohWguHxQuEw72QpwLE6vzL2MJQHmjv QK0t6IhNW/cQHXpMZc3Gd4NIe/ZKHXD3vXq4P4N9R5r8/GiCQljoDDpsS8wAnHQMOMCKLbGrGQah LxnGjPOIWeEiw5CHr1Pj5arg0ky9jbMjjUFci1l81pixoHssL0u79NNv13W+ZQcbDzfrt1z2UHVC P0ceoinzo1tKuz7bUHeZjY9PB+jVQgENRhEfYyrFiARgthNe1KZ27kIiZlwhEcm6cajuWIUSLQUS wwNRP/EAxbYiITiMKSoY9xFsOXBJzUEEWhvkCcIBswtZNu38jMEUwoE2iF2xXfIxaaSK8iJBK6Xq zTgAmYnCKu5T6FoA4fuk5/h/Qw+EjeU3DaUQi3YsZTI6XBnU9gnpH3/7e2IkiUo3SbQju9h7wGBl R4YA+8M98A//D8A/GYobTnPOo50rMH6SWBJmPHrUPuVb3544n9q5Z7ccMJakByM8HNoKYBSEwQ6q vtC0jKXTgbgdxw5EifblZByC+qPilMk1ois0e+5ssQz9f3uW+fzqI96AdFd3uEfDFQLfbfCNGh7R Lwd/ub6+mBzfnF8fXo9Pbw9P316cHb65nbw6vH11cnp6c33+5ubkx7/i9qAen047Ofm5u+3Eh5/d MFZaOettHoYAcZSuKke1XeIph5sjbivHR+2VJ4ThcnA8Pj2fTI7OxhftvRh8i/canbcIobuFVKX7 s6zvFvFpApermBBu4kc1BIWvRrB0uwT3QJofiTjgYNrIIVnxcucBD9Dp2jJrcOnKV1c8VgUaII+g ZA5XL4apxf2Qzegh3uCF6oO1ob9d/Y+iT+5Gd5i25B+/an3GS1wrX/0TAAD//wMAUEsDBBQABgAI AAAAIQCZD4kDSQMAAF0JAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTgueG1stFbbbhoxEH2v1H+w9rlk WSAJXQUirlGlXFAg6rPj9Qaru/bWNgRa9d977GVD0oBEovQFDJ45njnHM+Oz81WekSXXRijZCaKj ekC4ZCoR8qET3M3GtXZAjKUyoZmSvBOsuQnOu58/nRWxyRICb2li2gnm1hZxGBo25zk1R6rgEnup 0jm1+KkfwkTTR6DmWdio10/CnAoZbPz1If4qTQXjQ8UWOZe2BNE8oxaRm7koTIVWHIJWaG4A471f hNRFZmyaJe7bFDPNuVvJ5YUupsVE++3r5UQTkYCvgEiag5Yg3GxszPxPCTMswn/cHyokGq9SnXfP aIzcyKoTgPy1+4QTjfnKElb+ybb/svnNDls2H+2wDqsDEMHToS6rMqPX6TSqdGbCZpxET1mVphSu l4r9MEQq5OnSL9Nj18sKzOXs4Is5sesCzDCrPdrGtNz3lFQuBrR6vuyqr5K1y/0e3w6HxhI3qLew KhXWnfV8KzN2atcZ92whJxoDiORUX3omhUwg8BOdHk3DIKPuanNZu5sGJBHabsm13aEwbGEMcSdZ f17p59D3OxOT20HGKSpoIx6QNE3tG3F8Jrb7/YIM5lRbrl+EgZCQJaireMKy1HK/oq1K0SG1nEwy yvhcZQnXpPkR4iYW3eEX6o1maYCKwHWNPANeYKfgYUr7xHfq6YhPeHpbVpKX2GvxdkF6iwfS+EIa 9ajxglZUmkwmVFOcsf9yvIf844r8aSYSTq4X+T2Ify5C6yNEQB8GdCnEz4W/N5UWjXdU3Zu1SDEH XDP83Y+Om8dRvVnrj0/GtdZw1K71o9OvteHpsNkfNXr103bvT7DpC8ZxIhH3TiVfFZRvvTuvgu22 t3oiFof3vxQ9qRQdK4XyfKHl8UdomVq9U8iq076lfe4R8rBG+G00G5Npb3BFpu7uXnFuMby3RLvS 3tOPfFsqByeW1Sxlmb6ixc3SH48nAugb+L8K4CJUZ7o1QZMTOTbcKLHy0qAXY6ZQOMNsJqvhmyzw dHCNPhVSWB4QTHWLCugEkuNRA7VUwmd+Dtn8Fpo9vRGi1qtXQi6YVkal9oipPCyfG2GhHrkulPAv jqhePlvKcH04CHsTn1ttYsYSRdn9CwAA//8DAFBLAwQUAAYACAAAACEAoTNV65QFAADjEQAAFQAA AHBwdC9zbGlkZXMvc2xpZGU3LnhtbMRYXXIiNxB+T1XuoJqnpGpZYIb/MnYBhmS3bJYyJO+yRsCU Z6SJJLBJaqtyh1wgTzlIjpKT5JNmBi+YZbHjrfAAg0ZqdX/9tbpbZxcPSUzWXOlIiq5XfVvxCBdM hpFYdL2fZqNSyyPaUBHSWAre9TZcexfn335zlnZ0HBKsFrpDu97SmLRTLmu25AnVb2XKBd7NpUqo wV+1KIeK3kNqEpf9SqVRTmgkvHy9OmW9nM8jxi8lWyVcmEyI4jE10Fwvo1QX0tJTpKWKa4hxq3dU OodlbBqH9lenM8W5fRLrH1Q6TSfKvR6vJ4pEIfDyiKAJYPHK+Yt8mvsrMA0P5b3li0IS7TzMVXJ+ RjuwjTx0PYC/sd9YRDv8wRCWDbLHUbb8cGAuWw4PzC4XG0CD7abWqsyip+bU60Fla9INZ/D7IubE 31qXLaEQcSXZnSZCwt4MBjlYYjbvKSXvl5yG2g5n1rPxutjLQmJ3T5fEbFIAZyIT83xe9tLBVczX DvLCji1QtXoTJHJoBUHV30Os5fvthn1tcWvU/UbLTfgUjkxu2jEPfRluLNy3+HXuop1Ym6nZxNy5 AWDRDrQgIZ/P6O30165Xbzb8RoBAoVeir+6c/dZ4sHuyEszYAbsqFtOU2QedsgkzZE3jrteq4OMM 3k6AYrmZwIZ2FDaLIa7rcVH6aYr4w56BMyiMlHFcIDoxg5hTxGxuvDnvhWFkg4HG5F3IqT6DXAP6 QaIVy0U4oYrenCDdug06OeoWCMEtGXGO08cvIuKRPsFXoU8UIjYKhp3OHN9vOSSBYitoWRLtBFur 2Qisfxx1mkG1ns8AHFmsOhgyDhfInMCdeA3P51t93sdVcMMjWx87xcz5j3t+PHn9IY7IhJOVxnG/ J/QYOZ6qlZHDMQRfllDWPueMnGwHOfxUkCXoz5MxUo7hKlWR5oRJIXDy8HBHw1fdsYd8RxecvKeC l3e2eYb2h9B9Lzm5uNiR+ETxhKord9JHIoTZ9tFG5+1qjPyaB57l1zNUyYny95/Hd34RCQ+ZOVxD cbKz2fO1TaiAD2wqJzrlLEJyz1I50Su2JFSTwXBI/vn9D5LQDbnlhOLLgCYkAlkWyk0m95FZvliT Q7ZJs8QW74azEeFzlC9Gky849FNYXyOMXnhMXPI1j2XqAJVzojlbqchsCF0ZiRoMecEGPmFUc01Q z5Gd2ikDUnBzL9UdEN/6JlXSSCZjTb6bjq8nb8h4OBt8GI/ewDV/vZQCh4D/fkfYk7D5v1E+pPJN pO/IlEmFxO8gveZGRWyfMcdT79NDMbMdiaZIMCelXr+NSj0rRi+p4WQSU8aXMg5B5xMysD15UPge qdRCk1UiSxrPPVS/Nv06rmLdkfwr5CiK40z8M6uuw5lumx8PuaS3WhD/DfErVf8An56PabvAdCSl PXs+RbX25brmy6jOjcpg/WVFFXYokD2hsvl6yOYJxZ2C097gmkyjkJNrzg2Y/gq4osQqcJ3GVvR4 ldzuoVt/DXTRokL0QYBdU/PVqDtHb2wbxN9QbFZr/Xq11PfbtVKtVglK7cZlszRoBaNqpdfq14eD j17eDGkLhoDCh9uA/ZIflVfuqeajU7DzsWr/s9HzuVMHED22wehJrzR6itR1p0gwsLDfbzf8Qatf 6ldro1Ltst0s9UaNemlUD2q1Qb/VGwTDj7AordY6THGXit4VNwcYfNKtJxFTUsu5ectkUs7a/nIq 71EhSuR+dP7VSn594DoqP6i0G61qI2hYykBfaFn8Om0xVHT0LFbXNP2wdkcLLioQcQM3lILZebQ+ TsERHCV4YQ02Irc8pVgMiTNRXAGEK1xg2HJuHonIcA+pFVcmCrWdQFJGSAsZ8lnW7iY3OEi2NxX/ yfpMXacOLMz1s0+5zngE/8//BQAA//8DAFBLAwQUAAYACAAAACEAsgz+fKcHAAALIQAAFQAAAHBw dC9zbGlkZXMvc2xpZGU2LnhtbOxaXW/buBJ9X+D+B0LPdW3LH7GNJoHtxosCbTeI031nKDomKpG6 JOUku9j/voeUZFuOmtiOi11c3D7Etj6GM2fOzJAz/XD5mMRkxbURSp4H7fetgHDJVCTk/Xnw7XbW GATEWCojGivJz4MnboLLi//88iEdmTgieFuaET0Pltamo2bTsCVPqHmvUi5xb6F0Qi1+6vtmpOkD pCZxM2y1+s2EChkU7+t93leLhWD8o2JZwqXNhWgeUwvNzVKkppSW7iMt1dxAjH+7otIFLGPzOHKf Jr3VnLtvcvWrTufptfa3v66uNRER8AqIpAlgCZrFjeIx/1PiMXxp7rx+X0qio8eFTi4+0BFsI4/n AcB/cn/xEh3xR0tYfpFtrrLlbzXPsuVVzdPNcgFosF7UWZVb9NycXq/TWpt0wxn8fh9zEq6ty1+h EPFZse+GSAV7cxjUdImn+Vhr9bDkNDLucm49+7oq13KQuNXTJbFPKYCzwsa8eC6/6eEqnzce8tKO NVDd3hlI5NHqdNrhDmKDMBz23W2HW78X9gf+gW04crnpyD5OVPTk4L7Dp3cXHcXGzu1TzL0bABYd QQsS8cUtvZv/cR70zvphv4NAoZ/lRH/39jvjwe7rTDLrLri3YjlPmftiUnbNLFnR+DwYtPDPG7x+ AIoVZgIbOtJYLIa484DLxrc54g9rdrxBkdDWc4GYxE5jThGzhfH24pvhZEoNNx8g0IJ3EOXkcRld U01v9hDr/AVlPGdLaOCPnDEv8yYsQ2HDm85P4Y2IEBQltfanTBgOPISAb9AZOPZUomxw1u84x3jO nHXaveIJwJEHqYchJ2+JzCuk+bEz2yBBQNbO9IrAf9P2iIwNHGhchiNIuuRKIoUy7n+rBRkzxlNL 7xCUO07ee7E65syRB3lFYM4CTwVPThKvwF2PesGqWpa2X2fpVEmrVRwjWA6woSq3AIwCDWOIVURy +6A0EpLDzHC9QqUw5A7BEBEliV0egld1rTq8aNVJFeQOgKc0Q9L4yQhD4OClMt7xTaVLo1z5tXxj zLGr1RmSULYU8g3gcI3ajZJRk45SrZx7HFlPqfJbScPAP0TXKVV6vyPspYTb9klmO/QrobZ3GK9z RjgiE76kK6E0jckXJYVV2gWXC4UdxfaWXufPrVRUEVvR3xXK/6eKraIccYt9FLaoB/qjmoReyRQZ Uh65K1hAMvOW3FrneppZhX28rzvCVST8cCZVeHB44ltolWBTpIXKDDEqQ6Hb3bu8wNgqQnVq/6Nx 2RmROWeZFvaJFDWP/M61wCEmB+/U8bkJ/R23vJiOnu1Efm44C5k5Z+9ouLeXyzjY1F/UTFfdRZLG fpe0wZYvFi7yVly6TcKxK9bxCmua0rXHyi0scdUIu6GtvcqpSnKxwAmqcCGJ/K9Vzm4RoZxcPTJ/ eHU7sBthvvtcPVXglKCSHbI9qoZTHXk+bfLnDnf+LXE6XyIlv313vg4RJDq3nUVLSPvopHH8RNC5 4SuKU852PXkQFtvRk8aqy7KUafWGFFDw3+oMe/M7laEXpgWOF3md9Wbyd6SokThw7Lh17+RWxxam kiSTZclwLJUc2eLYJQpTHChFa+5YSXXK/qP1tjc6AJXXw3Scb3kOcmdVaoH1TGkujWCHOK0qqA7q T3LFjRX3PqB2fPhvySM3PFE4uO5ot3c4bLjqskesGI43DI2DYjuNVI2uMpXijyKpvCsPzIhFZJxj l61DG+v7g/mxMgtTtlMdmhb32JkgI3JihM0KIwh9oOCLb2ssqSUPIo59Q+N4HOsMoq5T8lbPCJlm 1nVfuEReQpkUkonIda7Wh553uLZFVO+Zo5etMwRd/BTtf44cj62esMjLb3RSNYk92w2fqueL3mH2 FRMVUMOt4RqLL3dq0Y/c7hnugvFMURrfoznMrD5dn7pW5x/Hc67xne8PCf933fbY1d71q7Hfcm1O Qy4vL8k4iuBMhc4YyiwnzLW1caPi29xk9GXLfuxenepwiIlWPrT56ILvOqaML1Uc4Qi9R8Pa+QsD ohcmGpHNO/ZLGi8CTIlctzpv+Ls5kHM0BMj1RKSccEg1Q6zn4g+cTtS74EWwx9k9Cd+RsNUOT4Lp sMR0ppDzdQXV7utjgNdRXTgiu0HIfzOqsUKJ7B6DgJ+HLNR2zP10dTsj8/H0C5kj/5EvnFvsn0+A KyYSJa7z2In+miV3O+j2ToEuRrkQXQuwH/55xv4M6i4wQ3aD1D/RzWl3J712YxIOu41ut9VpDPsf zxrTQWfWbo0Hk97V9K+gGBoaB4aEwvXjst3RGLJr4an+xilY+aWU+8Po+VHW8cmnHBdjdvvZYASX +ikumkCwcDIZ9sPpYNKYtLuzRvfj8KwxnvV7jVmv0+1OJ4PxtHP1FyxK290R09xvCD6VE3ZcfDbV ToQ716iFfY9TQjMfjzdT9cB1qoSfkLdbxZjdTx7dAOys0x2GQ0cZ6Asty0+vLS6Vk28W6y80/W3l UwsG+oi4qb+UgtlFtG4eQQoWCW44g60sLE8pXobEW1mOyqMMwwIhMUgV6FLzAIdAzDY05qWS478g gOoq4rf5WDi5QSJZT/TfZH2urlcHFhb6uW+FzvgK/l/8DQAA//8DAFBLAwQUAAYACAAAACEAZejR 87oDAADlCQAAFQAAAHBwdC9zbGlkZXMvc2xpZGU1LnhtbLRW227bOBB9X2D/gdBzHdnyNULswtdF gSQ1KucDGIqyhUokl6Rdexf99z2kpLhp0oXRpn6waXJmOHPOXHjz/lgW5MC1yaUYB52rdkC4YDLN xXYcPGxWrVFAjKUipYUUfBycuAneT/7840bFpkgJtIWJ6TjYWaviMDRsx0tqrqTiAmeZ1CW1+Ku3 YarpF1gtizBqtwdhSXMR1Pr6En2ZZTnjC8n2JRe2MqJ5QS08N7tcmcaausSa0tzAjNd+5tIEkbGk SN2vURvNuVuJw19aJWqt/fH9Ya1JngKvgAhaApYgrA9qMf9XQAyL8Dv1bWOJxsdMl5MbGiM2chwH AP/kvqFEY360hFWb7LzLdh9fkWW75SvSYXMBPHi61EVVRfQynKgJZ5PbgpPOU1SVKIXqrWSfDRES cbrwq/DY/aEx5mJ25tWO2JMCMsxqb60Wrc49JI2KAaweL3ucyfTkYn/Er7NDY4EMmu6tzHLr7vr2 qDA2saeCe7QQE41hiKQ829DH5J9x0B8OokEX+UxvxUx/9mztqNgiCdd7wazbcFqFSBRzC6PYmlly oMU4GLXx8T4/CeBynwA09p5pXFbA3DjgovWQBCTNtT0TZScPhpM5xdciN2xvXIW5AKwPAyacPXyr uIkby4qbHzPUaxhaUMvJuqCM72SRck26zlmkbkPFT5GVWlQ7oNvRIguQ4Ui/ToWCy2HHyGXMeUpe 5cfhDIo+VZVxKaLElHZecIoWVVeHnUz3WxK9I1G7Ez2DFZUj0jXVFHf8mKCfAb/fgJ8UecrJ/b58 BPDfktB7CxLQV2G6IuLvPdWW64aLyGfkb+YiQ193ze3fWaff7Xfa3dZsNVi1eovlqDXrDK9bi+Gi O1tG0/ZwNP0a1HVuHCYCfjuGX9TGC/7qSnolFeykf+YTvjh7v4vRQcPoSkrA/IzL/ltwmVlw5yrq OyKbzvkGRXVZM/qw3KxIMp3fkcTl7h3nFn3wDPT/9CPflppBiKl0a9DClJ9Pe527PJldD6L5aIbs 6Lk8uR62pqtBv7Xqd3u9+Ww0nXeXX5EXqtOLmeZ+5n5o3g7YfDGvy5xpaWRmr5gsw2rwh0p+4VrJ 3M/+Trt+QPhmHXUH19GoP4g8Z/AXXvpW1XiLrWams0LfUfXx4GHDUwW0z/2WAh5uxED0LILmnJc4 cAFbUUeuKJQhthHNIyDd4wmTC2RzLnLLA4LXhUXljgPB8bhClsmUb/w8tOUn5NrTW+WXoq/c9e7A 7do/t6p9xhLNZPIfAAAA//8DAFBLAwQUAAYACAAAACEA6q2MHQIDAACNCAAAFgAAAHBwdC9zbGlk ZXMvc2xpZGUyMC54bWy8Vtty2jAQfe9M/0Hj5xJjB0riATKEkE5ncmEC+QBFlsGtLLmSINBO/71H sh2a20weSF5sWdpd7Z7dPev+yaYQZM21yZUcBNFBOyBcMpXmcjEIbufnraOAGEtlSoWSfBBsuQlO hp8/9cvEiJRAW5qEDoKltWUShoYteUHNgSq5xFmmdEEtPvUiTDW9h9VChHG7/TUsaC6DWl+/RV9l Wc74mWKrgktbGdFcUAvPzTIvTWOtfIu1UnMDM177kUtDRMZmInVvU841524l1990OSun2h9fraea 5CnwCoikBWAJwvqgFvOfEmJYhE/UF40lmmwyXQz7NEFsZDMIAP7WPaFEE76xhFWbbLfLltcvyLLl 5AXpsLkAHjxc6qKqInoeTtyEM8+t4CR6iKoSpVC9UOynIVIhThd+FR67WjfGXMzOfLkkdlsCGWa1 t1aLVucekkbFAFaPl92cqnTrYr/D22/SRBg7s1vBPSbwnCawjwcyIKgrUi5bt7OApLm2HiZiCjsW nKKcayTtcJT+UCst+0DEIiG1DS7TKdX05lVTLjqa4FL42ziHZQXg6zAeNjCeUcvJVFDGl0qkXJN4 H4imFi35G0VORRagDFEjkY/Uo+rg/3B4VwsSfyFxO4o/COJOA/FM5CknV6viDvD+D/XhPqAGxcF0 BfevFdWW6wZxn8r9IJ6BSB2b/OmNjg5HvVG3dXzam7Q6vW7UOo7iuDUeH51ORp1x3O1Gf4O6sYyL XMK7F9vhWRNUTebqP27vkoSrnfp7dUK3SdO5UsDuUYI6+0hQZpEQ1wxPstMw0/vTjeclO/w+mZ+T 2Wh8SWauIC85txh2O6BdV75CJZ5RqkGDZTN7mNCXtLxee7bDSAV8Y79Vwq4jJojuRMBPeYEDR71W XhiwHDiYQhlic9kMq3SFUZvLlGe5zC0PCKagRVkPAsnxE4BsqZTPPW/b4gY5e5ipUefZVC1yppVR mT1gqgir8RyW6p7rUuV+QkftasxX7np34Hbtn1vVPmOJThv+AwAA//8DAFBLAwQUAAYACAAAACEA 4ZB+t6QDAAA+CgAAFgAAAHBwdC9zbGlkZXMvc2xpZGUxMS54bWy8Vttu2zgQfV9g/4Hg8yq6+C7E LnxdFEjSIHY/gKWomFiJ5JK0a++i/75DSnRuDjZF077YksgZzjlnZjiXHw51hfZMGy7FGKcXCUZM UFlwcT/GnzeraIiRsUQUpJKCjfGRGfxh8vtvlyo3VYHAWpicjPHWWpXHsaFbVhNzIRUTsFZKXRML r/o+LjT5Cl7rKs6SpB/XhAvc2uu32Muy5JQtJN3VTNjGiWYVsRC52XJlgjf1Fm9KMwNuvPWTkCaA jK6rwv0btdGMuSex/1OrtbrVfvlmf6sRL4AvjASpgRYctwvtNv8qYBs8xM/M74Mnkh9KXU8uSQ7Y 0GGMgfyj+wUjkrODRbT5SB++0u2nM3vpdnlmdxwOgAhOhzpUDaKXcLIAZ8NtxVB6QtVsJWB6Jelf BgkJOB38Bh692QdnDrNzr7bIHhUwQ6323tqtzbqnJJgYoNXzZQ8zWRwd9i/w7/yQXEAGTXdWlty6 sx4vVcau7bFini3ARHJwhGqirzyTXBQg8IlO703Dhoq41LY62txhVHBtH8i1k4/CMi2YRe4o6w9s DJ37162Rqe28YgRKqFXPThaalNZ8pyOPBWy5oTvjavJZHEwUt0STuxMOJqLP66c4IHJgAygOfMJj o/nryneD8gtiGbqtCGVbWRVMo857JEFhoYv8A3VJqhJD5UBap54onwhO6bdlhKfnrO5On4KVQEyT Jr5UQbKnuj1n65xu0909yv5AWZJmv4j8XiB/XfGCoZtd/QWIfyxC9z1EgH4Nrhsh/t4RDZketMic /5+tRQn3hWua/87SXqeXJp1otuqvou5iOYxm6WAULQaLzmyZTZPBcPoNt/3DOE4ExH1WyRd11+p+ JhXsJE0fBIVgnMOfVU/9IOlKSuD5iZi99xCztCCeK6lnSoaW/D199pWq+p/a8VbQMZebFVpP59do 7ZL3mjELt/wD0a62X2lIvi+FGxauuysDHVf5i2+nuUuU2aifzYczSI+uS5TRIJqu+r1o1et0u/PZ cDrvLL9BYqi0m1PN/GX+MQwl8PHFIFBzqqWRpb2gso6biSJW8ivTSnI/VKRJO5nsSTXGnVGaDYZJ Jxm1BQJR+kIJ0QKEMCzQSl8T9WnvaYMZCGSf+08K+GjK69EW6M68hgUH2IoWuSJgDB43IkwXxQ5m I3eTlVxwyzCCscVC6Y6xYDC1QZbJgm38RWvrO8i10xD0Q+ibcH04gLCNzz21MTvloID+AwAA//8D AFBLAwQUAAYACAAAACEAheuT510FAABpEQAAFgAAAHBwdC9zbGlkZXMvc2xpZGUxMi54bWzEWFtv 4jgUfl9p/4OVp11pUyAECqgwImlZVWo71dCR9tV1DFh17KztcNnV/Pc9di4tFEovU+0LmMQ+Puc7 37lx9mWdcrSkSjMphl7rpOkhKohMmJgPve93E7/nIW2wSDCXgg69DdXel9Gvv5xlA80TBKeFHuCh tzAmGzQamixoivWJzKiAdzOpUmzgp5o3EoVXIDXljaDZ7DZSzIRXnlevOS9nM0bouSR5SoUphCjK sQHN9YJlupKWvUZapqgGMe70lkojsIxMeWK/dXanKLUrsfxTZdPsVrnXN8tbhVgCeHlI4BRg8Rrl i3Kb+ylgGywaO8fnlSQ8WM9UOjrDA7ANrYcegL+xn3AID+jaIFI8JI9PyeLrnr1kcbFnd6O6ADSo L7VWFRY9N6ffb7fblUnfKAG/zzlFQW1dcQSDiCtJHjQSEuwtYJDxAnbTsVJytaA40fZxYT25WVZ3 WUjs7dkCmU0GwBlmOC33FS8dXNV+7SCv7KiBCjunQCKHVqsThLDcgqwXBP2ufW+Ba7XCdrPY8RSQ QnI2MOtIJhsL+D18O4fhAddmajacOqkAFx6AHojiKxGpB2evNRbYfJsLYkpL8QBMgw/YyeHt0KPC /z71UMKUcQ5EOjUxpxgCrVTYjOJcKeAhuvTP9RnoZ4AvThB8wsUARqUgLAvPvey/8Ln/2p/iP5YA OSsXv8917dOWddNh34WdoNPvOv0/0XfWa1xMM2IXOiO3xKAl5kOvB7xx6sHl9Yb7fCKFuVs7re/z G0iLsLTustSGuBXJLVb42y4N9D9DD0gLrDxIiMLnzvGHyOSkgF5PpDhFzGgsMN9oppGcoSkluWJm g8a5kZCBIUUiyOEoBs2ZyGWu0bUUzEgFHEa/Tcfx9e/ou6Yoxppu8/CIQU6VfOhpMX+i0hbTLSgL zsRDzBl5QGpgM6e6TFxaAZMfAStgtPvrmONL8INj2YuIOFw/pgbErb3ZjGwp2wrFd9x8zOb6MqiZ q9XqhFEzc1WSJbZQzoy/wtxQlTJFfY1J6uea+sR6x2+2TszafFTDkjVoR86jM7aT2CN7X0a5DIWD PnyH/F2R+7PsC4FRxABN0F/XVy4EbMI9xwajizVxVcsFxw4Sr75mi+wlrNdY4Dm1jcqW1K0AtyXl Q/Q+RLIqX9YkK5uzo0QjkB5AZV/RTGqbHTZ+s7mHbMedWKe4Xecdq6PWpjrV/v+5+O31FzJz0RIC wSi65ZjQheQJVegVZdiiBe3nC/1SYqAfh0qywHzmQQ9qa3BRomyXaVMYCBB1v1X1T0JOGOeF+Dd2 PvvjoHbwPvaP8zkK/kBBsxXsof/bMa3b7ImUkBS3UA2PNzfHUZ0ZVcD6d44V3FAh+4r25vOQBbVt Obq8uJsgW6HRlCUUXVMKJXz+U3ANKq5OuRV9k6f3O+h2fga6MCiC6L0AFz3AZ1F3BhOqbTb+7TSj 6Lwbtf2oexH7Yb/f9HvtbtsPOpPzaNwZx3EQ/fDKkURbMAQobPGHHLpTCHd7eMhopaeesh2utscP ZcqD4VNUiOchAk8ep1EYDa80TAqZGxKh0wMTo6jfDeJe5EetcOKH5/1TfzzpdvxJpx2GcdQbx+2L H2BS1goHRFHXE15WAzw8fDY0p4woqeXMnBCZNorpu5HJFVWZZG4AbzXLKd41y90w6J72mz0XkKAu KOmSUaUsPKrmasLVNc6+Ll1qgb8LIOJi9ygDZpfR+rgFRiCWwgtrrxGl4RmGwyDxTlSDeJLD3whM JHTGoLOlHoIJ30A0Dz1B4Q8OoLpM6F0xdKbfIJHU/xd8yPhCXaeO9Vqhn12VOsMS+D/6DwAA//8D AFBLAwQUAAYACAAAACEA3pj3Y/8HAAC7OAAAFgAAAHBwdC9zbGlkZXMvc2xpZGUxNS54bWzsG1tv 2jr4/UjnP1h5ajVRSAgQ0KCCUKpKOxsCtneTmBItiSPbdGXT/vv5bCdcQkvTrp3aKi/gxJd8N383 +/t4fhuF6IYwHtC4a5hnNQOR2KN+EF93ja+zUcUxEBc49nFIY9I11oQb571///mYdHjoI5gd8w7u Gkshkk61yr0liTA/owmJoW9BWYQFPLLrqs/wD1g1CqtWrdasRjiIjXQ+KzKfLhaBR4bUW0UkFnoR RkIsAHK+DBKerZYUWS1hhMMyavYeSD3AzJuGvvznyYwRIlvxzSVLpsmYqe7PN2OGAh/oZaAYR0AW o5p2pMPUYwzDoFHNTb/OVsKd2wWLeh9xB3BDt10DiL+WvzAJd8itQJ5+6W3fessvd4z1lhd3jK5m HwAINh+VWGmMDtGxMnRmgQgJMjdY6aEYpn6i3neOYgp4SvQ1et7nm2wxibNcPlkisU6AMkIulY7T nYoe2XiuaJoBepwSbdO2azUgkqSHadp1+SAhyKbDynq9pCNuB9RfSzrO4V/xAXdCLqZiHRJFX6AC 7gCs8APcDLEUeBJXvk4N5AdMKJIjHgk3JBi2RsoV0ZtImSM+urgNuACBRtOEeAHIppZEdGKdSoiE gkutT2J/jBme3PsZjQMABAhkgCtcJCWvGU6WgTdiIGiacZc7b/ISaWcsdGksQMDROMQeWdLQJwzV NwzNL4H3PnMfk/OzpGBv2B34IKypyIDsfuJAgURJ8YoFXePX0Lb6Vms4qAyGdbNiDxy34tT7ZmXU vLhwR5Zt1y3ztwFzTLsTUf8qUy7wfLCho8BjlNOFOPNoVNWaoZrQH4QlNFDKwaylGuYGh12jbpsN 22m27HYqiQCgonYGqJJJiYpqHOKZ26itJugwtVl3xHC7Zdu1ZsvJBLVhNxptSwtqstnx15qHUvzS 5hALjBSpHq1LBZ7DHpNriXmY/oGwLQLGxYT+UHpqDjo8basRcoraDFd+71fDtayGbfcrrYuLZsWu 21ZlULOditMYDN32aGi69f5vJdW709SLeSjJpr58yQJQmxKhwHdpiOSHzRbg35RU339vW6163Tl8 77RbDcs6eF+3Wk67dvjetByn4aj3cs/NwwwGwdAS+N6qOXZNU8ZTUL6YWnBXjMn9BntHKYKn6wDA YwOl8LQJgXca/hfGYrSKPWlQcYj6jOC3icSeQn6bKIxXoMk4eZvAX40nLwG43OBa1bzA3uY/pbKS Ovuo8f98NZ0VxO2OFbd2/oX3+B3fvsuV6XNOBJqQhDLpybwfxCSbriao1WzXO0hjeeWDdt64acg8 M98Puhe33hL8V4LoAsIShedaeqZY8TdhEI0Bgwk/e1Moz5XfcnQ7ZtFgZw8xUBTKuT/i4RfcIFKO 0Hg1DwMPDakMWfc+BMGFUkgHAUSB5QHIdLL0S46sUIAMM4Z9CLvZ9w7Kwfdk8EBB9T5DxJ9b775Q 5g6Eiyi7UqUXjknvoPC9Kj3HtIeEYI45CQOZ3XnI/L1vW2FntmJjEdFIJbDQSX8yOn1fNmOLoy8D TzynK4FgwyPKCIrkj7Ier8xmQLYIgaL7pEQVGhPVCGJp9FQTh9eQrAnBjSOLGZ5Pwa3TaSMDMQGZ AJBwgj/FA/ZdWZcFZEn6agpeCWpAGggcobQbhkqrCoZ0LKMiOV6q6jCeJioK44k39gRSCQbwHLfJ qN0RA7KQk+RYwfXYLGcF77a9/QUkJO4dl/bOV27IZrcqmJ6vpj83zRGgsXmQalsNgbQAZGFUE6gB 6adUJeuA/UGt8Czmt2TYX2PYUU+p9GT2jOKei1g6NbnIN9UTkA0t41RQykdPEEoF93oUnAz5HdvJ 3LjpKgIXYb11WsGPm05OM6cODjvv0AmvReT3QLvvoGobFDzCh9eHsgj+EHh5+ggVkgWCIow8GoZE ZYBlLqH0AEsP8Hg+tEACplSQr0dBlrkseeyrtKn2AI9oe9mlYqSXOErcKu6jXvvoavKezhumHmXq xsSaCxLlLNwze+HAvT8/Ky3Ipuy4wa430AekmIYuV5CJ7yCXRhGN0bdVGBOG50EYiHUO8QcD8eLp uX0CP2sy+MT9Np2eIisH/Bvm2h5PENey+arQK03nXzOdBU5ZCvg6D25llVP7Tpi8a6muEBXw21Ve kIaBPwpCdbuHs+s5JAJ1NnE02sk88t1hKpepbuEt4ApY1/gQxZVQ6Ks1BOc6CNYdHs91eFx2SJuZ 3vPpaf12ohTc6WN1TAF8VcJS9KroMGeFTrSq3b9hp015euhXjAXFwXj62ZoWqQJfehqDd1lyfn7+ aMWVk/gnA7G1AEpM5C3G+7NGsusZnKpSMf41xXjUP5W7cU/w9FY8IgCPdMtKRr8ORu87liXL38cR 34N7WyZUGzWrg05cF7z/F+X7Q4b7KLBw230RXK+YunqLAs5XpPToy/PrB25zPoNHf1QqDx3YvR20 uQGWLwwpkHYAE1teH0u9Sfkn6x7gf6eWYvcZ2vlCGlVfk5V3ZWUgu/Uqg0G7abkO1KuY9qhiD9ut Sn/UbFRGjbptuwOn79YvsnoVD+7Ky2vzz1q0YpoNKIlp19q2isAUbAqRDFpAIatU80L2H06+3Cgl CgV4gjCIEOFVAvk2Gb/B0O0QqDIKIuiQBToiTit1EgyTYdgszkrb/BXrGvJuzSKIA0HgBg2BUkAG N2FiAiWDUGlEfTLTVV7RhFKxqcD7o5IdDa4CB8BO4ZOtFGZoQulh738AAAD//wMAUEsDBBQABgAI AAAAIQC0YVhygQgAAGROAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTE2LnhtbOxc227jNhB9L9B/IPTU AvXauvnWTQpfFwb2YtjuB9ASHQsriwJFZ5MtCvQf+of9kh5Skm0568TeONtkqxeblklqZjgzPDOU 5vVvN6uQXDORBDy6MMxXNYOwyON+EF1dGL/PhpWmQRJJI5+GPGIXxi1LjN8uf/zhddxOQp9gdJS0 6YWxlDJuV6uJt2QrmrziMYvw34KLFZX4Ka6qvqCfMOsqrFq1Wr26okFkZOPFMeP5YhF4rM+99YpF Mp1EsJBKUJ4sgzjJZ4uPmS0WLME0enSBpEtw5k1DX30n8UwwplrR9RsRT+Ox0H+/vx4LEviQl0Ei uoJYjGr2R9ZN/4zQDY3q3vCrfCbavlmI1eVr2gZv5ObCgPBv1ScG0Ta7kcRLL3rbq97ywxf6esvB F3pX8xuAgs1NFVcpR3fZsXJ2ZoEMGTE3XKVdKYa+5d7HhEQcfCr2U/a899f5ZIpnNX28JPI2hmSk mirrl/6p5ZH3T7RMc0L3JGG6llPbE0fLdHANklJCaZhuq27p2fMpMHs6Z9yWN13u3ypZzvGt14K2 w0RO5W3ItIwhCdoGvfjAioZUKT2LKr9PDeIHQmqxk2QleyGjMI+MFHk5UXrHfDK4CRIJpSbTmHkB 9DPVRvKT/fNrSF9i8bP5WeSPqaCTg7dRkqRtEAQGcsI1L0qaV4LGy8AbCihbunhvdq7sa6WTL2OP RxJKTsYh9diShz4TxN4s6v4UtHCbQwu9P0op92bJAx8Km6kN9PdtAgnEWpPXIrgw/ug7Vsdq9LuV bt82K0632as07Y5ZGdYHg97QchzbMv80MMZ02ivuj3IHg993jHoVeIInfCFfeXxVTb1DNeafmIh5 oB2EWcu8zDUNL4ym2zJdN9MWTZSWdU6m1krFiG7c5XLPVDPVVPbaatXq+1raxL2cGtyD0lK30TLh 8zIjyCe6SldQKV/W7FNJiRbUyd5U0jmsTM0l52H2BVVbBCKRE/5Je6o5vHjW1j3UEG0KI//yD7dn Wa7jdCqNwaBecWzHqnRrTrPSdLv9XmvYN3t250+t07vD9IV5qMSm7/xGBHCciqHA7/GQqBtD6I1c PLvXnZptu5lF7V5v1t26ffe6bVl2o+UqIRbnt+r1llXPfAC4z2mQgiyxOJZjWo1UMp6m8smcQm8t hLI2WI52A1o42qq1eE7wAJDlhkrppZsIrqX0PzEXw3XkqS2VhqQjGH2ZTBTc8ctkYbyGH0vYyyR+ NJ48BeFqS01dTWrbdsuFp9BWfYpVAHKQFRVvNeBCY6IbQeTDenWThlfY7UOAALaY0fn0M/yIhh0G ERJbiQLJ9G3UFR+1Y11gm+3oIXQtuQEcAUyQ/Y2uS8AKYISxMizVX9EbRtNYk5zE3tiTRO9QJnBN tk0Ue3TZQg1SfWWS9k13E31t+29ngf32YL/s3/m6F4rZjfaj8/X086Y5BBubH++B9nUX7CzYxnUT 0gB+QVMBldTn69W4g50SCMwENw+gqPej6aygJhkAOpv7Kxf6eSz0SFnWBh6XS75r/Vvr/e5sezQh jXrLJf/89bdqNNukx1crHql4RKrUABlECOaFRkvkp954UIyazu0OHuWsxoL7a3hqxPtw5r9gA5He UrcAqxEtpqBJ3P5K4pw7GschQsJ5EAbytqD1iO4PxINfcJ2Zw9Vu90y4sHSM38wxzjVEuDebkOe0 2gUdSbVfpwQO5Si2yjKnCQsDlaA7ZtMl4/Ucmkn6XGXhHnFXzdvx954J6iM9KD62SeGmR/B37J00 /uFh4A+DUAfCibiaA/CkqGk43EFYybYbZA0Qo8bKy3ej2WSwR97D1rq3zF9NxvZOKcy61+pB9i4e BuRqAhFrgJkFi5sw8t4MWOkOvpk7uNcRlIBY2d3/AB11BLCDZJ5cC0aqZMIWDKkjj5F33Gdhwfmk 24Cy9I0tPyolVNr687D16Zg0a7WKadWFVdz4j9gNj97tiwcTBKCbTHudcUHDTgKj+6ch51bPhzD6 8WBD8Vlk/+u5LiF47L3cQHUPm+2rsAJ9R0Dw0nE+D8epQNI9AQwOex/yIQcxGJxZNljh93vSmkdo 1NfHOgfJU4qq8rIFP5Y64CxM3EYPSELvHGbvBIrFcPQ/iVNaZd5e5fK3DrXM2xefyChd7fNwtSeH KZkbKtfvbOv3sEc/uF2cG5qXq3q2Vf1qhKIhAACQOlpptFq/kAaCSJyrdAbTzmRaGRYTlwVsUC7f 2ZbvGRnlozRpm3eiuwkplSXw8DBAEK35OiE4sQskFzjr+rWAPM+ap9ib+QQJl7H5LpR8aYfIR0RS ZWx+6MmfZ/lETxmbbx77fhCBocPuAV4ZGJcPtJUHtXefcHx2fu7NOvCpOq+rklGUvuSkH5kuoJgH rR/GXz62ikTYC0t/5Sd3ZkOYT3hyp3SMEckJ9XmsXzJSD5qtE+Dw/80Z3tPJoIwayqihzIicLSPy qDREeaJ3Gm4oo4aXluU4mKPP87mnKUAJHNO3nF4YcDwhaigP0rDCZ31T7YSM8v4DQmUg9/2+f6gP 0tz67hEa+YB6KNcB+/QFp1za5Xdsl48CsaNIpm+IIRFEVKSeaxHhi0Pnsyc9eVtGrGXEWkasZcSK Bzj1q/VHnJx+22dQVVh64B2VLGJVX6o8Db53St7s/kZ7v9qRLoKU1+HKq/XsFhXqdlEDqtdEUSHT GVacfqtR6QzrbmXo2o7T6zY7PXuQFxXyUNJEVTc5a2Uh06xbds2yW3mJH1CpGcmpBQt5STEvFO9o /OFa7zWolCaZwNuJuBQjr6tcPLpuu6AUVKBeN1ZVlGSUlVOKKQaj2yzKa5D5a3FhqPoViwCPajBU qWCo2SZQbSJiwDIoB4XXimZpOa7VhHO5KZX2qLpKKbmaHJCd0adaGc1ookbc5b8AAAD//wMAUEsD BBQABgAIAAAAIQBvD2pz4AUAABQWAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTE3LnhtbOxY32/iOBB+ P+n+BytPew8sSUhCggorCFBV2h8VZffdJAasdeycbSjd1f7vN3YSSGl719vbPanS9qEJjj2eb/zN eGYu3hwKhvZEKir40PFeuw4iPBM55Zuh83E578QOUhrzHDPBydC5I8p5M/r9t4tyoFiOYDVXAzx0 tlqXg25XZVtSYPValITDt7WQBdbwU266ucS3ILVgXd91o26BKXfq9fI568V6TTMyFdmuIFxXQiRh WIPmaktL1UgrnyOtlESBGLv6nkojQJbdsNw8VbmUhJg3vr+U5U15Le3n9/triWgO9nIQxwWYxenW H+pp9ieHafDSPVu+aSThwWEti9EFHgA2dBg6YPw78x8W4QE5aJRVg9lpNNt+eGRutp09MrvbbAAa HDc1qCpED+H4DZwl1Ywg74iqmoph6VuRfVaIC8Bp4Ffwsvf7RpjBbMSXW6TvSrCMNqLqedVHa49m vgKbWmPpw0Tkdwb4Cp5GCB5woM94p8WaarQWXN9kmIHIxIU/K7I9mSl9o+8YscYDiHhgZUg4KoYN mwnvfLxxUE6ltvZEqtApIxh4X5tcjxaGUCRHZA3U1QrdUr0VO41USTIK/KvYdgGW1XCw9RaE59dY 4sWTOxkr4QHoBNAbnPBaHcRG4nJLs7kEIlUHc9kaOWdc0BxRCvYAAqNrhjOyFSwnEvWMUYC+74Gt J6GVLdvbPHWI56sMcY/HSXMgY00J4OZbBRYoLUt3kg6dr9PAH/v96aQzmfa8TjCJ007cG3udeTSb pXM/CHq+982BNV4wKER+1QQP+P3AYQuaSaHEWr/ORNGtPL9bilsiS0Gt83tuHUH2mA2dXi8K437g B0nNNFDQWrtR1HLOQLEvD3GeOaLvxxFQzHijl7hhTbeTT8ZBGHtJ4iDjmV7ihz2v2bmRVNvb8LB+ nWKNkbXVvw6WGq/AiYwsvWL1A9i2plLphbg154JWEKTrdzvDLLEOcZWPvoap74dBMO70Z7OoE/QC vzNxg7gTh5NpmsynXtobf7O0bi+zAytWEQh2vpQU4qIBRPNUMAQb+76bxJU33h+P4r4b+uY47o+7 YZy4wYNxL3QNRezxWZTNXlqiLRxw340Dt7JAZuGdhQu7zw8JAelOSuNY4CTW260RrAMDfYACz3d2 wHHUUmfVXQBjlf4/G4UoSriwuX6Z6l/vwNMVeZnKX10vfobi5tKxFPzfXeLd1XIx+xmQjt5w9JPq 8v+B3iyKQnD0acc4kXhFGdWUKASxEs0OQLEd5IHoVfpp9sfLxNcGdgc5KXj8MU95mYiWEudQQ8jP A3QGwJL/QT63snnz41mdCdhKMJrPKbP3ppKbVcokslnDfN5KJFvTTF5X33kjS320IBuqNJEkP1Pp qdvgTKnv1uMk395AJoV8+lb5FSAeZ8jj3LAxRo/SKkBAOr2mm520Vz6acSgy6/dXafpSg8N9UFST 4leEgKy+Xfd9t2fejxAvICyY6GCKB3i2CpL2b3g3jYJT5WgKvKe7BWFTii6hypqIA7JZvS0/TXWP TPJ7KhnbzZB28W8OoKmZ7rVBgiiIoVNUVQqwg22GJF4QmGrMFl5B5EVRWJcMjYwSSqJLIgpkXoaO JJl2zB54DxUr+DzAb6aYYS7M1WDGDdSq2D1l7VU2gm7BJkNH/bnDkjhIagbFj7l1LHlK06GY01r2 qXnxsBgxRsFsA/2GTMsK1+MBS32BwgpwQlFnSzsor6HA+9swNpYE6S3cUEiYx7GB0T1rXbx5JlP/ QYXakNZsjbmsBWtDNn2zpv5uNwomkyTy0xgaBV4w7wTTpN8Zz6OwMw97QZBO4nHamzWNgkwSG5F/ aLfA70ex5yfJsWYHLa3ejbaApGkBZky+w+WHvT0o6GxCEgD5AwyV0MusaNOaAu0dWsAH4zia1y2S EsNikLjkTc8w30HHk/KcrCmHqAyUItBjlUBXTqAXC34lcrKs2mfFQgh9bG3+p15Jpa5VBxDW+pm3 WmdzgND4/AsAAP//AwBQSwMEFAAGAAgAAAAhADSMUEd2BAAAiQ8AABYAAABwcHQvc2xpZGVzL3Ns aWRlMTgueG1sxFfbTiM5EH1faf/B6ucN6VwFEWFEAkErARORjObZuJ20hdvutd0hzGr/fY/d6TCQ BAgMuy8dx5fyqVMXVx1/WWaSLLixQqt+1DiII8IV04lQ8370bTqqHUbEOqoSKrXi/eiB2+jLye+/ Hec9KxOC08r2aD9Knct79bplKc+oPdA5V1ibaZNRh79mXk8MvYfUTNabcdytZ1SoaHXevOW8ns0E 42eaFRlXrhRiuKQOyG0qcltJy98iLTfcQkw4/QTSCTRjE5n4X5tPDed+pBYXJp/kYxOWrxdjQ0QC viKiaAZaovpqYbUt/FXYhkH92fF5JYn2ljOTnRzTHnQjy34E8h/8F4dojy8dYeUke5xl6dcte1l6 vmV3vboACNaXeq1KjTbVOTpqtVqVSjecwe5zyUlzrV15hELEpWZ3ligNfUsa9DDFbn5qjL5POU2s ny61Z9eL6i5Pib89T4l7yEGcE07y1b5yMdBV7begPHDplgOdPHhebvEbJmlPWjdxD5IHvqAV7WE7 4fRSDcxdgOUxwenGhWJuBYj2gAAf7JRY7Udc1b5NIpII4wLPxGZuKDlFPKxM4U7GRufa8oRce7NM HM/tMeh1sG6Qhy/uB/QKJ4Ylzy+z3d5ku/UpbIsErlQZZAfRnpZnHtmK24dx6ZaNbhwjcj26R+c8 7LTabb/Bu2i70+wcdQP+n13P29DbvKLmgyb010s1yZkf2JyNmSMLKvsRgJbwcPl6w20x0spNlwH1 bXGNJIahN5cHBUVUMqaG3jz3BvujH0FbaLbTL0qbB8N/yPHCVYHlnVd5TxsaTh0nlEhhHdEzknAp kLnpreSW3AuXkrzy0kxgzkHXbV66D+IX6XkZ839Mzw2fCQV6VELoHFmbaEWehOiuuN9Cf3AWd0LJ 9wuCtGYcN16cS/m7RW5LKt6QTyDuT9ke9lm5vXf6j6bKLZRt02+IyBOqQNbUhYP3MiR9TTRoNOTP 8+mIfNfmDtmZXBhdPEuor0TmU9fbVzXPwcdywXtuXOek/z9p7f9QIRGWlc6ZT0JjSRlPtUxgyTe8 V54tVFUvlAGJQ5mJlJtSOYtQWvnHKjw1OPfCa6X0SEhZit/zmXlHEXBazEnzD9KMG80tYbs/p+vq caS1TzE/s9p+vQp4ndWZMyWtfxUhiVXMvqEO+DxmAds/ZyEBTE6HV2QiEk6uOEeumP8SXpuVr06k F31dZLfP2O38CnbR/0D0VoJDxfxprjtD4+W7j7878WBw1h20aoPu+bDWPjqKa4etbqvW7IzOBqed 0+GwOfgnWlXa1pOhANjzv1H9btS8ZeHtLdU4fLQKrvbHdz07OwuY8mXbDBHMVE0WhlXfxaS5ovnX RYhRtJMIjmGYyuEiK7d/3ILKUmRYCDWmurQoytFgUByGxKmqGrWkQJspVOLrBOF4RNABOoRFP1Ic ZRR8Rid8WjYl2Q0ict1PNtobHWUmmNFWz9wB01m9bE3rub7nJtcidKeNuGxxS7gBjle/xOdHK8ye AZD6LwAAAP//AwBQSwMEFAAGAAgAAAAhAPI/uzVyBAAA0Q0AABYAAABwcHQvc2xpZGVzL3NsaWRl MTkueG1sxFddU+M2FH3vTP+Dxg99CyaJE4JLsiVh2dkZlmVI9gcoshxrkCWNJOejnf73XslWIJAA WTotD1ixpXvvuefo6uri07rkaEm1YVIMo/bJaYSoIDJjYjGMfsyuW4MIGYtFhrkUdBhtqIk+jX79 5UKlhmcIVguT4mFUWKvSODakoCU2J1JRAd9yqUts4adexJnGK7Ba8rhzetqPS8xE1KzX71kv85wR eiVJVVJhayOacmwhclMwZYI19R5rSlMDZvzqnZBGgIxMeeaeRs00pW4kll+0mqo77T/fLu80Yhnk K0ICl5CWKG4+NNP8TwHTYBA/W74IlnC6znU5usApYEPrYQTJ37j/sAindG0RqV+Sx7ek+L5nLik+ 75kdBwcQwdapQ1UjegmnE+DMmOUUtbeo6qkYlt5I8mCQkIDTwa/hkdtlMOYwO/OqQHajIDPWmWrm 1R99PsJ8Azn1ybLrscw2Dvgcns4ITgXI57KyMmcW5VLYKcEcTJ6fwp83+XQyN3ZqN5z65AFEnHob Gqji2KmZitaPaYQypq3PJzKlnXCKQfdNyu1oSkmlmd0g5xakC9pCv+FS/Y4m4J+JSlYGfZOCWalB zOgCcmyB4uDMuz3o0YdmR1fMkMq4HYdumLG7RsAUBA85CgmBYc3YYd66gTcXJKga3XFMaCF5RjXq uEyBpgNHR7LIMtBgIPoAgQ71MyknvTPY5l7P7X633+s/U/Wg2+51znsRctpOBt1+f0tpbcnDrrUU MvGU7UPS6PScVy6mitzTrCKOQYj/nYoBMaIS6xu/FZnIIJdu6PDNq1sogJBKR1Atzzf01bA9K5hB 3PEMTyiIIMBAv0F1ATtaSPukayXC2RIL4nS54HKOOTJBzvhRzkZRwqCU1oUTQWlHNIe4rEGrgsG2 x0rxjTNioZYjbzaDamkQbA3t1PVTovd+SqoXx2+bfWgrQxHBhpqT3XDq7eP3kOfpCDqpyO6wxvev bd8PmH9DLftATqu5IZrNabqT8n89CPPnMOq4DfhYHJ3kC87Ew4Qz8oB06o47/TXz1QQCgLLqptiR O/gNnPyr1eqEUZv7sx4Od15iETvZM5HLnfBDrXye5z1R7CTl3SHFBpPymctD5L7ltNnwzrc/U46r EK96TXYSvgP1Y15/Qml30tj/TGTVMDJi8URsO9gP0dxtTvyt8hzLfwTJHU3360F8jIBXaffH4v/h fdv4bMG97DL8qRuaXuhAbwx0N8r3otAXDaO/xuPzfmcyGLfG7eS6lVydn7Uur/u91nWvmyST8eBy 0v38dwRr2klKNPWHzNdwT4CXL3rzkhEtjcztCZFlXDf5sZIrqpVkvs9vnzaXhSXmUKfOO2ftJOkn dSXysfl+KUQLEEL/Trj+htX3pd8QcC2xVE/8KwWHkMsCTH2cAi0XK+GDA2xFg1xhWAzTZiI0/FkF 1xXXG+QM2kAawRkOFyQNjYKgcJGCVkxmdFb3vuW9lHZ7L/kQ+jpcH46jrY7PjZqYYQgXstE/AAAA //8DAFBLAwQUAAYACAAAACEA/dgKsUkFAACZEQAAFQAAAHBwdC9zbGlkZXMvc2xpZGU0LnhtbMxY UW8iNxB+r9T/YO1TK3UPdoEEUMgpIUkVKeSig0h9dbwGVvHaW9tLoFX/ez97WRIIAXKXq8oDmF17 PPPNN+MZn3yeZ4LMuDapkr0g+lQPCJdMJamc9IL70VXYDoixVCZUKMl7wYKb4PPpzz+d5F0jEoLV 0nRpL5ham3drNcOmPKPmk8q5xLux0hm1+KsntUTTJ0jNRC2u149qGU1lsFyvD1mvxuOU8QvFioxL WwrRXFALzc00zU0lLT9EWq65gRi/ek2lU1jGhiJxvyYfac7dSM5+1/kwv9P+9e3sTpM0AV4BkTQD LEFt+WI5zf+VmIZBbWP5pJJEu/Oxzk5PaBe2kXkvAPgL941FtMvnlrDyIXt+yqZftsxl08sts2vV BtBgtamzqrTotTmtVqO+MukrZ/D7RHASr6wrl1CIuFHs0RCpYG8Jg+pPMZufaa2eppwmxj0urWe3 s2ovB4nbPZ8Su8gBnE2t4Mt55UsPVzXfeMgrO1ZANVvHIJFHK2rFTQzXIGvHcefIvXfAHUetzpE3 4SUepeC8a+fnKlk4vB/w6/1Fu8LYoV0I7oUCLdqFGiTh4xF9GP7VC1rHR/FRA5FCb+S5fvQAOOtB 77tCMuseuFVCDnPmBiZnd8ySGRW9oF3Hx1u8mgDFlnYCHNrV2ExAXC/gMrwfIgCxZ8MblKTaPpPB ng7B4MIQNSZPSj8Sk0rGyfXl6Iq0GycQa0E/CPTfMATYVgZjWBJhNx3iiuHPdGg45REklVc/hg5p Aq5XjPk2JsRRx7FinQqtRtPxw1OhFbUjByNmfCcXdnne7/+2I+N1RxKT2b7gFNl3qbo9HRRsSpLU sMK4vExSSeyUE6ayrJCpXWzxLBhU8XSvblwmd1TTr9toFjlyYu8lzTa1c0z1+xy82XcBMXpS5Fpa riW35ELTsTVkzXjP7Tci5gCgc2UsTzYk7oJnj8xX8IgZIh4pda9PdsDk6fumR1yM42gd2w0rDhbo 6WpPwycqAHSWah4ayrKwMDxk1HAT1iMSkjNJxcKkPtcMOSs0eEjOCqtwwDuOokQgfSVtKguFjDRQ IKrSyIjkl+FZf/AruTf8Hb7bb3Tf6bZm9H+A/hIsD/hLxBgsRzkRag5KOcMXYb3uUCsB4gn5Y3Dj 8cEsckEtJZdz5k9Mj9yaHTtJvR+YAZV0wl2RtCb129HZFRD/r3xxDdKlVJBcK/gBqANiDVaTMtCJ VT6RovYUjpkiNesYoerakRtjHN0flRtd/jy0PEBtUlyBYKO5p99DcYtSHEPnUVdO7dH6kIz+3sIg 7qAvKEtfkJmTO0EZnyqRAOsD6gOn/IsKwhXIG3VhYsuyZ0rFOECt7YqD8uCuJkOAXNWVVZ0o1VUq RCn+nSXe9oS5M++eFRMS/0biehRvCbX3Y9qpML1SyrH2JarN/VXXflTHVpew/ln4uKiQPaDu+nHI Qm13iPmq1R0VZJgmnAw4x1ky+QBcGy5qS64OhRN9W2QPG+i2PgJdNMQQvRXgsv/4UdQdoxN37ejf KC2j5nkrCs/jTjNE4dsIO0cXx2G/3biK6mft89Zl/59g2XoZB4aEwg7/1z3HZlmKVLP0VPPZKdh5 V/55M3rKw+h1hOBJ1XRjWPXhTOgBzb/MfIjiegGx0fePcjBkyfrnKehx0gwvXJNi5Y1BD4SGk2Ix JI5QTZeNe1Lg2iGV6OpSnBo8ILgRsIiKXiA5LkRAGZXwUdmkZl8RkKv7haj56oYhS5lWRo3tJxTp tfKqoparJ65zlfrbiqheXnmU6np1nPmlfm601NkhAFD/BQAA//8DAFBLAwQUAAYACAAAACEABQPG AS8FAACiFQAAFQAAAHBwdC9zbGlkZXMvc2xpZGUzLnhtbNxY3W4qNxC+r9R3sPaiVyXAhr/SkCMC 4ehUSQ4KRL12vAbc7Npb2xDSqlLfoS/QZ+mj9En62bubBEIIOUmknN4sy9oez3zfeDwzBx+WSUwW XBuhZCeo7lUCwiVTkZDTTnAxHpRaATGWyojGSvJOcMNN8OHw228O0raJI4LV0rRpJ5hZm7bLZcNm PKFmT6VcYmyidEIt/uppOdL0GlKTuBxWKo1yQoUM8vV6l/VqMhGM9xWbJ1zaTIjmMbXQ3MxEagpp 6S7SUs0NxPjVKyodwjI2iiP3a9Kx5ty9ycVHnY7SofbDZ4uhJiICXgGRNAEsQTkfyKf5vxLT8FJe Wz4tJNH2cqKTwwPahm1k2QkA/o17YhFt86UlLPvI7r6y2ecNc9nseMPscrEBNLjd1FmVWfTQnHot bDYLk845A+/TmJPw1rpsCYWIE8WuDJEK9mYwqN4Ms3lXa3U94zQy7nNmPTtbFHs5SNzu6YzYmxTA WWFjns/LBj1cxXzjIS/suAWqVm/CiTxa1XpYw+sKZK0w/KHhxh1wrUZrv+FNuI9HJjht2+WRim4c 3pf49XzRdmzsyN7E3AsFWrQNNQinJ/JIX3lzna1w5uFcMpsbStuwDA/MjDHaCbgsXYwCEgltPX/E JLYXc4pzlutrD7tTjqNFzvlC8OsDKGjhL14SntgZYBQa4jVjbjt/OK+ZS97xt/8m/IkIzllQ/GXU VWv7la3c1auVes7uC8mL+GRML0e/dYJ6sxE29hHmttDpiIzlKGXuxaRsyCxZ0BjOBH09eVAnn+CI ck79GP8Ge4beW7d7QpQIKYzVYiEo+ffPv0id4MuKTyAoyGhINT1fd7INm7iz532oeLg1C9iAoPXu 0fiJXl5yTb6jSfojORVybjkxTItLblYQ+XotzE/+JcXdJafbjXr3dI1wkc4NURNyrfQVMUIyTj4d jwektf+ILz9g7t0beWE46VE8+sKwuXEZk7ctrDw4qF+fcblNpK/pxJIVd3xGYPMXpj38+eMXS9h0 SSKz0BbRwAXF8JWj4tqdbXVpfI6Md7eY/UlCLcltjtqdX7RJyWm6HcYte3GNlBhxekPGsMOd8Ljg LXeCp24NjTyD2RGN3lxrpNRkFZXd4vXLdx+puWbcEJQcWzV41h26TsCDc51fqC9X/9xVMjwifIkc ABcCMSlnAhVPVt+sedIz0oAnTXj3cXeoVaoMsDlzJdHI8tT4UFD9P8TdbvQLHHc9zdv5HHrHs4f/ /L3iIJmbPr92qBW1Qx++SIYxZXym4gihd4cSAqpgx221XmSzyDqj8SRA/ezqhyyZdhWyy6EhQN7W ikXtJ9VAxHEm/pll22Yct+fh8ykJv38idK+XdjkNYaUavgoR9YKIgVLu5rtPRe3pau5pKiZWZ1z8 Ovd3a0HHDvXc29GRo+jzxlG3d0pGIuLklHMXEF8F10aB6yh2os/miasy7qNbfw100RmD6I0AZ42I t/L3CVpyri/1e787GPQarWZpMKhXSrVmvVvq9iqtUrVaqfb7zd5RpXX8R5D3YIwDQ0Lhjf2LBzkI qt2cqf07UrCzW/3YxfTokXssVPluR9Z9c1Elb8ixWJ/S9PPCn2v0GXE2ev5TCg/Jvf5uCnonAunS 1DWcrDwx6K2g80SxGBLHsujgRXMkW0LiHkQBbnlA0Bq0OBWdQHJ0RuEyKuLjrFuVnONA3jYaq7UH rcZEMK2Mmtg9ppJy1rMsp+qa61QJ37asVrLeZ6auVwcW5vq5t1xnhwBA/Q8AAP//AwBQSwMEFAAG AAgAAAAhAJrd+TEwBwAAJxwAABUAAABwcHQvc2xpZGVzL3NsaWRlMi54bWzsWVtv2zYUfh+w/0Do aQOS+BI7FyNx4bhJEaBNgzrFnmmJjrlQokZSdrxh/33fISU7quMuFwcYihWpLUvU4bl+58KTd/ep YjNhrNTZadTaa0ZMZLFOZHZ7Gn29udg9iph1PEu40pk4jRbCRu/6P/90kvesShjezmyPn0ZT5/Je o2HjqUi53dO5yPBsok3KHX6a20Zi+BxUU9VoN5sHjZTLLCrfN095X08mMhbvdVykInOBiBGKO3Bu pzK3FbX8KdRyIyzI+LdrLPUhWTxSCX3b/MYIQVfZ7IPJR/m18Y+vZteGyQT6iljGU6glapQPymX+ Z4ZluGh88/ptRYn37icm7Z/wHmRj96cRlL+gT7zEe+LesTjcjFd34+nnR9bG0/NHVjeqDcDBclOS Kki0Lk67EudGOiVYaylVWMrx6kcd31mWachJ4gfx4qtZRYxkJvL5lLlFDs04IlWuCw+9Pqr11uu0 YnSpiU73EF7i1XF4QFc1lRy128cH9JgU02p19pthxUOBA+G85+7PdLIghY7x7Q3Ce8q6kVso4alC HbwHpvEBsypOni+y3a+jiCXSOK97ZlM3VIIjRkpeXP9KO8F+E0qdYF8HO5dURJZcc8O/bCRGSuM9 bAtNVOzhMthls3X2K+sMdebgu+xa8VhMtUqEYe3X2Uom8LTKnC8y0wMzrHy3Zqhuq9ntPN1QZJBM DwqnJ9IFlQUL0oN1A5Z+NC6ugFOlhskVN5nW/gmBvY9918iDbMFsMU6lJYRkTjM3Fezy/OaCSbJC IhI2XvibZBYjx2DYMAAfy4uxkrFHGMYt40oxusuNY3rCeBaoXIKKyYTbfW/4BE8M+3IxxNME/7E1 EEoQ3rGUJ4LNpZtKcAEWYnICBP0DUjx2cibdgklLj62EY4A97BR5hpcMQpJoj42KeLrawEKeWBXY RBuu6vcDp1Z4HdgdkmYOv/ffRjqowTMslIid0ZmMsX2aFrgI6ByY586L5GRKe7CcvHeHzacSbHAj GE8SgLIFx073ajEVosWHDD6CVR8x9KbAe4Kpazs8jgVPoEIwcFO5R65Exg1MGNTGNku0hf1GH3ZI p+QyqUjHAAT4iBFwDjjtWEy5wtWk9N3Rh7dihqLFuxqyu0KyZ0pat1N6Fv1eBg89YNJZoSbwJ7w2 1+aOVtwaXeQkSyKsvIWvC56WZEoBNYnmb7FJkcHn4XF4sUAsmrA7L2yOWsG+uZhrTOfaED9L7b+l 0QdnTzY5lr4hJwRY54kk3MOfN3EN1OzSTt/h4u3DevMOrwrAAYBwDV4B90A0JI7fAYlV1jCFgk8i DGu2eGmCotQ2RZDdDZFl7pjpUUFqLhMUcZQIqJzP83CFwtyvnMiyFPOlDhFwfTJed//waCs8+XrK 9X022ArBTUKiFnqukPvHh8db4akS8pciT5Cdff7fCuFNwnaeL2znaLvC/rpXd9pavtwcWNvKyJt3 eFXojqrqyoYKRReOiqaHNVWZvXewYJXRCOZCFqoS0A5gj+obBH2MNsGoBXokJLiqRETdOBb4mRce Darir6rYdlZpb0WRiBGRR8BlvQZEXUhtmUPa26s5449hqWso1fqi1xbK1X3xfwD9ThuzCVP+CwBK TVIiHALL/og+O/C9noxlztG/IWSpzPXBXIU9NWqJQH9HLQ8SWixyYEhVTyzLhdxoFLOh70rK+Rde AcUzgSp6WBjjxwGG6FLZi5yOAgQt5OU5av0Vyr1Iy69C2CfogMd3mZ4rkdyCc4+i89BToi8oEgm9 QJAZYFkzI2JtEl9CpUI4VP0E3AuCVt8e08ryN5/BrfgYU6yyZQ/d+BuksWYXg6jlDKGcPDx3toMU HwaJ71FR1AY7+68b7IQhXOIwxcXAg/rACJNLGvb4OZafxVFDvTaUgyCr6dSLhme+YaaBz0o7tTEa QZPVSiYXUin/w9yOh8qwGVcYs/l/fnBYW4Z8hjEdLXf9QXFbIADaO6zdbLVraQ8zqA1juEfYejEn qz2gwReM9LqV2UdQg2BXhW/dH871OtswPyb1IB1c4I8CAyhhKi/wc8PteMEE5wHUg/x1ODjaHxwO urvHZ4fnu53Dbmv3uNVu7w6HR2fng86w3e22/o7K+bAlyTNwR0ZYG8CujPVwALtuLzp2EEvfcfdh lLnBcVBNljX8A58B90R2ZdH6JHjFyDLUX8rFaouXOc1B5TQXGhNoU0OL7jbcZeLgHiTwN77yL/Ph N0GMdSU/FyR8xh0Nhp/YiGLsU0gcNbDYFLp+KB+OgHBZnQrFynzi+eeZByEcdsEG8DzcypGQCP+x dLUEICpTPPBwmn20OCjA6QjHy1h2k1XHSEmBQzCJEdZEZtKJCLkOs1/jTqNM4HgOJteJuAknKukX GH552tXqrJ13pTI22uqJ28McthEOzhq5nguTa7QkODtrNcMBXGDXswO2XeCPrkqecQnw6P8DAAD/ /wMAUEsDBBQABgAIAAAAIQA8cmA3eAQAAFcNAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTEzLnhtbLRX 0W7iOBR9X2n/wcrzMkASKKDSEYGyqtR2UGE+wHUMRJPYWduhMKv59z12ErptgaG705dgYvv63HPP vb65/LzNUrLhSidSDL32p5ZHuGAyTsRq6H1dTBs9j2hDRUxTKfjQ23Htfb76/bfLfKDTmGC30AM6 9NbG5INmU7M1z6j+JHMuMLeUKqMGf9WqGSv6BKtZ2vRbrW4zo4nwqv3qnP1yuUwYn0hWZFyY0oji KTVArtdJrmtr+TnWcsU1zLjdLyBdwTM2T2P7q/OF4tyOxOZPlc/zmXLT95uZIkkMvjwiaAZavGY1 US1zfwWWYdB8tX1VW6KD7VJlV5d0AN/IduiB/J19YhMd8K0hrHzJnt+y9ZcDa9n6+sDqZn0AEOwP tV6VHr11p98PgqB26YEzxH2VcuLvvSu3UJi4leybJkLC35IGOV5jNR8pJZ/WnMbavi69Z/eb+ixL iT09XxOzy0GcSUzKq3XlpKOrXq8d5bUfe6LCzgVE5Nhqd/wQwxeU9Xy/37Xzlrh2Owxa5Yp/E1Ja zgdmG8l4Zwl/xK8LGB2k2szNLuXOKuiiA+AgnN6KSH1z/lpnoeZZIZipPKUDuIYHVqaYHXpcNL7O PRInyrgAEp2ZccopEq0CbK7mslCMa4JMITfCcCW4IRNFl0ZfAq6BfJxdPIED3NR4MSwDeTqc4dtw Bh8SziSGVuuI/7dIBhdtG7XjoQw7fqffdfg/MJQ2iKmY58wOdM5mzJANTYdeDzJy8HD4fsFjMZXC LLYO9WNxjyqJoQ2XVTrSWMQzqujDa1Xo70MPGoZIj+qjjLkL/DFtOSvAdcKKFdH1NtEGciVzzgqV mB0ZFUaiNKN2knnOWYLaWlbSA6qrEJz05CWGigHrv8uew4lxJvib2QMZo8YnMVcHMJ5DcTH0tFid IKmk+v3pBeLLC2BCDSezlDK+limAkjOyzLKEy+ZEdYwNbl8IZU3TpYcbx6ZYqUB7p1iBwYDYV9e6 Wgo5TdK0NP/OOnc4UkclasU1KlbE/4P4rbZ/QDzv53R/qU6lREF8wWr489r1c1aXRpW0/lVQhRNq Zs+oXh/HLGBbMm+uF1MyH43vyBx6J3ec27z9Jbz6tVbnqTV9X2SPr9jt/Ap20RbC9EGCXSPhFPsR 0l2iH7VN2d+dVhRNulHQiLrX40bY77cavaAbNPzOdBKNOqPx2I9+eFUDoi0ZAoAt/2/u7jc3Nqp6 Fal28BwVHH2q1h9Nn2NlBxw9955oBG81GoHctYQo33Axivpdf9yLGlE7nDbCSf+iMZp2O41pJwjD cdQbjYPrH3Apb4cDprgrmzd1u46Xb1rkLGFKark0n5jMmmWv3czlE1e5TFy73W5VPbu7C8NWcOH7 7bDOGYB0xagGCw/qLpql6o7mXzautODjABk3dq9yKLvK1ucl6HCSDBPWXyMqx3OKzbC4EHXbHRf4 aEhEzJeJSAz3CPp5g2weeoLjcwZSlzFflC1m9oBCsv86+F/Ol3AdHFvYSnx2VGG2gYMW/gEAAP// AwBQSwMEFAAGAAgAAAAhAHNoIxIiBAAAyA0AABUAAABwcHQvc2xpZGVzL3NsaWRlMS54bWy8V11z 4jYUfd7O9D9o/FwCNh8hnpDdQMJOp0k2E9jpY0exZfBEllxJEGin/71Hkk02CSFhZ7M8gJB0r+49 OvdDxx9XBSdLpnQuxSAID1oBYSKRaS5mg+DrdNzoB0QbKlLKpWCDYM108PHk11+Oy1jzlEBa6JgO grkxZdxs6mTOCqoPZMkE1jKpCmrwV82aqaL30FrwZtRq9ZoFzUVQyau3yMssyxN2JpNFwYTxShTj 1MByPc9LXWsr36KtVExDjZN+ZNIJPEsmPLW/upwqxuxILD+rclJeK7d8tbxWJE+BV0AELQBL0KwW qm3ur8A2DJpPxGe1JhqvMlWcHNMYvpHVIAD4a/sNIRqzlSGJn0weZpP5ly17k/n5lt3N+gBYsDnU euU9eu5Otx1127VLNyzBvc84I9HGOy9CoeJCJneaCAl/PQxyNMdudqqUvJ8zmmo77b1Prpb1WRYS e3o5J2ZdArjEqGluOKu2+nWHWC2iHeq1Kxusev1uv+UBC6PwCJx6DNvh4WHUsRsseFG7H0Zdt+Nb ULzqMjaroUzXFvRb/LpLozHXZmLWnLnLAGQ0hiGE0QsxVHfOZ+swGH29EImpvKUx3MMXdnKsDgIm Gl8nAUlzZdwlEl2YEWcUwVYZbE4mp6NLMslTRi4ZM9B4DCMNiFNpu91TJ+Qqkf1t+f18Oib9zs+x RP+Dq3G3uBOf08VsoQ2JfiNRK4wegQNXcTXgS32FGHp+72Z55znL2+/Icr249SxH1kBI14HxAtvB uAeH3o+TDv2WDZGd6GuaFJ9yZjKbxbeA727gjcHBRHpNFb15Gh7WlLC30xR/0/sctj1q3FEuMez0 +lKmTFEjlY7JGV3mKfmTcsNUkSv2IbUTB/ebiU9FQjPGDhJZ7AaI8hkCn6PGfl8aeaPxH8g3nz9Q 5sgFKniWM54+WrrD0l/IU35ptxf7xxiI5YvjGTWMXHOasLnkgJW8IdRerxypQWcC3swpz4IqrnyG t/XWlpmtZUTIcc65V79n/t9OqJ00Qur6oXlr03CMpQQbH6HaeT2BvY5qZpSH9e8FVTihRvaVlGUL zc9F1hWq3ZXze4tDVBN3wm1RvloUt0+g7v4IqNE/Q/VWtF3H5ej7HjzO0Ljb7vXf8Vm/Nzw7OmyE o3a/0Ql73cZwPO43jsbtdtgdHvZG5+P/gqpT0xYMAYO3NhXP2ho0S2Cb7WPCh5yIk+3cS2XgxVB6 6SZdtfc9OoZ1255wdUnLL0sXr3iNgMYjN1Wit6pC4GELSm1eYMEVXXGh0XihP6UQhsapqPv8dIFX Si5SluUiNywgeEAYhMggEAzvJ1AGFWPqelpT3CA6N8+RsPPsQVLkiZJaZsaWjKZ/2TRLec9UKXP3 uAlb/oXkzXXmwEPj7bOjymaLAED9HwAA//8DAFBLAwQUAAYACAAAACEA+nFv1JcHAAB5LwAAIQAA AHBwdC9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIyLnhtbOxaXW7jNhB+L9A7COpj67X1Z8nGOovE G28DZNNgkz0ALdGWGlpSKdp1tiiwd+gNeou2bz3KnqQzJCVLiZ11kKRIDAOBLZHUiJzvm9/49Zvl jBkLyoskSwem9apjGjQNsyhJpwPz4+WoFZhGIUgaEZaldGBe08J8c/DtN6/zfsGi96QQlBsgIy36 ZGDGQuT9drsIYzojxasspynMTTI+IwJu+bQdcfIryJ6xtt3pdNszkqSmfp5v83w2mSQhfZuF8xlN hRLCKSMC9l/ESV6U0vJtpOWcFiBGPt3ckpzhCzixZR7AYcMLFuH3eKo+P9CJkURLmO50cAXpy0PT IePGgrCBOZ5aZvvgdRsfgcX6Ch8u8ktOKV6li3c8v8jPOd6EZ4tzDjLxjUZKZvBqFCAn9DJ5m8Iy Jbjx+LSURPrLCZ/hjkBXBuwQIL3GT3iI9OlSGKEaDFejYfzTmrVhfLxmdbt8ARyteimeSp3o9nHs 8jiXiWDUOGckpHHGIiCOVJE8oXoMtJifZuFVYaQZnBlVoY4KyikF4/nxVXlsiOsctCRQrF6nJmFn abW+kPotN11pxfV8YKBUje27XSdo6iew7V4X51FLluU6HbjBvawE5bwQ72g2M/BiYHIaCkkEsjgt hFpaLpHoq43kfbE8yqJrBGMM34A5mB88H2f8k2mwk7QYmD3LdeHdQt7InZoGr8+MGzOCDTOgHDxB 0hDkDMxQcLmXFEzvcC6ySaJ3pF6JL2eFuBDXjEpaAHikD2qFD9gQI2j9NG19vADrn4khowS8g6aQ OBiyJLwyRGbQKBGGdgISBvAVIBK1JKSupEiaRueEkw83JGsVSd2UOgHkFJE208mp6IRcrrPJRoAe yiZUkKlN+yGksoA9SDCp3tLqGqxyPdvrdZ3nzyqkxb2IBBZnsIVkpDz+A4mF2pO8KhrEApJJ2qqP 8pXSY9yDyxc0zNLIYHRB2RbiJcfuIf4yTvj20iUZ7iF9lM25iLfevKvYuDUco2SyVjqEkUc1abc0 6bdENAOEVMhDTToS4MU+gYclbKJNW8IowwQGk3vGi67jwd8N07Ytx6kChtP1LNt7/pbdiBfSVMuo ICPEglloyoRNwfszE8ciOkE/juq00L3hWJGxJBoljMkbzP1WaZBYquxIJKlQiZHvrUJplTPJYFGT A7at3iQnwJfgRtS1Dlv4rjuiVpRwIfObdfHrLFsYwQ+G3bE6DZPfyGujEgdKUn4HOHOPoOWVDB9l GWbM9bAlrfKhHJ9AwJeo/DInHN6gea6iC6ZD2/LcsWy3TIzWEz3oeTtN9DJ32gmqnxxfjoyz40Pj PaVgg9P/ie/dku8X4BqocTafjW+wXnrHh7IeSlAQvY740qju5eC7nufcTfxd9/CqZHh+tJ+wSNbF v/mHgXPoH3qt3pF/3HJ9z2r1LNtuDYfB0fGhO7Q9z/odyiZZFhbIvBTYgZHi61UNxBcZAMXBl89/ fffl898rS4H3o4wNOc9WsQGYWJb9cFk2E0LG35PcgFYBhFcBZT9Ey4EZXcHVeGrjGNTOYglX0RVc kTCEZgWs0BflCMyrkWqNU45AsaSm3HIEci014pUjEJvUSLccAeuNWZJeQcqEX6YxydiPaqC8wtwG zsSiU3KdzcVJBDXvjRGJmW25vhs4QQDv5X3sbvCTSJf9taeba2FH1Vpd1G1cC3ut1upsceNav7ZW R92Na6HvVcnVvmrj2l5tbfeWZhpn60GRXsn1v7IWeFCtlf2JhsabcgH7am3vK3KBFdVaS+axdwhu AFf2Y2qq0MDHEyOOoPOgxYmlbC4UyAnZGZC3aEY6mdNZJQZbA1zOJRlfQE4pGx+oIqH6GZScpkcc iAiqwCZfqm9hSQxNCgho5/M0hO6J7sHl4RH22rCPFJ6HOuOUW4KsDcb07Hh+Bt1Mae81dwc9F5B7 RTl2QrdNblVCWEtd4YS4UemFJtDqGpjfz35uMYGYgBMhNyYoURNhcWMiLHBiUyLc1Co0GaFtcUvF M8JPB6bj2j08WJKCPwRVtcqBMq9/av2DKlUj5AYGowxqAnTWSk2HPCHMNPJEhPGIzBIG+bsD7Atj wgsKG9cV13g+hBE5PDC/fP5T6a+GowrjT4FjugnHtLUBx7R1J47SHGwsshRWPmAFleUKKzvwoGAC D61rsJeN1R+3sLKDp7K5R8QKAdKuy1lhVXaFa2DZgayMdgOs24ZlP5mDfESwECENllsDS7djdxWs NZaFTvdJotkjgoUIabC8FVh2x/Ml1aqQZe+QZf37z20v+BKwQoA0Vt0aVp7lSqe3k1itSy8wnXn2 hoUIabD8Glg935IBdw/WXQ3rrXL6R/SCiJAGK1iBpdL0RjK4Q17wxVoWIqTB6tXACoKu7B7uLes5 WRYiBEV0oz7O+5mIKa+qZagczxWkuoas//yhKsH1krJ7ocq1JynMapWsctYvspItf1/z+LXQS9PP +uqx7HTt9bOhYHN8/AnNU3Q+XhqB1hdJVmAHMpfbM2hDZSKzpT2DIGRtqAZ8V7VK9wzakIFDRif7 EHsFbch6u56/d9KyiV9lmvXkEhLP1T/C8H/A5U/mD/4DAAD//wMAUEsDBBQABgAIAAAAIQD9eIyp vgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDgueG1sLnJlbHOE j8EKwjAQRO+C/xD2blI9iEjTXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3bq9jWN4kmJXfAa1rIC Qd4E63yv4XY9rnYgOKO3OAZPGt7E0DbLRX2hEXMJ8eAii0LxrGHIOe6VYjPQhCxDJF+cLqQJc5Gp VxHNHXtSm6raqjRnQPPFFCerIZ3sGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95 LjayvA+qqdXX3OYDAAD//wMAUEsDBBQABgAIAAAAIQD9eIypvgAAADcBAAAsAAAAcHB0L3NsaWRl TGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDkueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEjTXkTw 4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3bq9jWN4kmJXfAa1rICQd4E63yv4XY9rnYgOKO3OAZPGt7E 0DbLRX2hEXMJ8eAii0LxrGHIOe6VYjPQhCxDJF+cLqQJc5GpVxHNHXtSm6raqjRnQPPFFCerIZ3s GsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LjayvA+qqdXX3OYDAAD//wMAUEsD BBQABgAIAAAAIQD9eIypvgAAADcBAAAtAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxh eW91dDExLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhI015E8OBF9AOWZNsG2yRko+jfm2MFwePs MG926vY1jeJJiV3wGtayAkHeBOt8r+F2Pa52IDijtzgGTxrexNA2y0V9oRFzCfHgIotC8axhyDnu lWIz0IQsQyRfnC6kCXORqVcRzR17Upuq2qo0Z0DzxRQnqyGd7BrE9R1L83926Dpn6BDMYyKff1Qo Hp2lM3KmVLCYesoapJzfeS42srwPqqnV19zmAwAA//8DAFBLAwQUAAYACAAAACEA/XiMqb4AAAA3 AQAALQAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMi54bWwucmVsc4SPwQrC MBBE74L/EPZuUj2ISNNeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdur2NY3iSYld8BrWsgJB3gTr fK/hdj2udiA4o7c4Bk8a3sTQNstFfaERcwnx4CKLQvGsYcg57pViM9CELEMkX5wupAlzkalXEc0d e1KbqtqqNGdA88UUJ6shnewaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kuNrK8 D6qp1dfc5gMAAP//AwBQSwMEFAAGAAgAAAAhAP14jKm+AAAANwEAAC0AAABwcHQvc2xpZGVMYXlv dXRzL19yZWxzL3NsaWRlTGF5b3V0MTMueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEjTXkTw4EX0 A5Zk2wbbJGSj6N+bYwXB4+wwb3bq9jWN4kmJXfAa1rICQd4E63yv4XY9rnYgOKO3OAZPGt7E0DbL RX2hEXMJ8eAii0LxrGHIOe6VYjPQhCxDJF+cLqQJc5GpVxHNHXtSm6raqjRnQPPFFCerIZ3sGsT1 HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LjayvA+qqdXX3OYDAAD//wMAUEsDBBQA BgAIAAAAIQD9eIypvgAAADcBAAAtAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91 dDEwLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhI015E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92 6vY1jeJJiV3wGtayAkHeBOt8r+F2Pa52IDijtzgGTxrexNA2y0V9oRFzCfHgIotC8axhyDnulWIz 0IQsQyRfnC6kCXORqVcRzR17Upuq2qo0Z0DzxRQnqyGd7BrE9R1L83926Dpn6BDMYyKff1QoHp2l M3KmVLCYesoapJzfeS42srwPqqnV19zmAwAA//8DAFBLAwQUAAYACAAAACEA/XiMqb4AAAA3AQAA LAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ3LnhtbC5yZWxzhI/BCsIwEETv gv8Q9m5SPYhI015E8OBF9AOWZNsG2yRko+jfm2MFwePsMG926vY1jeJJiV3wGtayAkHeBOt8r+F2 Pa52IDijtzgGTxrexNA2y0V9oRFzCfHgIotC8axhyDnulWIz0IQsQyRfnC6kCXORqVcRzR17Upuq 2qo0Z0DzxRQnqyGd7BrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS42srwPqqnV 19zmAwAA//8DAFBLAwQUAAYACAAAACEA/XiMqb4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMv X3JlbHMvc2xpZGVMYXlvdXQ1LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhI015E8OBF9AOWZNsG 2yRko+jfm2MFwePsMG926vY1jeJJiV3wGtayAkHeBOt8r+F2Pa52IDijtzgGTxrexNA2y0V9oRFz CfHgIotC8axhyDnulWIz0IQsQyRfnC6kCXORqVcRzR17Upuq2qo0Z0DzxRQnqyGd7BrE9R1L8392 6Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS42srwPqqnV19zmAwAA//8DAFBLAwQUAAYACAAA ACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxLnht bC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWT ErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+ OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCY esoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBw dC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7S ehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDij tzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2 iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA //8DAFBLAwQUAAYACAAAACEA/XiMqb4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMv c2xpZGVMYXlvdXQzLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhI015E8OBF9AOWZNsG2yRko+jf m2MFwePsMG926vY1jeJJiV3wGtayAkHeBOt8r+F2Pa52IDijtzgGTxrexNA2y0V9oRFzCfHgIotC 8axhyDnulWIz0IQsQyRfnC6kCXORqVcRzR17Upuq2qo0Z0DzxRQnqyGd7BrE9R1L83926Dpn6BDM YyKff1QoHp2lM3KmVLCYesoapJzfeS42srwPqqnV19zmAwAA//8DAFBLAwQUAAYACAAAACEA/XiM qb4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ0LnhtbC5yZWxz hI/BCsIwEETvgv8Q9m5SPYhI015E8OBF9AOWZNsG2yRko+jfm2MFwePsMG926vY1jeJJiV3wGtay AkHeBOt8r+F2Pa52IDijtzgGTxrexNA2y0V9oRFzCfHgIotC8axhyDnulWIz0IQsQyRfnC6kCXOR qVcRzR17Upuq2qo0Z0DzxRQnqyGd7BrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzf eS42srwPqqnV19zmAwAA//8DAFBLAwQUAAYACAAAACEA/XiMqb4AAAA3AQAALAAAAHBwdC9zbGlk ZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ2LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhI015E 8OBF9AOWZNsG2yRko+jfm2MFwePsMG926vY1jeJJiV3wGtayAkHeBOt8r+F2Pa52IDijtzgGTxre xNA2y0V9oRFzCfHgIotC8axhyDnulWIz0IQsQyRfnC6kCXORqVcRzR17Upuq2qo0Z0DzxRQnqyGd 7BrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS42srwPqqnV19zmAwAA//8DAFBL AwQUAAYACAAAACEAC2Q/viEIAACSNwAAIQAAAHBwdC9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIx LnhtbOxbW3LjuBX9T1X2wGI+E41FiqIe1fKUpWlPusruuEaeyjdEQhJjCGRAyI9Jpar3kB1kF0n+ spReSc4FSInUwyNn3N3jln8sEAAvgIP7OLig33x7vxDOLVd5ksqB633TdB0uozRO5Gzg/nh93ui6 Tq6ZjJlIJR+4Dzx3vz397W/eZP1cxJcs11w5kCHzPhu4c62z/slJHs35guXfpBmXaJumasE0HtXs JFbsDrIX4sRvNsOTBUukW7yvDnk/nU6TiH+XRssFl9oKUVwwjfnn8yTLS2nZIdIyxXOIMW/XpnSK 9UVjEdPvZGb/XqnTN6yfpyKJzxMhzAMtlI+Ecm6ZGLiTmeeenL452ejFp1Me6YtcUxvJI0mmQILz 7FpxTiV5+73Kxhm1YvT3t1fKSWJsiutItgD2JNs0FN3Mo0Q3K7f2+qyUxPr3U7WgyQI6537gYocf 6C9eYn1+r53IVkbr2mj+px19o/nbHb2xWDsAFrQalFZlV7S9nNALwnJFPwAXJmeCO/5qcfYNQJhd pNFN7sgUy7UopKM5evMzpdK7OWdxTtV28YCrHIoQocGzuaMfMuCmEy140c82Yq5y1T8H4s7k7jKN 0ZctdeoSMhuoBe0OFNZA53eCsNWt49f1/V5I7YSi5wWtJh5oZmtBmcr19zxdOFQYuApLNwOx20Iz WL/sQuPLlJTMbJKQzt3A7bX9tnmh0rJIyPxEshi4XYxox2R9wuatjM3LmiXCljEXIY3i0YoJIX0/ TOMHGm2CX6AAR4CpzVP1k+vcKQbY878umeKuI95JoN3zggCL1ObBQOI6qtoyqbbI5WKUwiygwExG kDpwI63Kh5HGMyGWLjKmL+Q4i6grzYZwuL7/M1NZAZaGnr5Px3OW8V2Y2b4GbbsQEiJyPdYPghsU oI0QixWKW0yoUH5gwPqKKqFVA5fLxo9jeLuFHgnO4A2Lbvp0JJLoxtGpw+NEO4XTM1oF34ghaJu1 GR4iUcZo0LASXRStNTxqE51tm2iRBhmDf36bIJxcuBfYfmlCz2AaHmyAzMRgXvqWmm0E0OJeaFb2 aht129BfjWXQzhvDyHdYhjGPijEa9YMdHmqMYx6lMnYEv+XiAPEmsDxB/PU8UYdLN4r8BOnn6VLp +cGTD6wlHYzNeTJ9RPrTfJLX9MH9LPNYx2kzo0/kk2JYQP4T4g8T08I3md3DvJ/BN4U+fA9CaM03 +V6rtYrbQSf027/WsA2uVqeRXy6If3ZHZcL5rfAMbWH9mE9/QNQmVfECIl3VkE196xxdzSYrhm5I UrnFlW6IRVaqid8gCXYsVJc0guSWLILKtjuUieI90al9XiBOlDbUujZNo4X69Gw5c/w/OH7T82u+ DLst4yumGC20Rk9W4oqhn0o1YNa9bbM2ZvGJzHpKnI82i6gk+Gph2pYD/P+m3fL8oKTku22722u/ 2vYTCfqXtG2HiRloN50R1hb2VZj5u7fX5874bHTpjJOYO5ecayRBPpvFt+AjNwN5+AkPF8gMvV8u dhm9oQ+/IJ6H7XbrcaN/DehIVLw8o/91m/xUxCYV97dmGHbaZ2fdxrDT6zSC74bDxnDUGzZGQbMz 9MJW2H3b+zsSJCbvlCNTyJEEMd5sM89gCECN0NS4hD79+OFfv/v44d9rJ4FJkFv8JcTApCJsuhHF MsEZCXXJMgfZy4ErNLI1+h6l+AalycynOp/qUIpvUGJRhJwpehSFsgbttmbVp1XWtMo+QVkTlDXt sqZd1oRlDdKEc5HIG5wI6Md1pqn4o60oS9aJwd9csId0qd/FyKVRzqRSYzbO94JO0G11ifuoPmVV 1bvYnDz39+1iHau+5UGkIrgYaj515rFJZWEDKetjsk65KVPi0TzSxhWsshLlHKVNNsrh7EIOFRYK y52mUp+ZQDhhOTJvlPJEsLhaygi5uaZRpjyLhnxKQlG6irRNP694bbX1bApA9vYrWiuMGgm+YoxH Et1QBkIe1LfCobFCJNKlUf4pi5BM/f3iLw2hixMX22jgzDZE+UZDlBeydzFyA6NPmbw1WfjaYTxT CRNIlM6ZyrnRAYt9HR8CpVCz1is+pJt1fAiUAp/gFZ9tfAiUAp/2Kz7b+BAoBT4h4bNg6mLglvdC O7zRhiOnd1+I3z7M4RAKBSCdNSDmighh7AgBIRQKQLprQLxWh65FjhIRgqFApFdBpOt3cV15lIgQ DDZlV+GG+CYA13FbRNF6mFbg9wisROIwgejfKCushYEYPC+LxPEawxXs7slMcrLEHb0yXGXgfvzw T8vxKvzSHN+NL3yUX9pLyZ/ll3Ifv5SNPfxSNg7klxb9DtDHncAafb/b7lDFS0D/H1vo+2R3z47+ Ftfa5KIWy/K7iAqYfrfiGl+aKvuHHZWeqMpbYG4S1wJMAGcyYSu/4L8gMHdoJnmdT6+ZmyzXguk3 2x1zk/QCwfzvf7at/PNguZsR+2184FULWHsV82CG/Iwx6cvBtZsv+72OZ8jQz6veccG1m01b8lML yPvc3nHBtZtqt7rd8MAocVxwrXh4hXln/VTPuVrxcLDWK3t+Kfhr9SJ+lYIrupTZXRtQqgQRL1+z yRgX4OXZeIuwI9NucqfrLHA962s/i6ywaOsybriij7Zpg589cuKioZ6xfS5GXc+YgPMdLT67WXKp JKsDxtHis4f41vMpx6xAu8msV0+vHDNAexiqYQyvLhohaw8n7QT2K4tXH7SHhSLkmvPiK0B7eGfY 7tQzO0cbxVZMs0ou8fXF+kMB+iqj/F+60/8BAAD//wMAUEsDBBQABgAIAAAAIQDe+Dcj3gAAAFgC AAAsAAAAcHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlkZU1hc3RlcjEueG1sLnJlbHPEksFqwzAM QO+D/YPRfXaSwhijTi+lUNipdB8gbCUxTWxjuWP5+5keRgJluwx2MUjCTw9J293nNIoPSuyC11DL CgR5E6zzvYb38+HpBQRn9BbH4EnDTAy79vFhe6IRc/nEg4ssCsWzhiHn+KoUm4EmZBki+VLpQpow lzD1KqK5YE+qqapnlZYMaFdMcbQa0tHWIM5zLJ1/Z4euc4b2wVwn8vlOC8Wjs/SGc7jmgsXUU9Yg 5TLPy6CWRR/UfbPmP82an8w2f2mWyy5pNa1bRt3e7wGp1T20XwAAAP//AwBQSwMEFAAGAAgAAAAh AOr4VTchAQAAyQcAACwAAABwcHQvc2xpZGVNYXN0ZXJzL19yZWxzL3NsaWRlTWFzdGVyMi54bWwu cmVsc8TVu2rDMBQG4L3QdxBnr2U5iXMhcpZSCHQq6QMI6/hCbclISqnfviJDsaFVCRi0GCTjX5// Qed4+uo78onGtlpxYEkKBFWpZatqDu+Xl6cdEOuEkqLTCjmMaOFUPD4c37ATzn9km3awxKcoy6Fx bjhQassGe2ETPaDybypteuH80tR0EOWHqJFmaZpTM82AYpZJzpKDOUvGgFzGwR/9f7iuqrbEZ11e e1TulzOo7VqJr2LUV+djhanRcUiS6b6dLtgq8T8A9A9btqTN+dJwprrt0NszCzqWZNxbUbChRQu6 V7YOdbaK2dkmJFvHlOUh2SambBuS5TFlu5BsG1O2D8n8zR7xYk1DtH1UGgvRmJ+QEWv7mQN0NoCL bwAAAP//AwBQSwMEFAAGAAgAAAAhAOokx0xlBQAAvRsAACEAAABwcHQvc2xpZGVMYXlvdXRzL3Ns aWRlTGF5b3V0Ny54bWzsWd1u4kYUvq/Udxi5t2XBxsaAAquETapKCYkK+wCDPSzuGo9rDwRaVdrX ah9nn6TnHHvA/DhxSFqtVG7AmM/fnJ8535wZX7xfzUO2FEkayKhnmO8aBhORJ/0g+tQzPo5vam2D pYpHPg9lJHrGWqTG+/73313E3TT0b/laLhQDjijt8p4xUyru1uupNxNznr6TsYjgv6lM5lzBz+RT 3U/4I3DPw7rVaLTqcx5ERv58UuV5OZ0GnvggvcVcRCojSUTIFdifzoI41WxxFbY4ESnQ0NO7Jql1 DN6qRzlejR/l/eRXgxE4WcJt0+iD/94o9FnE53BjIOcxT4JURvRPGo8TIRATLX9K4lH8kNADw+VD wgIfCfIHjXr+Rw6jnxHA4KK+9/gnzcS7q2ky71/wLkSDrXoGJG2Nn/AQ74qVYl5209ve9Wb3R7De 7PoIuq4HAAs2g0K+48yjQ3cs7c44UKFg5sarDMrh0VvpfU5ZJMFPdD9zzxsuNRn6jPTxjOWhR6oc l/1J8dD4FGJKwVKrK+mv0fEJfNNN3g1TNVLrEFIA18vQpATwri+mv2ShLdwGb4twcJJ3wRT4gGSF HOtARLWPI6iDuRqEgkOd5KFW/UEYeJ+Zkkz4gWJ3PFUiYYqikKIBF8CuIJU5pYj8B55wMGKHGaPB uzAyuKj9gcss4OVhb27Cjjl/CLknZjL0wQLrLTKA8TRgusJc0gkrSQRGa29K2o4LBU7z0nSajmk2 0aTt7LQbdsNsg7jgHG01O26LbIYwZETkfjYldER0hhmPvJkEtZhklMXs5clmc57cUl0EkQ8Fjpc4 +mQxBBUjQ7K5wNLfe4Zlo6UT7WZhbtClBbMnJ9ReVWJtHLIiFdoBZja3rB3TJguqsJrtQ1akylnt LavZdM0WgivREnI3BMiV0zoF2rbVJhtOpUWunLa1pbWsNpjwCmuRK6d1C7Su3aR5eKq1yJXTtre0 yFk9ZUdii1w5badA23LcV6UMuUhLijVBioaDwKzbSBeNfrrCoeCQwKU7CneKitlaxQYyUlCrO0JG qgFLrV4oXriUYHXPeDjNZSyTGFxWKUx4UVxPMCHlMmaZrt12nSdkrNlxTCgORFTRMZKhYqIOVqqt OmWUBQBcajEpKhmW0AarAYDVElHAkpJssBoAWF33RSzOyg1WAwCri7kUqwGA1RVaitUAwOqyK8Vq AGB1LZViNQCwWYHoToDiSyK58e3bqCBqBuBDFy2tvy9oS0bCk5HPQrEU4ZEC3aenungB/XgWJNXZ 85W/suLcyEWiZpWNt7OKrE4fTI+yQ2/ypt2Zo3VtvN+dkcWni1rWH2fdGQrcbwueQNuZaxxFm1rl yhrXsp2GBeZCJ1bWq5kuKN+5V+sZ514N+uVzr9Yzmv/HXq2lNe1Yr0at0emydihlpJMnS1lZv7aV snO/hjHf7X/O/VrJmc6TO579hurcr+ERWrYb3I/Nt9qvuVrbPnAldjahLewwTxe2rF/zFRwg7m5H zWxPVbofpVH3T7/g5vbAkn48cWLpB4miM+BjZ5dDuWTtH5nVMBs7e4TSRpht6GDcU7b6cNyXnZff SIkHpcUjS/ctgjxV0AYfLiTmM+eX/3Kgf74e37Dh9SW7E0LBy4//KNodHe1RGPiCDRfzyV7M6aji tRMbXgMB9dGwP3Pe8pKwT+FdC745+cO9bDcv3Uun1rlyr2u265i1jmlZtcGgfXV9aQ8sxzH/NPKX CCl6HoF1WDTPn3bBfpsqSvW/fvnrh69f/t5mCsZHjpItYqXKoCPt7MUQXOLbI1KVMLnj8f2S9q/w 0gzqYkC3YpgpWGcA3UKQQ7926/8DAAD//wMAUEsDBBQABgAIAAAAIQBQ3r+jAwQAAO4RAAAhAAAA cHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDYueG1s7FjRcuI2FH3vTP9B476WxTY2EE9gh7DQ 6cyGZAr7AYotx+7KkisJAu10Zn+r/Zz9kl7JFgHWFNhs+5SXRMhHR7pH915d6frtuqBoRYTMORs4 3hvXQYTFPMnZ48D5sJi2+g6SCrMEU87IwNkQ6bwdfv/ddRlJmrzHG75UCDiYjPDAyZQqo3Zbxhkp sHzDS8LgW8pFgRX8FI/tROAn4C5o23fdbrvAOXPq8eKc8TxN85i84/GyIExVJIJQrGD9MstLadnK c9hKQSTQmNH7S1KbEqxVT/zu4VcHGZxYQY/nDMH0eE4TxHABHYsnjsacKaAxn2S5EIRoEFv9JMp5 eS/MiNnqXqA80Qz1SKddf6hh5icDGDTaB8MfLROO1qkohtc4AiXQeuDAhm30XxiEI7JWKK464+fe OLtrwMbZpAHdthPACraTwl6XlUVfmuNbcxa5ogR5W6sqKIah73n8USLGwU5tfmVePFtZMm2zpi8z VMuuqWpc9dHoYfESNDViqfUNTzba8Af4bzpxRKWaqw0lRhBYNo6AHP6A/BRrryas9WEOXl2oMSUY vL4WTw3HNI8/IsURSXKFbrFURCBl7JKa8hrUUbA5NSVhyT0W+JcDZm0fjmBmWLRdITQrCY8L2bFC 1t6E7imOScZpAovwXyar/B2iAdPUAQ8E97B7cERbLdeBlwVhD+LVuJrXdV3dNvpahwvcTh/6HaTd Lgj98KrbMRtomYwA1TZbTRp3Tc9NV9QzYYOjhKRaXr1+v19NCtruAKDpN2CDXawFALbTgHV3sRYA 2OBLrLe3BgsAbHgKawGA7Z7CWgBge6ewFgDY/imsBQD26hS2Amit63DSG2OiCUYiYNiGzQujS3uQ CS65F11VBB1OaRz3goCek5izBFGyIvQMehNlF9Avslycz24C4gL2KV8KlZ29+KCKyLO3Y5qnjexw inzTvBb8W14zmsB5ag+DC4+Lg7xm9s8cFTrTmMbumdGU17pB/zWxwYnwmtii18S2LYReE9sZBVto E9s7rMhetWZS8ddntaoIThTUqAd1m9mg4wnu5UVxkgtlLg5N5fGMr1D/R+S7nrt3mB49MdCW7itr 4q6VeMq5rsV3S+LwZSVxJXKqRKXyb0ssYAZbIJ+okP9joX+eLKZoNhmhW0IU3Jb/J7V7Vu05zROC Zsvi4UDz7rfQHN4NgLpR9hMH+CWyp3BD19ftP3qjfmfUG4Wtq5vepBX0Qq915fl+azzu30xGwdgP Q+9Pp755Sm05g9XpWuH0lRGODFiTvhR+/vTXD58//f28UzC//nKkljorMkwOql4ToKnfHMyDARW3 uLxbmUIPXlnAa8emqwRP0XEG0GeI5rDvNMN/AAAA//8DAFBLAwQUAAYACAAAACEAAC8bOnsEAADf EAAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ1LnhtbMxY227jNhB9L9B/INTXei3J F9lC7IXjddoCiTeovR/ASLQtLHUpxbh2iwL7W+3n7Jf0DCX6krpdI9kaebElcjhz5swMOdTV200q 2VqoMsmzgeO9cR0msiiPk2w5cD7Mbxo9h5WaZzGXeSYGzlaUztvht99cFWEp41u+zR81g46sDPnA WWldhM1mGa1Eyss3eSEyzC1ylXKNV7Vsxor/Ct2pbPqu222mPMmcer06Z32+WCSReJdHj6nIdKVE Cck18JerpCittuIcbYUSJdSY1ceQ9LaAt6WIfhQ8dpgRVGsMec4QvkczGbOMpxiYiYiMMxIUysyW xVwJQXLZ+gdVzIp7ZRZN1/eKJTEpqRc7zXqiFjOvGcTw0HyyfGk18XCzUOnwiodgg20GDoK2pV8s 4qHYaBZVg9F+NFq9PyEbrSYnpJvWABDsjCLeReXRP93xrTvzREvBvJ1XlSjH0ts8+liyLIef5H7l XjRdW2XkM6kvVqyiXpOqWq6aNHxY+dJwaoHumAh8v+W1DB3tttvtu09ICYLAb2OQETVeq+u7QccY sZpgpFJdhHpzncdbovQB/4gcz6JVjizVtIKHstQzvZWIM57X0gMixuUSZSSRBTyMxeJnDJW/DRyY hM0HE/iIgwEuZW22XolwH2sE2TwEJfiBEsmpHkXW+DBDPaZ6LAWHodo7PRzLJPrIdM5EnGh2x0st FDMUonqBkbRrY8OoFFl8zxUneIeaKSo8hGWwYL03hFBk/j384LsqhTnl3r3kkVjlEsXAfHIS1WLj /KxMIPYdlA1y2ibOsxLC77vdAMlhgmer5DghOq7r9YI6MlWRnZMQD5XOUwmRcnVrCjTJYuw09Egx fXicYjs1SA7SBFtiNV3mMolvEilJ1uymYiwVW3OJ7NvQFoRwJpmuRgLANpmA4O2ETSgP9GCusmQm dllnUten1K2QtjsBUIDuM+B6vQvCJYzkNpC39nD7Hsr8XLjdC8IljDXc9h6u1wo8QnEeveSZSYAL ZAOBrPF2DvD2/B4F+fXhJZA13u4er+/3QO9rxEsga7zBAd6g3Tq/3C6ZDwSyxtvb4yWw59fbJfES yBpv/wBvtxO8znojkNVOfNBFmDOf0GOT2x3uxq3n9wB00JkWoDzqAZ5zzrftOf+Oa3F0zptD9aXn fKzR2qBZWnG5sOd9daxRI2zoooeZYa5q00x3YTsV26eZU9WexeblP3qpOFHadMmnuqppvma975nv eu4ReWiyTzdQbKcOdp9DccdSfJPn1MIdNlPtr9FMLbSqWP7lkStYsER/obP6n4n+aTK/YdPJiN0J gb5meSG2u5btGdotwaaP6cMTzs3l4KWJjYsyVJ+k3TTIaDG/Qn4vcCOlu+XvwajXGgWjTqN/HUwa 7aDjNfqe7zfG4971ZNQe+52O94dTX7NK8jwDOto8v7zLoPZMRenh509/fvf501/7SME+6XhJZZhe u7o645Hu2Ob2INUdL96vzUaIzwrIWjTDGCqQKVRnEN2LkA77YWL4NwAAAP//AwBQSwMEFAAGAAgA AAAhAKVIilNBAwAAHAsAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NC54bWy8luFu 2jAQx79P2jtY2dfRkBQKjYCKUpgmtRQN+gBu4jRZHTuzTQabJvW1tsfpk+zsxHR0VILC9iUQ5/z3 3c/n83XOFhlFBREy5azreEd1BxEW8ihld13nZjaqtR0kFWYRppyRrrMk0jnrvX3TyQNJo0u85HOF QIPJAHedRKk8cF0ZJiTD8ojnhMG3mIsMK3gVd24k8FfQzqjr1+snboZT5lTzxTbzeRynIbng4Twj TJUiglCswH+ZpLm0avk2arkgEmTM7HWX1DKHaPntZwcZI1HAq+f0IO5wSiPEcAYDs1RRgoAOGnCm QMkYyHwmCNGmrPgg8mk+EWbeuJgIlEZap5rvuNWHysy8MjCDP+6z6XdWCQeLWGS9Dg4ABlp0Hdiz pX7CJByQhUJhORg+jYbJ9QbbMBlusHbtAuDBalHY7ryM6O9wfBtOicNbRVWaYph6ycN7iRiHOHX4 ZXjhuLBiOmYtnyeoJK802cqu/Gh4WHsJTA0stTjn0VIHfgu/ZhAHVKqpWlJigIDbOABxeAB+inVi E1a7mUJiZ2pACYbEr+Cp3oCm4T1SHJEoVegKS0UEMs7AMQDJDtBRsDmVJGHRBAv86Zmyjg8HsDI4 bT2EvyXCl0EeW5BVNqEJxSFJOI3ACX8/rGkESWHJH4AobACiBV2h25OwTlsDWK4RLikalPCwS5ow dtjUKQk5nFFKCkK3kDekd5CfJanYXv1Y7+MO6iM+FyrZ2vnGrvJpvFEdKslBc7thc/sCK7KW2AYI lFVbDV5VLyIFx/kb1HxMYweKrE52c6hN2dDF5R/UjygVytTYTZVkzAvUfo/8uldfy7kXwaKV3CvL R9MiHnGuy9af1cOkxb6QYyVKyl/mWMAKFvQBy8rmMrIiswn0x+FshMbDProiREFv8Z9on1jaU5pG BI3n2e0z5s39KnZ5EUKXBdIbsZs6dZj8jqGl0Z3J91a/fdxv9Zu10/PWsNZoNb3aqef7tcGgfT7s NwZ+s+n9cKpLWurIGXi33e1a3tn6/nx8+Pnu8eHX007B+lrjhZKz1ckw92vZeMFf3aSZ3oqKK5xf FyavoCeFrB2YoRwyRZ8zMH0y0Rq2q+39BgAA//8DAFBLAwQUAAYACAAAACEA7CjelywEAACLEAAA IQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQzLnhtbMxY727bNhD/PqDvQKhf61qSJUsR YheO6wwDEjeY0wdgJNoWSv0ZSWv2hgF9re1x+iS7I0XLyVzE6NLCX2yaOp5+9/vxyDtfvtsWnDRM yLwqR4731nUIK9Mqy8vVyPl4f92LHSIVLTPKq5KNnB2Tzrvxq58u60Ty7Ibuqo0i4KOUCR05a6Xq pN+X6ZoVVL6talbCs2UlCqrgp1j1M0F/B98F7/uuO+wXNC+ddr04ZX21XOYpe1+lm4KVyjgRjFMF +OU6r6X1Vp/irRZMghu9+jEktashWpUrzhyizUQDE54zhsjTBc9ISQuYuEcLsuB5xvQjWd8LxtCo bH4W9aK+E3rFvLkTJM/QQ7vS6bcPWjP9swQzGPSfLF9ZTzTZLkUxvqQJEEG2Iwf02uEnLKIJ2yqS msm0m03XH47YpuvZEeu+fQEg2L8UpK5NRP8Nx7fhGCK8fVTGlMLSmyr9JElZQZwYvgkvnTfWGcaM 7us1MaynSmhvral5rimxS6Sm1WLdkzGMw9g1jPjewA388DEvURT5ARogO14Qua6xOIzauK4Ttb2q sh2y+gDfWhWacKkWaseZZhs4oQkghw/QllPMGFb2Pi4gYwo15YxCRrXKqPGU5+knoirCslyRWyoV E0Tp3SPR5SWAUKB865KV2R0V9NcnnpE8msCbgQ6LEIZGn6+rNLAqLTYP5p3+SwglNw9GKNjZsO2s tqcL5g0ib9gqNojjIZwJjxUbglxaUq1YFPpobUgwiaCDN/vH8nFUMZSJN9yDjUMKKm505uRlBtmv h5SvQC3YeZDF4GAzh9NOq5yxJYiAk7KCLL/OOdc/8IhjUy5IQzkcFFs8GUDBvFRmJgrdPVR9HqKx Vu/AD2hp/cOwxYd+YOh3UIMwQmbI+eFFkC3eQYf3wgt0mp0fXgTZ4g06vPtteH6AEWULODwAHPux TovzA4woW8DDDrDvx5C5Z7mFEWULODoAHAWDM805RNkCjjvAiPZMkw5RtoAvDgAPw0if/ee3hxGl PqrtfY/oX+C6h/vyR934gb3x31PFyB2nKVtXPIOaY/ASN3+moMj5A0psypdwL+nb31zMWLlq9nCw 0ERifaILqK5mOXpHP1dVZblQuqw9Vl/Nq4bEb4jveu5ppRTZu/vGoiq0FF9XFRZzhyQHL0HyEqoR zfJvGyrgDZboZ+osCOd7Ev3L7P6azGcTcssYlDurH8T20LKtey0y3xQPTzjXxT40Z7az+KbeA5pa cH2Udl0y6zbkf+/vJfSP2Az+GU3iwSSahL2Lq2jWC6LQ6114vt+bTuOr2SSY+mHo/eW0fZHELrME dHgcPd9zmJzDruLL579ff/n8T6cUvB99fKXJOCkzdOFtel0YYkes21kubmn9odHnPfwFALsWyl6Y qmGnYJ6BaWeCPuyfCON/AQAA//8DAFBLAwQUAAYACAAAACEA0LFUnwYEAABXDgAAIQAAAHBwdC9z bGlkZUxheW91dHMvc2xpZGVMYXlvdXQyLnhtbNSX227bOBCG7wv0HQj1dl1Lsk4RYhdx4hQLJG5Q pw/ASLQtlKK0JO3au1igr7X7OH2SDg+ynNhpvUK32L2xdRh+4szPmSHP32xKitaEi6JiQ8d77TqI sKzKC7YYOh/ur3uJg4TELMe0YmTobIlw3oxevjivU0HzG7ytVhIBg4kUD52llHXa74tsSUosXlc1 YfBuXvESS7jli37O8Sdgl7Tvu27UL3HBHDuenzK+ms+LjFxV2aokTBoIJxRLmL9YFrVoaPUptJoT ARg9+vGU5LYGb2UhKXFG4Gw2ozliuISH9+ohmtEiN69Efc8JUUZs/ZbXs/qO6xHT9R1HRQ5RdexI p29fWDN9y8AMLvpPhi8aEk43c16OznEKvqPN0AGJtuoXBuGUbCTKzMOsfZot3x2xzZaTI9b95gMw g91HQd3aeHTojt+4YwLh7bwyphiG3lTZR4FYBX4q94172XTdwJTPCl8vkQl0JrmmWVPzXoekGSJ0 WJu57oIRJWHimoj43sAN/PBxXOI49gNloKLjBbHrGot9rw26TuVmXOVbFdUH+Neq4JQKOZNbSnS0 ISY4hZnDD2hLsUoSwnofZpAkpbykBEMSWWXk6JIW2UckK0TyQqJbLCThSOrVIxTyHCYhQXmLJCy/ wxy/f0JWwcMpfBnC0cwQLo0+z6s0aFSarR7MN/0fIZRYPRihYGXDsmu0PV0wbxB7kVVskCQRlIHH ikUgl5ZUKxaHvrI2QTCJoJ0366eJx1HFlEx0TT1YOKjE/EZnTsFySHh9iekC1IKVBwkOgNUUCpxW OSdzEMF80gIsy29ZQRirqaMOQEWxwEELPPMCvVA7ABXFAoMWuIt0B6LCWGK4R0z8REvTgagwlhi1 RN9PQN5uYVQYS4z3iHEw6CqMwlhi0hIVrqsyCmOJZ3vEKIx1DnSIo8LoitAUJoX/AXUJEvtnlaag KU3vSQZbiwV00+D7tQnayeUSrMkF59WnJcG5aOvPt3pLLqE6/w7bAUznkK+6bJmKolqujqa6mOnA qsJqJWOqAjT3be39Xq1RehytIFDFDzSz39q3t4/0sjnoMnnBpW7zx/rNtFqj5Bfku557WmtBO5wp dv+4yYSHSur+C/ulptkf2Q50VnIOtVpL+dsKc2imjZondCH6v1Pz18n9NZpOLtAtIRK2zD9J0uhQ 0uhfTE44RExX5VFV9X4FEvC/m6NzOBOoDf4fYy8chJ476I2vo+tecDVJemMvPutdxVeD8cS/cOPk 4k/H7nWFOjkwcFpViqcZrjcgz1cFOfry+a9XXz7/3a4GmIQCPbN7PCnFdZUzhxi4VEcdfU6h/BbX 79a6EsFxDhLuUj+qYTWa2pi1JorRHAhHXwEAAP//AwBQSwMEFAAGAAgAAAAhAPZnryV2AwAARQwA ACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWzUVuFu2jAQ/j9p72Blf0cDKWVd BFSQ0mlSaVGhD+AmDsnq2JltUtg0qa+1PU6fZGcnARWCCm03bX9CcO6+3H139+XaJ/OEoowIGXPW sRoHdQsR5vMgZtOOdT05qx1bSCrMAkw5Ix1rQaR10n37pp26kgbneMFnCgEGky7uWJFSqWvb0o9I guUBTwmDZyEXCVbwV0ztQOA7wE6o7dTrLTvBMbMKf7GLPw/D2Cen3J8lhKkcRBCKFcQvoziVJVq6 C1oqiAQY4/04JLVIIVt+88XqQqr+mAaI4QSOJrGiBAEhyONMgbMxkOlEEKJNWfZJpON0JIzfRTYS KA6AWavwt+ziQWFm/jIwgxt7zX1aImF3Hoqk28Yu5I/mHQvKtNBXcMIumSvk54f+6tSPLits/WhQ YW2XL4AIli+FCqd5RpvpOGU6OR2NZVa5KQbXc+7fSsQ45KnTz9PzL7ISTOes4dMI5WQrzWxhlz80 fJT2Ejg1ZKl5nwcLnfgN/JpD7FKpxmpBiSEEwsYugMMF6KdY9zJhtesx9HKiPEow9HpBnup6NPZv keKIBLFCQywVEcgEA50PkG1gR0FxCkjCghEW+GoNWeeHXXgzBF1GCLc5hduJPCyJLLoJjSj2ScRp AEE4L6M1DqApSuZfgVEoAKIZXVL3QoZ12xqC5SOGcxYNlXApX2nS2KOoY+JzmFFKMkJ3gDdM7wE/ iWKxO/qhruMe6Gd8JlS0c/DNfeHjsBIdlORVe7tZ9vYV8eETMgXdNKGCnpYyUCEUIBleBNakJwS/ iwgO5KqLl45aKdf0I1Aw3t9A9jENLRBd3fxmyI2MaOMNPdFVoUyPrp7UHK8c3kp5MQ4ZbRhb7AYk BB3IRx8mIz+GBi7VSJsbMaqwL46qhyiIhTJSXiVYvdkUOe+RU284j1p7a/3QEu6ZKnW0Wcmjp7Xp 2ZUMlchL+XWGBahxWc0ntOz/rObnweQMjXveEI3jgKAhIQoWpL9U2NZmYVt/sLCwMl7MksraGgX+ pyc1hB1Qr3LfTw/rg95Zf1A7bjUHtabjNGq9Zu+45n3sNwee43yon/Z/WMVWIylUlUHSujvX1xHz WdiuDar7cP/z3cP9r1U3QBAaaItQ7zToRuvydRVu9WprNlIqhji9zIwewfIOY+eZoxS6MVdIf2Wi Mcr1v/sbAAD//wMAUEsDBBQABgAIAAAAIQBprjQamAIAAO0GAAAhAAAAcHB0L3NsaWRlTGF5b3V0 cy9zbGlkZUxheW91dDkueG1svFXhbtowEP4/ae9geX9HQ9IyaARUQOk0qaVo0Ac4EqeJ6tiZbTLY NKmvtT1On2RnJylbS6VKrfonOMfdd/d957v0TzY5JyVTOpNiQP2DNiVMRDLOxPWAXi3PWj1KtAER A5eCDeiWaXoyfP+uX4Sax+ewlWtDEEPoEAY0NaYIPU9HKctBH8iCCfwvkSoHg6/q2osVfEfsnHtB u/3JyyETtI5Xz4mXSZJF7FRG65wJU4EoxsFg/TrNCt2gFc9BKxTTCOOi/y/JbAtku+IgbihxbqpE g0+HyDxa8JgIyNEwdh7WqIulYsyeRPlZFYtirpzvrJwrksU2to6hXv1H7eZeBbrhwXsQft0gQbhJ VD7sQ4gSkM2AYqe29olBELKNIVFljHbWKL3c4xul0z3eXpMAK7hPallVjB7TCRo6p2AYmXOIWCp5 zBTx7wlWUYAo5zK60URIpGyVqJhGs7LBtfRtpiIllfSxwYv3A5sIPKGoH5LzHVmnkHV2hyZeo9xO R7MZy3hrNVnhrzNCyLVZmC1nTitkBCHG4wM7g/3Dm85E62pBSZwp4+QjOjcTzgBnolbYDGeyJL2P JGj77T6qZbCCGoeJeA4Kvj4JZ+lCiImx5qZAPFbiPi3xYSPxmZQGhf1X5OA1RE6MqlT+tgaFGRqh mwZVXXlrob9Ml2dkNh2RC8YMLos3UvuoUXvBs5iR2TpfPdD88DU0x7WJ0Htldz11ar/4fie4oezS +dkd9Q5H3VGndTzuTltH3Y7fOvaDoDWZ9MbT0dEk6HT8X7QeOm2ZC6xu73Q8molq5uwo3N3+/nB3 +2fXKcxvMV4yGW5Aqp2KR7tz3drk6gKKy9INMH5k8NZOnKnAm1KvlZ2LxWg+U8O/AAAA//8DAFBL AwQUAAYACAAAACEAm95lVs4CAAA/CAAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ4 LnhtbLyV4W7aMBDHv0/aO1je19GQFAaNgIpSOk0qFA36AK7jNFEdO7NNRjZN6mttj9Mn2dlJaNdR CU10X8Cx7/6++/l8HpxuMo4KpnQqxRD7R22MmKAySsXtEF+vLlp9jLQhIiJcCjbEJdP4dPT2zSAP NY8uSSnXBoGG0CEZ4sSYPPQ8TROWEX0kcyZgLZYqIwY+1a0XKfIVtDPuBe32By8jqcC1v9rHX8Zx Stm5pOuMCVOJKMaJgfh1kua6Ucv3UcsV0yDjvP8MyZQ5ZGtSw9mV4CVGzlQVMOnjEWRPlzxCgmQw sbJWyJnZFZ2vFGN2JIqPKl/mC+Uc5sVCoTSyArUj9uqF2sx9CjCDgffM/bZRIuEmVtloQEJggTZD DEdW2l9wIiHbGESrSfo4S5OrHbY0me6w9poNIILtpjarKqO/0wmadCoO/jarypSA66WkdxoJCXna 9Kv06LxoxGzOVj5P0BPwtV216Hg09hqYOlhmcyaj0iZ+A/9ukoRcm6UpOXNAIGwSgjj8AH5ObF0z 0bpeQl1nZsIZgbqv4ZnRhKf0DhmJWJQaNCPaMIVcFcAtAMkB0DFwOLUkE9GCKPL5mbLNj4SwMwTd RAjDCuHLII8bkOfEMLTghLJE8ggiCA7BNDKQ8je4FoTHGAoRqsR3iTu09gBegXGUKuPqcBftuSxQ /z0K2n57P7BoK/ePiDsN4gsp7dE+hXx8CMixURXlL2uiYIcGdFP0r1bMWzK7QH+ari7QfDpGM8YM tN//RLvb0F7yNGJovs5unjHvHII5PEQgvRO7uziHqe8Y+r3t3t974/7xuDfutk7OetNWp9f1Wyd+ ELQmk/7ZdNyZBN2u/wPXjUzbzAVEt18Hqvqa7TEP9z/fPdz/ejwp2N9qvNBy9roZrgdVjxMM7Qvm 3h+uZiS/KlyThGcbqnbipnKoFHvPwPTRxGo0D//oNwAAAP//AwBQSwMEFAAGAAgAAAAhAEAyHKWh BAAAwREAACIAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTEueG1svJjdjuI2FMfvK/Ud rPS2LCQkJEQDK4ZlqkozLCrsA5jEDNE6H3UMC60q7Wu1j7NP0nMcG8gss8NmaG8gBPtnn6//cXLz dpdysmWiTPJsYNlvOhZhWZTHSfY4sD4s7lqBRUpJs5jyPGMDa89K6+3wxx9uirDk8T3d5xtJgJGV IR1YaymLsN0uozVLafkmL1gG/61ykVIJP8VjOxb0E7BT3nY6nV47pUlm6fnikvn5apVE7F0ebVKW yQoiGKcS9l+uk6I0tOISWiFYCRg1u74luS/A2iKJFjuLqGFiCzdsawiWR3Mek4ymcGOWRHIjGPmU yDUZ0wL3ocaUxUIwhqOz7S+imBczoaZOtzNBkhhRGmG19R96mPqZwTC4aD+Z/mhINNytRDq8oSF4 hOwGFgRuj58wiYZsJ0lU3YyOd6P1+zNjo/XkzOi2WQB2cFgUYl5UFn1tjmPMWSSSM2IfrKqGUph6 n0cfS5LlYCeaX5kXTbcGhjYjvliTyv0SUXpc9afyhxlfKp+ajR48Yft9xwkgb8FyN4As6zzxiucG PRduEvSN1+v53UAtYkiwSIUuQrm7zeM9unQJ3xA5mkXrHDJ1iTNoyEs5l3sOcYbrLbdhR4TyRygl DllAw5itfoNb5R8DC/Idllwayw/jIch1DriYhuAI+ICpnGIlsqz1YQ6VmMoxZxTw2iQ5HPMk+khk TlicSPJAS8kEUY6DuoWdIV2qNRSSZfGMCoqbOiVjLGgIK4PtxmblBozH80HvmqCbMphxGrF1zmPY hIMugmIxAW6UAlCBFpQL5LJJmGaJ0LMd3/eqoJnqqOWBa9uYLJcmwrPRT6m4V9WYZDFIC15iKJeb KeinmnWSE11ICr2izh4cC5cOJlKFcj0fR5FLeM7RAg3RvO6R17ddlfwX8XBklRvAQ4jmuUee3fVt LLHLNohFcAAiRQO9E2AA1dsMiBQN7B2BoAawwUY7RIoG+idA31WRa2AyUjQwOAKRdnlQaj5Eigb2 T4A9z28YFKSc16RntIPEiZCmyzRREdeoyAIr81RCupgrr5UQVG6QTpDgNeUrrSZKnFQ3UdZim50r w432m2Zwtq14XWgaVdc4NtuanAQdaDLVIob0jbaidOFcL/kuNbFr1Yq9SCdGQzWxa+qEEM1rqCZ2 LXGvoCb9K4tJjXcFLanxriAlNd4VlKTGu4KQ1HjP6wgkEoF2cjjEqLRqftZB0VBHnbJ21mmiRJ5R ondUspoSuddQolh+pUN21Q5Rf84KkdI/cyIzp9CaXKgf3zgzHtT53Olxmm9J8DNxOnan5jxQtfMH xVeLfc+4+C7P8ah6KvfqfPZauV9JUXn59w0VsII5Pr5wfvyPHf3rZHFHppMReWBMwgPw/+Rt33h7 zpOYkekmXT7xee8aiQ2vAgB91u0vNNrvcfsKnrrxyflPfxR0R/7Ia/Vv/UnL9T271bcdpzUeB7eT kTt2PM/+y9IPkSVansHusHm9rDIgTqqi5PDL579/+vL5n2OkYH1kvKYy1BmgejEAl/geQZ1vuHig xfutEkJ4cQJZO1a3CsgU2A0OPQ5Bhnn1MvwXAAD//wMAUEsDBBQABgAIAAAAIQBcdsCHoQMAADMM AAAiAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEzLnhtbLxW0W7TMBR9R+IfrPBKaZM1 bRetRV3pENJWJtrxbhJ3iXDsYLuhBSHxW/A5fAnXN3G3lk5kDHhJ0/j62Pece4998nydc1IypTMp hp7/rOMRJmKZZOJ66F0tzloDj2hDRUK5FGzobZj2no8ePzopIs2Tc7qRK0MAQ+iIDr3UmCJqt3Wc spzqZ7JgAsaWUuXUwF913U4U/QjYOW8HnU6vndNMePV81WS+XC6zmL2Q8SpnwlQginFqYP86zQrt 0IomaIViGmBw9u6WzKaAbIEYs8gMZ2ORLNYewXhVwojvjYCCeM4TImgOH95CaBZTTjCeAGNkwdYG w3SxUIzZCaJ8qYp5calw9qy8VCRLLFqN4rXrgToM/woIg5f23vRrh0Sj9VLloxMaATtkPfRAxI19 wiQawSZIXH2Mb77G6esDsXE6PRDddgvADraLgv5FldGv6QQunT1S/G161RwKGOcyfq+JkJCw5aHK M56VDtUmb9cpUlJpYqweHpEqA+UqiepZVSjS5GZrpNrtf0tQrxccdzsVTUG/2zsa7HIVdMI+jlvG wkHoh0GIizgkWKSCLiKzPpXJxjL9Dn5BUFs0Q49Rm3wFy7WZmw1nqAewRiNICR4QzKltNCZaV3No tNxMOKPQiLV2ZjThWfyeGElYkhlyQbVhiiAF0JYAeQLiGKiNGpKJ5JIq+mYP2bJKI1gZ9u32iylY Zu/W8ehXHW01XXIas1TyBLYS2AyhEZxgfySpJW5PUWgLqFlXD82V7YZ9MBas/0PC9jr+8cCO/yth od4IL/lWwQcKbelGnfWO0JWYqCg83JLI1j1qa85iCTbFWcl4A3iU+h7wizRTzdGPqlZpzNeZXCmT Nt58977w2fIgOvjpX22xrmuxF9Swnc5CQh7aWYkBV/kERyHlS6/uKfQWdEnrrPhy2y6xn51JOFND 52pqY0mmDJ40hwxtJksyeEqCjt/Zqbk7iSVbuD90sdBRfCaldc/b9oVl8VCSl0ZVLH9YUQUrOKJ/ 417/mOhX08UZmU3H5IIxA1eu/8R2z7E951nCyGyVv9vjHE/Sh3IOl0+APkg7+tTfqe8lXO/s/exz fzw4GvfHYev4tD9tdfuh3zr2g6A1mQxOp+PuJAhD/4tX31C0zVzA7pod8uDf2F5m9OPrtyc/vn6/ UQrWtxh3WE6jzsBjvrp+wqu9sOJ5zdUFLV6XaLdwVYeqneCnAirF9hmE3oRYDHfZH/0EAAD//wMA UEsDBBQABgAIAAAAIQAazpup5gQAAEgSAAAiAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91 dDEwLnhtbMxY7W7bNhT9P2DvQGh/59rUhyULcYrETYYBiRvM7gPQEh1ppT5G0a69YUBfq32cPsku KdGRFCWWk27YH0eRDg/v57mUzt7uEoa2lBdxlk4N/GZkIJoGWRin91Pjw/J64BmoECQNCctSOjX2 tDDenv/4w1nuFyy8IftsIxBwpIVPpkYkRO4Ph0UQ0YQUb7KcpvBsnfGECPiX3w9DTj4Bd8KG5mg0 HiYkTo1qPe+zPluv44C+y4JNQlNRknDKiAD7iyjOC82W92HLOS2ARq1umiT2OXibrX5f7gykYHwL N7BxDp4HCxailCRwY5alAhjQp1hEaEZyaYfCFPmSUyrR6fYXni/yO66Wzrd3HMWhpKoojGH1oIKp f1OAwcWwtfxeMxF/t+bJ+RnxISJoNzUgcXv5C4uIT3cCBeXN4OFuEL3vwAbRVQd6qDcACw6bQs7z 0qPH7pjanWUsGEX44FUJJbD0Jgs+FijNwE/pfuleMN9qMumzpM8jVIZfSKoKVz5U8dD4QsVUG3qI hO24UFsqHKZrjZxWTKzRyLOwZSAZGYzHZoWoe1wy577YXWbhXkZ0BX8hcSQNogwKdVXGmRViIfYM 0kx8tmUYDEKE3UMnMSgC4od0/RvcKv6cGmAS2LTSjh/wkGO4rvFAhIkPcYAfWMqIbESaDj4soBET MWOUAH3lkzifsTj4iESGaBgLdEsKQTlScYO2Bcsku1B7KEqahneEE2lUnVmmgviwM8RX+wyXZbaf zjkEsdkFd4wENMpYCEaYr6uAOIT61UXSP/mW4zoyobIZurLvYIwBUWbf8RwLQymU7pcNpdwu61BH QmdftVY9VVXKW5m2ZPWVlDUAXJpVvdarwqtjNQCwVgfWrmM1ALB2B1ZW28EGDQCscwyrAYAdH8Nq AGDdY1gNAKx3DKsBgJ0cw5aArh6ClQgYDs3yyp6Smqpaqmj0VNk3qnngR2+pCveENl7QIEtDxOiW sh70qrdOoF9GMe/PrhriBPbrbMNh+vU13paFeQp9vO5khzH3XdXM1mq2lKmuS5kKCIx9PapeNMzk BAEJh1EQEbY24AwAAqcSqYaalBx1sVAVL8VX3npuumHbcnDZ5w8jvzHe7PEEj8avFjiUEH6jjhhx GsJpR15K01abORwKVTZrmoYbOiVnosRCJ0p5q6j0jO7F19DTlkZWfBNsy11RL76GNrZ0tOLDlovH fQknz2it5vNMT0p9LwMbfC09rvhM0wPzXsLX0mzN59pqbJ1uX0vXKz5J1jshDX9b2q/5xo77snz8 P+YDdLY+TagDhjzmPn2ucrQSvSOCNpRIaedrlSgUj3QIl6cF+bbRKUTQ4w8edJ6HlAo8c3YNYy7U q0jXKXaebZH3MzJHeNSYfk9KPDrQwb4vObqOdYivs0wemety78gB9dogrwUvo/zHhnDYoRJ8fORI +y8H+ter5TWaX12gW0oFvIf/R9F2dbQXLA4pmm+SVSvm4+8Rc/giAdSdYT8yaE8J+xpe/uUL/F/u hWdduBfOYHLpXg1s18GDCTbNwWzmXV5d2DPTcfDfRvUuW0jPU7BOnX1a71+PewJGJdgk392+ff7y 07fPXx8yBfvLJ08cfnp1htKg8vsEXMrPGargGb8l+futmtfw/QaqdqZu5VApYI2EPkAkh/4CdP4P AAAA//8DAFBLAwQUAAYACAAAACEA1nqNL1sDAABTCwAAIgAAAHBwdC9zbGlkZUxheW91dHMvc2xp ZGVMYXlvdXQxMi54bWy8VlFv2jAQfp+0/2Blr6MBCoVGQEUpTJNaigbdu5s4TVTHzmyTwaZJ/Vvb z+kv2dmJ6eiCFFq2lxCc8+e77+4+X+9slVCUESFjzvpO46juIMJ8HsTsru/cLCa1roOkwizAlDPS d9ZEOmeDt296qSdpcInXfKkQYDDp4b4TKZV6riv9iCRYHvGUMPgWcpFgBX/FnRsI/BWwE+o26/UT N8Exc4r9osp+HoaxTy64v0wIUzmIIBQr8F9GcSotWloFLRVEAozZve2SWqcQLRCjFisHGTuRwUrD GUDo/pwGiOEEFhaxogQBQegzGMc+pmhBVsqYyXQhCNEbWPZBpPN0JszuaTYTKA40WoHiuMWHwsz8 ZWAGL+6z7XcWCXurUCSDHvaAFbTqO5C8tX7CJuyBE8jPF/2nVT+6LrH1o3GJtWsPAA82h0Le0zyi v8Np2nByUhqbqHJTDFsvuX8vEeMQpw4/D8+fZhZMx6zh0wjlKVCa38Iu/2j4sPYSODVkqdU5D9Y6 8Fv4NYvYo1LN1ZoSQwi4jT0AhwfQT7GucMJqN3Oo8ESNKMHQAQV5ajCisX+PFEckiBW6wlIRgYwz 0A8A2QN2FCSngCQsmGGBPz1D1vFhD04Gp62H8JpTuJvIY0vkVk2hGcU+iTgNwJXmIcjVVDmIixia IK92B+oSisZmZh/GtYwACsHaae1dGf+QLkQzuiH6lfnQRW7SIbfykXNuiIeHPdIEtUcJzInPoa8p yQitAG8ysgf8IopFdfTjnNHKfE34UqiosvOtfeHjsBQddOegndCynXCBFdlqAEMISLHVjhepS6Cg +b/BVYFpaEvfSIARGS1F/0Btglgoo8hlujPlGeq+R816o75VczuJRRu4F4pN21I84VyL3J8qY8ri tSSHSuQsf1liASdYol8iMjtkpbwtNsyUEf1xvJig6XiIrghRMJL8J7ZPLNtzGgcETZfJ7TPO24dQ dhjOALqUdqNTh6nvEMYgPcd87wy7x8POsF07Pe+Ma61Ou1E7bTSbtdGoez4etkbNdrvxwymudKkj Z+Bdtbs4v+H1bfv48PPd48Ovp0zB+Rpjh+RU6gxzG+djGrzqwc5MYlRc4fQ6M3UFoyxU7cgspVAp us/A9MlEY9hhePAbAAD//wMAUEsDBBQABgAIAAAAIQCTqn2YuwAAACQBAAAsAAAAcHB0L25vdGVz TWFzdGVycy9fcmVscy9ub3Rlc01hc3RlcjEueG1sLnJlbHOEj8EKwjAQRO+C/xD2btIqiEjTXkTo VeoHhGSbBtskJFHs3xvoxYLgZWFm2TezVfOeRvLCEI2zHEpaAEErnTJWc7h3190JSEzCKjE6ixxm jNDU2011w1GkfBQH4yPJFBs5DCn5M2NRDjiJSJ1Hmze9C5NIWQbNvJAPoZHti+LIwjcD6hWTtIpD aFUJpJt9Tv7Pdn1vJF6cfE5o048IlnIvzEARNCYOlC7OMg80dwVWV2z1W/0BAAD//wMAUEsDBBQA BgAIAAAAIQCi8bD+zggAAK43AAAUAAAAcHB0L3RoZW1lL3RoZW1lMS54bWzsW1mP48gNfg+Q/yDo fbd1WLLUGM9CJ/KQRYLpCfIYVNuyrR1ZNiTN9e9D1mWV5S7JsbC7wdgG2nKZYrFIfiSLpX73y7dD ZXwpmrY81ivT/tkyjaJeHzdlvVuZ//qY/xSYRtuRekOqY12szO9Fa/7y/q9/eUeeu31xKAy4v26f ycrcd93p+empXcMwaX8+nooaftsemwPp4Guze9o05CvwPVRPjmX5TwdS1qZRkwOw9f6TFlvyueqM tGjLXW2+FxNkFcxSdy0OrKvmBdkX/C71HsOmd20+2UjbNrvXpGqML6RamRZ9mU/v3z2RZ05QdUO6 nL44HSfYfHLG+FGCqhvSBRa+JT9KQNZrWM9w7jjOrMzltD0idjnk7cIrDBX6Hn93ILOyNsaUErHL xYBe0VmPiF16A/o0ytIsV+ShRIzeH9A7qZMGkUJPifZVWX8aUFtWCC9OLUm2x+pvV8nDMEksofgz FVhf+hBOsT3WncajTKQ5kN+OTQ6E+KUiXVkb3fcTeOsa/DZqSlKhVOS5IL1xNrRuL4ZgfoXdoaxn 5X1mBzOdF0eXelBX+o/ttlwXdIXbsqpeuu9V8feWLrI9VuUmh0G8j+K5kEg67eGSm0Gh2zWE3mM0 x+7fZbd/2ZMTKIhhctdy1rvWOB1bACSd+CpvnBSU3DHkeuiGTJst6X49btiw2we0ZEPhvaOhQkzk IoOpk7nL+yazmVRvqk1dmk1Fo76jLE0uGWw4XBoMSm2C6xsEA7XtQ0RF2Y12Tapig3pnwU6YBacW 17OYqN2TTcFthOse2simRhK+QuM2+M4VGwVUdK3WerOFyPaO2aYYqT/d4o3phPXusZKIUMIyVDmX cKzqPjir2vi6MkPP8UxjTU4rcwsxCS4PJ7B6W+9Mg1Q7SOXrrmFuPwpmqvizNUOxMPC+HuJsS4wP FqzEgVPTdilp98w16E/cBaoaZ2LyOx6oda4FME//H6RwA3CGP0wK0KNq2mK7LdZd39i9EdQd+8pD 6fFzVzQv+81X47X63HwgYH50VVjPpmy7lUkjAn5poLyiv8BPanDmgfFKpYSzkeq0JzzcIkQFkhk5 dVUpA/3WEw/WdlV2urjbl0IhP9NS+m78gy0F80lRF+4GLbCGwrshBuJ1ZR6bbn+EKHTal+u8gWKH xg7wFgOiC6ZrA8p/+tkUX/CTYY7xQG5Vudt3H8qd0ZSQj7p9UxT/hLBEvW+Emc1zF2MpGFGP6onb npjYr8WXovqIMdDH3G4ae3B1Gk14GKB0l/6nfucIet1hkdPHmxJDZO5lGPi9Kx8GZliUGodpQSP0 L0Wk2lIrH3Y/vV3k3v5C8IdzmbUQqIDJeqkgvJr7JotwY6plEWuwYscTwoEVhyuGQVkQnUi3N/AP 5L+yWVfn+vbj8QPEVgP2gsgM3Aa8+idWeBgYINngKxRObJA5E7JiquXVLWpNJOuLYHpvpSvnvbA3 SjbF3jcqWxZn6nQKFudUNtewoms29qaqwbKXEIWhrdjIUMPQJkS/R3B8/Q0MzTsDLXWm4lvXECg9 XygOOPjVQbTrWlA8ugsr89FdwA30fd0FcKhfycl43dkrE5pJEHO+wRW0n0wYc3DMwTG4gh4T1O2s MbQy+YUYgd/ZiKRxxYgraBZiZCFGPDEC+wTeghEjPiRN7JpAzw4/TEMsFDYTfMk8vw9BMhwZgY1D K4k/U1Mu9PEtNiWsa8dVTrNlvxzO4zT3bmjK5XkY+oI3txoyZZe/f1MuT7MkVuXXNuWyZRB5CdcN dxuUX3bclLZqkriQRji1JBE+NFAmqkaSn6kgpksfwnsesNnVhvung80tvWxsv+ZqL5g2vHuIuHCk Ab3zR8ImiTLnQn4tbOIwDrPlVNhgbk0EyMZhE+X+UgrzgI32CGhxN2zgDMPPRfd0hiOgm7JN//iJ YUULmyBNfOkZPWyxy2G2yZI8ylU3nfUI6MoRkxY2yzx2p8MGzgz9G2BjWRFsqTgmH7DRwsa7GzZo +lScz80AmyV9cevxo9UeIpTsQd1OdWstbDD6SkeaABvkn4m19bDFLu8/OaXyqyehWtg4Keabqdkm zz1o3XPq8WyDFewDNvCMAS9FWdPgekvA18DGi7yAK32WBw56DxLwJxKuPXCAriSPyUdgA/F04TuK G2lh46d+nqgw0xZpUZRYiXC8CbBJI3wr8lBssVspIhTYR1EcxKo8Wtj4jr+IFwp/7QMHqEtOPQ4b y8rzG2FDN/20JUCbA7QlQJsDtCVAmwNs6dA04BdiK///3RJYvgkbL7HPWpwBNrSnKlxQA5s0T51Q bJNHYKNserldznsVigjFTeNsGfpCBkavhU1iRfBS3FRbpN0Km8wBlKn8tbCJEj/11JaGBjZKABqH TepGji1S2bQi7YeFTfAmbCzLdWXXaQbY4ImDzCIa2OCmXcbIEdighBdFlzbbWFZ8PveYABsETaK6 9aywidI4yNRsqYUNaPAcypj8GtigbqQmx2ED9ejSsnmMeMBGu7cJ34QNumTPzak78q2LEsHRyaVx ZtjbZG4W91oMvWxARVDmRmhLGSdkm4UfRItYyR49/sOWAMLmIhvMC5soSi9gqYWNmy/ThcjEs8PG yuDI8QGbYsLexmYPB/FsoviksjefId34gR97KTeLJt2kdmonwrdH0k1ohVaghmttugmsMIvEhm1C uoEdeBSrVdGsuEl8eIsIz+TR4mbpBnmoyq9JN3meJLJgGE83WZgmsuHwSDfadGO//V8ILgR+ebg2 B258JX/ROM9hoeD1In/18sEw3/iWFy4FxibkGxDBl7lxCm6COLjIB7PiJoZQEott+wTceImXTG9B K+da47hBxcvk/cCNHjdvPygA/yli2Z7MD3fXaZ7jZo6I3bp8kydWIPLSSL4JkmW8FKXFBNwEuZc7 qp/2cDms02I3yiNxZsj4z4qbBFATq7jX5pvA9jxH3W5p8k2SxPA4IrfgOG6CBJKxIP+RcAOPQqgP 2NCH1WCUPub2/r8AAAD//wMAUEsDBBQABgAIAAAAIQAxBPMJ9gYAAC8kAAAhAAAAcHB0L25vdGVz TWFzdGVycy9ub3Rlc01hc3RlcjEueG1s7Frrbts2FP4/YO8gaD8H19HFsmzEKWw33gqkXVCn2G9a oiwhFKmRdOK0KNDX2h6nT7JzSMm3ZIXnJBuKugFsmjwkdT6eGz/19OWyZM4NlaoQfOB6L05ch/JE pAWfD9z3V5NW7DpKE54SJjgduHdUuS/PfvzhtOpzoal6Q5Sm0oFVuOqTgZtrXfXbbZXktCTqhago h7FMyJJo+Cnn7VSSW1i9ZG3/5CRql6Tgbj1f7jNfZFmR0FciWZSUa7uIpIxo0EDlRaWa1ap9Vqsk VbCMmb31SGegYTJlKX7P5vbzUp6dkr4SrEgnBWPmBypKx0w6N4QN3Nncc9tnp+0dKZplNNEXSuMY rocrmQYurKorSSm2+M0vsppWOAq7v725lE6RwrG4DicloI9rm4FazPzkIGbX3Zo+b1Yi/WUmS3xY gM5ZDlw44zv8hEmkT5faSWxnsu5N8t8ekE3y8wekQVm7ASi02hS1shrdV8ePo27YqPQOgCF8zqjj r7SzUwDD6kIk18rhAvS1MIhxDtJ0KKW4zSlJFXZb7QGvZi+EBHevckffVQBcnkqw4w8D948FkWCw 9RQrB8/NV1MVoO/Mbt+IFKaRhRYuorQPgn6v68UnAC7iGHa6YN5mm/XsSir9CxWlg42BK0F1szq5 qU2D9BsR3JQLtDJzSow7twO31/E7ZsLGSFmg/7GiHLiwOfzDPUkfsTnnqWlrUjDbhqNi3Jz6tkGi 0oiXXo5EeocCM/gGICAywIPmQn5wnVtJ4BAUIkhdh73mgH3PC0PQWJsfRmfXkZsjs80RvijHArwE 7JnwBFYduLppjjX8QvBEWRF9wadVgoL4LIjJ1fJ3IqsaOA1G+1ZMc1LRh/CzssYLrRq4CFN6qu8Y uBm0b5hnNCb9lGbvQE80DW99YCsBBGxjIpg0PA5i1cxE01t1UZ5eEklwQQZWOnApb72fuk5aSN34 Fkob32+wBuuzrvJ1h+ncd5gAj9qEg6d3mBQOpkghLjTedairBHEcRl7wUMg5OgwGiW/IYRzC5lAl SON034TneCdh2PHvu064l+u8ExD8MPk2WUdVELK3u7YSEUheQWw6TwsjhcFhwz8xzezkJcXS1+W8 djWTAE0yQinTaBLaXlnJ88IAEwBm9yjuYC4y8b9J8TYnYYwFgSD0e3W2gJDU5Lcm/Tw6Q20XSXI+ W5VImKNWmXFL7JBUZqJnDdc+YbR73xY6e9nCYXUH5p/twsNGVRO6H3HU9fHiSYcB/O0edSeMI+y0 tQgYRm0Mz3HUx2Lk4GLEuGdTVDhQdazKclNiyN1CgotLKURmCiVV6jGjBOJx7eb6bMyK5NrRwqEQ gJz6aobFElzhoPRRWKpoU7BgfDGFSPOBO+H2Jt2T/kHbT2kieOowekPZHluZcHfgVld5IfffyXjb gTtNxELqfG+lTGI5dKsi+8pOEC3+ZckIV3d7bVzfsaJnjHWZ3rlj2VBnEHlEqLP5LIaI50MZuZXQ jgXkAQXk7Hjj2u/G1bvvPt1ndB8oBd8uyoeKBVOgPMKDNq9gRz96Kubi//Sj57uIZSw1lOPHURhN up3uuDXpBsNW2INWLxhPWpPx0B+O41eTUex/AubH0GsKGFEK7I6LxMhu1WKLnH8kTfTZl89//vTl 81/rkgEeAhd6DJ0C7rKmVaECAoINuRKshRayGLgfR6Ne5I/jUWvkhZNW+KrXbQ0nUac16QRhOB7F w3Fw/gn0qbywn0hqCOLXaU1UQ+c9crksEimUyPQLoLDalqVuV+KWykoUhqj2Tmq221DFURjHvW4Q 9zCmwOPCozXf5mGhq+GfEybfkMoBcnngMg0XUr2EVnoNrdncxz644uoltNJraJEkAUobJOpG0wPj tmclEzQ9wM/YIdCrbjQ9naYHGCg7FDU9kevkrODXgAV+uU4m2K+2o2nZgGleFezSb7URMyBAtCl8 HUou+EjCcpDzM8H10NANM6KAb0TaF14bXC443sBPjKWpKhnRDE0FWpeJthw83oEb5nVLYpgBwtuy G3L16C6t4VxTiW9GkBw0s7/C/sOxmMPcYf/x3QQ3npKRBFjloSwIaJ3kRCpqlLFVDdmQ+bnkLUpw NdJP1M5Aoupt7MOaWn5FWRp600cWuyTyYsVEH9F+YrQRYjwdAD5Yo20IcTBfy5QdbbuhoB5r2whx jXa4RtsLul6ENMcR7qcNJYhxDXdnA+7Yj80briPcTws3YlzDHa3h9uFFKaaytXVDvL8isym8rGri zL3UCTWByTfrTLqdOe0rtf8gy2EGY9pmMPpY90dUaoC6GwB1wwDz8hEghqjUAMVrgBAdQwOvHPa7 tSBEpQaotwFQ1OluJ5DvFiBExVxANot1ZB3W/83n7G8AAAD//wMAUEsDBAoAAAAAAAAAIQAh6sLw 10EAANdBAAAXAAAAZG9jUHJvcHMvdGh1bWJuYWlsLmpwZWf/2P/gABBKRklGAAEBAQBIAEgAAP/i B7hJQ0NfUFJPRklMRQABAQAAB6hhcHBsAiAAAG1udHJSR0IgWFlaIAfZAAIAGQALABoAC2Fjc3BB UFBMAAAAAGFwcGwAAAAAAAAAAAAAAAAAAAAAAAD21gABAAAAANMtYXBwbAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC2Rlc2MAAAEIAAAAb2RzY20AAAF4AAAF bGNwcnQAAAbkAAAAOHd0cHQAAAccAAAAFHJYWVoAAAcwAAAAFGdYWVoAAAdEAAAAFGJYWVoAAAdY AAAAFHJUUkMAAAdsAAAADmNoYWQAAAd8AAAALGJUUkMAAAdsAAAADmdUUkMAAAdsAAAADmRlc2MA AAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAAAAAAABRHZW5lcmljIFJHQiBQcm9maWxl AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABtbHVjAAAA AAAAAB4AAAAMc2tTSwAAACgAAAF4aHJIUgAAACgAAAGgY2FFUwAAACQAAAHIcHRCUgAAACYAAAHs dWtVQQAAACoAAAISZnJGVQAAACgAAAI8emhUVwAAABYAAAJkaXRJVAAAACgAAAJ6bmJOTwAAACYA AAKia29LUgAAABYAAALIY3NDWgAAACIAAALeaGVJTAAAAB4AAAMAZGVERQAAACwAAAMeaHVIVQAA ACgAAANKc3ZTRQAAACYAAAKiemhDTgAAABYAAANyamFKUAAAABoAAAOIcm9STwAAACQAAAOiZWxH UgAAACIAAAPGcHRQTwAAACYAAAPobmxOTAAAACgAAAQOZXNFUwAAACYAAAPodGhUSAAAACQAAAQ2 dHJUUgAAACIAAARaZmlGSQAAACgAAAR8cGxQTAAAACwAAASkcnVSVQAAACIAAATQYXJFRwAAACYA AATyZW5VUwAAACYAAAUYZGFESwAAAC4AAAU+AFYBYQBlAG8AYgBlAGMAbgD9ACAAUgBHAEIAIABw AHIAbwBmAGkAbABHAGUAbgBlAHIAaQENAGsAaQAgAFIARwBCACAAcAByAG8AZgBpAGwAUABlAHIA ZgBpAGwAIABSAEcAQgAgAGcAZQBuAOgAcgBpAGMAUABlAHIAZgBpAGwAIABSAEcAQgAgAEcAZQBu AOkAcgBpAGMAbwQXBDAEMwQwBDsETAQ9BDgEOQAgBD8EQAQ+BEQEMAQ5BDsAIABSAEcAQgBQAHIA bwBmAGkAbAAgAGcA6QBuAOkAcgBpAHEAdQBlACAAUgBWAEKQGnUoACAAUgBHAEIAIIJyX2ljz4/w AFAAcgBvAGYAaQBsAG8AIABSAEcAQgAgAGcAZQBuAGUAcgBpAGMAbwBHAGUAbgBlAHIAaQBzAGsA IABSAEcAQgAtAHAAcgBvAGYAaQBsx3y8GAAgAFIARwBCACDVBLhc0wzHfABPAGIAZQBjAG4A/QAg AFIARwBCACAAcAByAG8AZgBpAGwF5AXoBdUF5AXZBdwAIABSAEcAQgAgBdsF3AXcBdkAQQBsAGwA ZwBlAG0AZQBpAG4AZQBzACAAUgBHAEIALQBQAHIAbwBmAGkAbADBAGwAdABhAGwA4QBuAG8AcwAg AFIARwBCACAAcAByAG8AZgBpAGxmbpAaACAAUgBHAEIAIGPPj/Blh072TgCCLAAgAFIARwBCACAw 1zDtMNUwoTCkMOsAUAByAG8AZgBpAGwAIABSAEcAQgAgAGcAZQBuAGUAcgBpAGMDkwO1A70DuQO6 A8wAIAPAA8EDvwPGA68DuwAgAFIARwBCAFAAZQByAGYAaQBsACAAUgBHAEIAIABnAGUAbgDpAHIA aQBjAG8AQQBsAGcAZQBtAGUAZQBuACAAUgBHAEIALQBwAHIAbwBmAGkAZQBsDkIOGw4jDkQOHw4l DkwAIABSAEcAQgAgDhcOMQ5IDicORA4bAEcAZQBuAGUAbAAgAFIARwBCACAAUAByAG8AZgBpAGwA aQBZAGwAZQBpAG4AZQBuACAAUgBHAEIALQBwAHIAbwBmAGkAaQBsAGkAVQBuAGkAdwBlAHIAcwBh AGwAbgB5ACAAcAByAG8AZgBpAGwAIABSAEcAQgQeBDEESQQ4BDkAIAQ/BEAEPgREBDgEOwRMACAA UgBHAEIGRQZEBkEAIAYqBjkGMQZKBkEAIABSAEcAQgAgBicGRAY5BicGRQBHAGUAbgBlAHIAaQBj ACAAUgBHAEIAIABQAHIAbwBmAGkAbABlAEcAZQBuAGUAcgBlAGwAIABSAEcAQgAtAGIAZQBzAGsA cgBpAHYAZQBsAHMAZXRleHQAAAAAQ29weXJpZ2h0IDIwMDcgQXBwbGUgSW5jLiwgYWxsIHJpZ2h0 cyByZXNlcnZlZC4AWFlaIAAAAAAAAPNSAAEAAAABFs9YWVogAAAAAAAAdE0AAD3uAAAD0FhZWiAA AAAAAABadQAArHMAABc0WFlaIAAAAAAAACgaAAAVnwAAuDZjdXJ2AAAAAAAAAAEBzQAAc2YzMgAA AAAAAQxCAAAF3v//8yYAAAeSAAD9kf//+6L///2jAAAD3AAAwGz/4QB0RXhpZgAATU0AKgAAAAgA BAEaAAUAAAABAAAAPgEbAAUAAAABAAAARgEoAAMAAAABAAIAAIdpAAQAAAABAAAATgAAAAAAAABI AAAAAQAAAEgAAAABAAKgAgAEAAAAAQAAAQCgAwAEAAAAAQAAAMAAAAAA/9sAQwABAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB/9sA QwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEB/8AAEQgAwAEAAwERAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYH CAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHw JDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6 g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk 5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIB AgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEX GBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKT lJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX2 9/j5+v/aAAwDAQACEQMRAD8A/v4oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAMbW/Efh7w1bwXfiPXtG8P2lzdwWFtda3qljpVvcX 104S2s4Jr+eCOW7uHISC3jZppnIWNGPFAGwCGAIIIIBBByCDyCD3B6g96AK1lf2Op20d7p15a6hZ zGQRXdlcQ3dtKYZXgmEc8DyROYp45IZArkpLG8bYdWAAKNx4i8P2ms2Hhy713R7XxDqtvcXel6Fc anZQ6zqVpaf8fV1YaXLOt9eW9tz9omt4JI4f+WjLQBa/tPTTqJ0f+0bE6sLT7edL+1wf2iLHzRB9 tNl5n2n7J5xEP2nyvJ80iPfvOKAFfUtOivoNLkv7KPU7qGS5ttOe6gS+uLeE4mngtGkFxLDETiSW ONkQ8MwNAC6hqOn6TZXWp6rfWemadZQvcXuoahcw2dlaW8YzJPdXdy8cFvCg5eWWREUcswoAqQeI NButIh8QWut6Rc6DcQx3MGuQalZzaRPbysEiuIdSjmaylhkdlSOVJ2R2YKrEkAgGlPPDawzXNzNF b29vFJPcXE8iRQwQxIZJZppZCqRRRIrPJI7KiIpZiACaAFilinijngkjmhmjSWGaJ1kilikUPHJH IhKvG6kMjqSrKQwJBzQA8kKCzEKqglmJwABySSeAAOST06mgCnp+padq9pFqGlX9lqdhOZBDe6fd QXtpMYpHhlEVzbSSwyGOWN4pNjnZIjo2GUgABY6lp2qQvcaZf2Wo26TS2zz2N1BdwpcQNsngeW3k kRZoX+WWIsHjb5XUHigC7QAUAVo7y0muLm0huraW7shAby1jnie4tBcq0lsbmFWMsAuER3gMqr5q qzR7gpIALNABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFAH87v7dn7K3if4gft1eNv2g9T/Yp+AX /BXf4T6Z8Cvhx8IL39mPxz8VfhZpfxX/AGNfEtpf+NPFnibxZ8Ovhl8a7W5+D+s3Hx68MeK/DOqa hf6xr/gD4nSP4K0AaDrV1oEGnwSgHntx+2N8Ev2Qf+CKHxw1r9lDxF+0B4G8Q+HPij8Sf2S/hF8I v2popB8ZP2T/ANpL4u+PP7D0P4BTaboenX943gr9mK08ew+OPBGk6drPxAmg+C/hPTodI8Y+JLOD T9gB5h/wTT/af+Df7Jnhj/goz+xB+yH43ufi94B/Z0/Zsv8A9tn9iuK/8P8AinQ9U1nTm+E40X45 /DtdL8caPoc8s2h/tM+GIfiDOiWtzbTD9oi3Wa9n8mUqAfTH7OX/AAS0/YJ+Ov8AwTf+D3xy+OGi 6Bqnx9+OP7O/w4/am+Jv/BRrU73QdM/aj8N/Fvxx4C034u6x8efCf7Q+v2Emt/Dy08Ca/rV1rfg7 RVurf4e+E/C+j6Z4f1Lw7deHbC6tJwD48/aY1lPhP/wW38E/t2+GvHdx448F/s+fstf8E2vAfxZ8 ex6nomoaV46/Zf8A2zPi9+1z8BfFnxH1S48H2ml+GdTsdF+I2u/Av443WseGtNtPD8Gj+DNW1DTN Nt9GkEMIB6l4b1LUfjR/wcFfAH9qeW+up/BV/o3/AAUP/Y1+DMHnyPpd34D/AGMvDHwN0r4i+KLS JW+xm91T9qf4p/tEeEbm9hE0l5o/w88OGS6ZIo7a1APvf/grJ+zj42/aL8Rfskt4O8A/BD9q/T/g z42+JHxR8f8A/BO346/FKw+Gvhn9qrwxN4Mg8G6Z4stP7X0fxX4Y1/W/gL4p8Q6V4h0XTPiJ4Q1T 4dTXnihhrOo6Hrf/AAjl4wB+WWr+Ov2cP2cf2ZP+CpGjeBP2L/G/7JPxgtPBX7MvxV+KP/BMf9pP RfAWv/se2Om6l8V7f4f6d8fv2ddD+Bmvf8IJr/hf4japHeaH8QNZ8BfETTbCbx18LfC39reCfD97 pzT+IwD64/bw/aF/bU/aO+Dn/BX/AEL9nTVf2avB37PH7G/wz+NH7PHj3wp8VfBHxA8SfFv47+K5 v2TND+LXxg1Pw/490P4leEvDXwV0jwt4P+LWk6F8NJdV+HnxMi8WeNNC1a+8R3ek+GbyFNPAPEpP +CoPxq8I6h8Nv2UPgV4z+HPwXtv2cf2Gv2OPG3izxr8S/wBjL9rz9sY/Fn4mfF/4RxeJPDXw002w /ZZvtKg+EPgfRPCei6Xd+KfHviu71zxLrOp+J0svBfhG4g8K65d3QB+5v7Nfx+8RftSfsOfD79oD xj8MPEvwX8Y/E/4KX2v+MfhV4u07V9L1zwJ4uj0rU9L8UeH5bTXtP0nWm0+017T9QOh3uqaVpt7q ehPpupXFjaSXZgQA/mD/AOCQH7QHjD9gn/gl18T/AIJ+H5JNT8d+Mf2Tf2Uv2vP2FtF1adrg+J/i P+3joOh/s72/w708uJ0lsNH/AG7tFbXdYs4rd7nStF+N2jytbXNvJASAaP7IP7S/iH/glv8AsoaD +xh8G9Z0/wD4Tf4i/wDBVz/gob+z9pPxu+I3wk+M37ReleAPh5+zlreq6l48+KGs/Br4HXKfFj4q +NtcGl+H9K0Dw7pmsaNpi614ou/FHi3xDY+HfDuox3gB9h67/wAFqv2gPh7+zz4otvFHgrQ9b+NV z+2t8HP2Qfg7+0Zdfsm/tdfDn4GfEbwp8Y/hv4g+LTfH1v2XfEtnN+0hquo/Czwt8Pvif4Z8cfCP wTr+rNr/AI98OaHL4b8Z2fhfxVHcaWAeE/tXft0ftd/Hf9hD9vz4UzeOdJj1T4MXX7KHijwj+1lo f7Gv7U/7M/hL41fDT4rfG3S/CHi34Yr8Lfjb488M+J/BPxQ8C+INO0abxjrGg+O/Hfgvxh8OfE8W iw6BpV7rGo32kAH1h8df2y/j5+ylrP8AwVF8XeB/h9+zX42/aP8Aghdf8EePBF949j8AeM/hxpXx 78V/tF+N/CXwk8Y3Xj6zi+JXjrVvD+g6TZ+MfEKfCexs9b8QXnw2tNThi12/+Jf2CY6mAdp8YP8A go1+2L+wpr/7XfgT9qOD4BftI+KPhl+xh8P/ANrL4H6r8D/h144+AWmaj4y+Ivxw1L9naz+CXjXR /Gnxb+Nc1zoFt8SL3wXead8RrPXtHvf+EXv9Zl1fQft1vE8AB7p8Nfj9/wAFEvhf/wAFAP2cv2Sv 2rfEP7KfxJ+H37QX7PH7Rnxqg8e/A74T/Ev4Xa3oPjX4Nat8ENM1L4Z2+l+NPjX8UYdQ8N+GZPik Lqy8bXS2Wp+M9O1fT4Lrw/4av/Dt9ProB+yFABQAUAFABQAUAFABQAUAFABQAUAFABQB+eXx1/4J 3eGvin8b9Y/aR+FH7SH7UH7H/wAbPGPhLw74F+KHi39mvxd8PLbSPi/4b8HyXa+DV+JPw++Mnwv+ MPw81nxD4JsNV1zTPCHjTTfDGjeL9I07WLjT5davtMgs7C3AMn4f/wDBLf8AZ4+Hup/s2ava+Kfj R4qvv2cPjj8W/wBp9rjx9440zxhc/HX9pb4xeCNX8A638d/j9f6p4WfU/FnxA8M6F4g17/hAG8KX vgbw14Rn1JYbHw6+maP4d07RwD6A+Lf7JHw1+MX7QP7Nf7S+t6t4x0D4mfswL8WdN8JyeFr7w/ba H448F/Gzwla+E/H/AMOPijpmt+Gtek8TeBtQOl+HvE9lp2nXmgajpni3w1our2mrJHFeWl6AfCOv f8EVvgpqvhDUvgXpH7Tf7aHgn9jDX9a17UvEX7Dfg34r+C9I/Z71DQvEut3+va38L9N1J/hddfHT wl8GNVutX1a2v/hX4Q+Muh+FP7Muo9J0200zTLf7JKAfSnxC/wCCbP7N3xK1f9pO91228V2Wh/tQ fseeBf2IfGfgbQLvwxpPgvwl8G/hxJ8VpPCN58NdNj8JyX3hjxnpB+Lut/YdVutU1nRtMbQfCU2k eHtOuNLuptSAJfhX/wAE6Pgb8H9W/Ym1vwt4i+KN1qP7Cnwv+NPwx+G1zr/iLw/qlx8Q1/aBs/Ay fFPx58Zrz/hEbe/8U/ETxLrfgaHxhd654cu/Bun3HivxJ4p1G90W8tr+xsdMAOx/ax/Yn+Hv7WV7 8KvF+pfED4yfA/4y/AvVfE2qfB34+fs/eMtP8GfFTwHF4406w0nx34ft5fEfh3xn4I8S+D/HOn6R osHivwj448FeJ9B1RtE0i6+xQ32nWt1EAfNt1/wSP+DXi74bftEeE/jR8dv2nvj38Sv2ofCvw48B fFH9or4neM/h7P8AFyz+Hnwo8Y/8LA8E/Dn4c6b4a+Fvhz4PfDjwJpnjG613XptC8OfCqGXWNS8T azqOv3+rap/Zt/pwBa/aV/4JN/CH9o/xZ+0JrsXx5/ag+BXhb9r7wlp3hH9rP4W/Anxr8PdA8A/t ARaP4OX4fabr3iqPxr8LPHvijwv4lbwPbaR4P1/Uvhn4n8Dw+MvC+h6bonjGy12zbUFvgDR8T/8A BLX4fN4u8M/EH4LftIftT/st+PLL4CfDb9mj4j+LPgP4p+FNlqHx0+E3wk0zUNI+HkHxQsPiL8Hf iJoEfjvwjY6zr1v4c+KHw+0bwJ480KDXb+00vW7ayt9GttJAPuj4cfBrwV8Kfgx4S+A/gxNZtfAn grwDYfDnRG1TW7/xB4kbRNP0ddFW+1fxJrsmoanrviK8iD32q67rEt7farq09zqN+9xPcSlwD4P8 Lf8ABIv9lnwrcf8ABOu8h1X4s6rdf8Ez/BF78PvgrNqvifw0v/CxfDcmk+FrfRLb48waR4K0m28c nwZ4r8D+Efif4Ni0CHwXZaH8SPD9jr0dnNaNdaVcAE3ib/gk/wDATWvDN7ZeHviR8ePhz8SLL9sb 42/tzfDX49eBfFHgew+Lvwa+Nv7QOo+Irr4k2PgG91P4dat4NvvhprekeK9c8IX3gH4heDPHWnaz 4Vu0tfElxreq2OnaxaAF7Xv+CWnwb8a/BrxL8NviP8YP2kviH8SPEvx28G/tPp+1P4h+IPhy2/aJ 8IftA/DrT9J0f4e/Ef4b6l4e8C6L8LPh9/whGiaQmg+HfA3hn4VWXw0h0PUtf03UPBupQ+Itb+3g Bq//AAS++G/jv4I/tKfCP41ftAftPfHLxL+1XpXgbSfiZ8cvHvjL4f6f8TtFtvhheQat8OIvhbof gP4X+Dvgv8NrPwZ4ihbxNY6foPwlFnruvXFzqPjeLxZNKTQA3xD/AMEtPg/430H446d8Q/jD+0D4 68RftGT/ALEGpfFjx9rOtfCqx8Va54g/YN8W+F/G/wAMvEVnD4d+EWi+F9M1Hx54g8KWc/xYhg8N tpuqwX2oweCrDwGZLWS0ANH9tL9hzwb8Z4P2jfjVafDeX4+fFX4jfsU63+ybF+z94w+I1p8M/hX8 RfB8HjjVPilY6anjbTvCWp+Lfh78Q9R8S38tn4f+Itvrbad4WvItD1WHS9NvtOfX4gD4E/Yc/Y0/ aIn/AG//AIe/tUfFHQf25vDvgX4D/svfFv4JWWrf8FBPj9+zv8Xfir4x8ZfFPxf8JbnT/DXwx8Nf sw+JPE/gbSPht8ONC+GniS58RfFbxvc2XxP+LviLxjoEurS+LNP8PW2s6UAf0PUAFABQAUAFABQA UAFABQAUAFABQAUAFABQB4p+0p4o17wP+zn8fvGvhXUX0jxP4Q+CnxU8UeHNWihtriTTNe8P+Bde 1bR9RjgvIbm0ney1C0t7lIbq3ntpWjCTwyxMyMAfzK+O/wBvTx7d6n/wSb0v9pD/AIKXfE39iD4c /tBf8EhfDH7THxQ+KfgHw98Bk1j4pftMXY/ZujiTU5PiV8Cfizoumxa5pHj34ja/PpPhnw7oFoLn ToTavaWtsbOcA/UX9lzw/pH7VvwE+JFp+zl/wWR/at+PMKfEjw5bXXx70HSP2RZPGvw5v9A0Se+1 L4daLAv7JGjeBpNI8VWXiPSNY199e8D6/rkb2Glf2HrujwvqNvegHyt+w1pf7YXjHwF+2b8d/iN/ wUi/av8AiG/7KP7Uv7fnwE8J/DbxB4V/ZLsfAPjTw1+zpq/jTwN8P9b8dt4Y/Zo0DxjP4kzbaf4m 1abwz4s8NaVd6/p1uI9Kt9Ge60i4APA/+CZX7VfgL9p/wx+xVf8AjD/gvZ+0F4x/al+Kfgv4P+N/ iH+ypZWP7GtpomrfEqbwtpPjb4j/AAfk02z/AGQrbxnZ+HUvLXX/AA9qMFl46t/E1ro0NyLTxRDq kcWpqAfsR/wVr/aB+Kv7Mf7GHib4u/Czx1Z/CWLSPiV8F9G+LPxpOg+G/GHiL4J/AbxR8T/DXh/4 yfFjwD4C8WwX+g/ED4geDPBOoalqHhXwbd6L4lm1fUMHT/CnijUre00HUAD5A/4J/f8ABQmyk+Hn /BQn4q/Ev9qbxL+01+xV+yj478IaX8IP2nviZ4C8J+Bvjt4pu5/h1pmq/Ff4U+Jfh34D+H/wkufE us+FPiJqWg+D/hVqJ+DXgzxP8T9a8WL4c0K08Xm10bWtUAPY/wDgl3+0X+138c/jP/wUS0H9riKx 8K6x8NfjP8Cpvht8FtPtdHK/AT4e/F79mT4bfGXRvhXreu6bZxXHinx14ftPGlnb/EvXrnUNV027 +Icfib/hE5rXwkNGsoAD5y/bT/bZ/aX/AGd/+CzX7LPgbTPiLLb/ALEk3wR+Cdt+0d8MptB8NNp1 vr/7T/x8+Mv7N3w2+Lkvi640eXxJog8NfGWT4FaBqlsmtW2gy6FrGoT3MMEscs8wBufFv9tr9oK6 /wCC437Mn7OfgT4hx+Gv2OfCumfFL4VfHnw8dJ8OTWnxC/aEi/ZR+IP7T95Z6l4n1DTLjVtEsPhB 8O739n/xEItH1nTFu7/4i6hDrMT2unqlwAfS3wp/4K5fCz4o+I/grqT/ALPv7SfgP9m39pz4iL8J /wBmj9r/AMcaH8MrT4KfGPx1qEmqQ+DLOy0PRfijrfxo8D6H8WLjSbq2+EHif4kfCzwnpHjq6a0t 4pdNl1TR11EAhT/gr18JJdcPiaL4CftGSfsjD48/8Mzt+3eukfC4/s4j4t/8LLX4Mb/sP/C0/wDh dR+Fn/C4GX4XH4zj4T/8K7/4TFgg1k+HM+JAAfLPjT/go98bovGf/BUnwz8VPCPx3+B3ws/ZQ/a9 /Yp+DXwq+Kfwz0z9mPxL4ktNL+LniX9kPS08MXOk6z8TfE91rZ+NepfGO88a6hrer+Hbb/hD/wBn 7xoNNWfwp8d9Al8EWQB9AfEH/gs18MvAF7+0HrTfssftZeJfgj+yN8eNW+AX7Uf7Rmg6B8H4/hd8 IvEOlav4a0q518afrvxk0b4l/ETw7p8HjDw74l8TSfDPwD4s1Hwl4S1KLVdesLW9DaSADt/2kP8A grJ8Of2fvFf7R2laP+zf+098fvA/7Gvh2y8QftcfF/4KeH/hbf8AgH4Ey6l4Ig+I8Hh7U7fx18WP A3jbx34h0jwJf6L408bWnwx8I+MbTwN4V1uw1PxBfQXMeoadZAH6MfCX4j6P8YvhV8M/i54ds9T0 /wAP/FP4feDPiPoWn61Haw6xY6P448Oab4m0yz1aKxu7+yi1O2stUghv47O+vbVLpJVt7u5iCTOA eg0AFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAeU/HjwLq/xQ+B3xl+GmgXGnWevfET4U/ETwLo t3rE1zb6Ta6v4t8IaxoGm3GqT2VpqF5Dp0F5qEMt9NaWF9cx2yyvBaXMoSFwD8V/DX7B3/BQf9nX xl/wTq+J/wCzvZ/sbfEnxd+yp/wS20n9gL4t+HvjR8ZPjb8NvDmpeLI7v9nrWNV8afDrW/A/7Ofx M1PW/DsWpfBK4tNP/wCEm0XwhqVzY61DdXOlWlxE9qgB+rP7M+sftsatH4zP7Y3w8/Za8BSwP4f/ AOFeD9mf4yfFr4uR6rHKutf8JUfGbfFL4E/BNtAeyaPw6PD66GniVdUW71o6k2kHT7EamAfPf7MH 7HHxO+CnwM/bo+GXirXfAmoa9+05+1f+3V8dfAV34f1PxBdaRpHhH9pzxp4j8R+AtO8X3Go+GNKv bDxHpFlq9tF4vtNGsNf0ywuknTRtX1+FY55QD3r9hD4FeLv2X/2Jv2SP2bvH+o+HNX8c/AT9m/4M fB/xhqvg+71PUPCmpeJvh18PfD/hPW77w1fa1pHh/WLzQrrUdKuJtKudU0LR9Qnsnhku9MsZ2kto wDzX/goT+y78Sv2mvh/8D774Naz4AtPix+zP+1F8I/2q/h/4Y+Lba7B8JviT4h+FcXibTl8BfEPV PDGma/4g8OaVf2Hi6+1vQPF2keGfFV94P8d6B4R8TxeGtZ/sprOQA+KtK/4JZeMv2qviz+0V+0H+ 37Jofwt8TfGfWv2VL/wV8Jf2K/j78YNIh+H13+yFL8U9U+GfxF8WfH2w8JfAnxj8QPiqde+LGoXN pe2vgXw7pfg608IeDY9HutUvNLsr3TAD2P8AYR/4Jo6n+xt+1l+218ern4y/GT4jeFP2gNX+F1v8 LtL+JP7TPx1+NeuDw14a+Dnwq8LeK9Z+MWnfFC9u9J1r4l2njrwLqum/D3xmdV8Ya74f+Ed1ZeD7 LXND0m4u/DFqAUf2vP8Agm94q/as/aC/ab8cap4l8IaP8Nfjn/wTNg/Y68NTpqOvp8QfBnxv0f42 eO/i94O+J8NhB4fbR7fQ/Bera14R8R6Fqtr4kuNdTxT4fZG8OraQwX1yAePfCr/gl78ebfVf2EvH Hxz8d/Cjxd8TPAfxP/by+N37dfiTwlqfi7T4fiF8Rf20vg943+HC23wVivPBVs954e8AWmv+FfAW hHxcvgq6034b+B9Elhtr/Vbf+zJQD5w/Y9/4In+Ov2ffEn7MHgTxV+z/AP8ABOW48HfsrfE/wx4u j/bD0TQPF/iX9qT42eEvhg+oal8KrW8+EviH4W6N4D+D3xbi8Qaf4O1Hxx8V9J+MnxCmJ0q7vvCe i2mtalJqFgAYXww/4IW+KfhjrqfCJP2ff+Cdnjr4Rad+0bffFPR/2v8A4i6L4w8VftX/APCmNY+M d58V734T618E7/4WP8LtZ+J+k6dqM/w28N/Gq4+MQ0uw0Cx0zxXL8NpvEsCWduAfUX7RP/BOL9q7 4oeOP+Ci2ieDdW/Z9X4R/tnfH79gH9pjwX4l8T+N/iJpPxC8IeL/ANlHxV+xrY/EHwH4o8I6V8KP EXh648P+IvAn7N/inXfB3izSvGM+oN4s1jw/4W1rw3p2kXWpeLtHAOt+Jv8AwTZ+OXjP9h3/AIKx fs0aV4q+E9v48/bu/aG/aI+LXwk1a/1zxfF4S8PeHfi3pnw5svDdn8SL+28C3Ws6TrdlJ4Q1E63b +GdB8X2NtHNYGw1LUmknS2APzR/b7+NGq/sq65/wWC+AfwR/aT/ZE8Pj9qyx174h+J/gn+0XB8V/ Dv7WsHxr+NH7LHgD4VXWj/sdfDPS9AuNF/bL0b4waN4T8G6b4H/4RrXdIsvhp8XNV8RaB4p/4SCD QL7w/MAf0y/sneD9f+Hv7LH7NPgDxXYS6X4o8D/s/wDwb8H+JNMnx52na/4Z+HXhzRdYsJtrMvm2 mo2VzbybWYb4zhiOSAfQFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFAEVxcQWsE11dT RW1tbRSXFxcXEiQwQQQo0k0000jLHFFFGrSSSOyoiKzMwAJoA/Or9mT/AIKK+Bvjn4c1bWvHfhO+ +D97qHxY+GPhX4V6LeXepeKL74kfCr9pDQrLxd+yx8YPJtPD2m3Xhiw+Lfh251TTtV0jVbV7XwV4 58GeOPDN1r+q2uhw63fgHZ+M/wDgo9+yX4DtNRvtc8beLrq00GT4hDxXc+GPhD8XPGdv4ItPhn8a vGH7O3iDV/Hlz4T8E6zbeCtEv/jN4B8Y+CPCOseJ5dLsPGl14b13VfC8+qeH9D1nVrAA6Dxj+3x+ y74D8NW/izxN4+1Cz0a9g+N8unyQeCvGuoXeoz/s9fHXwZ+zV8TNOsrCw0C4vJ9TsfjX8QvB3gjQ 7IQiXxRca1Dqugfb9Dt7zU7cAk+HP7Zfgz4pfHfQPgj4Z8CfFOxbX/gfr3xpHirxn8OvHngK30tf DvxV1L4S6j4O1nRvGHhbRr3TNbTXNF1a9t7i9ngttW0ldJ1jw8utaDr+la1OAU/BH7TnxE1T9qNv 2cPiF8GtA8ENrngD4v8AxR8HanoPxbt/iH4xsPAXww+KXhT4a+GfEnxh8GaR4I0/w98L7P45Q+J5 /F3wggsviN43vtW0zwr4y0XXLXRPFHhPxLpGjAE/7Zf7SvxE/Zb+HusfFXw58IPDPxC8A+CPAvjb x58Q9e8VfF6D4ZtbzeGpvDdp4S+Fvw80Sx8DfETxJ8RPjN8YdS1280X4Y+Fo9G0Dw5qviHSYfDmo +MtN1/xL4W0zVwDzPwz+3T4k134qado8/wADynwZ8bfFD9of4EfCrxro/j9tW+LPi34z/sy+H/G2 teP/AAzrPwevPBOi+HfDeka1efCP40eH/B+sW/xg1+/udT8B6VJreh6Lb+NFPhoAr+G/21fi74x/ Zeg/aI039nnwd4DutF+Kf7VHg34vaL8dP2iPDXw78D/Anwf+y38Xvjd8Kte8VfEP4meE/B/xSivd V1m9+Elis2leBPC/jDwxoWoeI9Rln8c33hvw3D4h8QgH2p8G/iE/xc+EPwq+K8vhTxF4Dk+J3w38 DfEKTwP4wtGsPFvg1/GnhjS/Ej+FPFFiyo1n4i8OtqR0jW7RkRrfU7O6hKqUwAD0igCpNYWNzdWd 7cWVpPeaeZzYXc1tDLdWJuo/JuTZ3Do0tsbiECKcwuhmjGyTcvFAFugAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoA8x+NXws0r45fCH4mfBnX9f8AFfhfw/8AFXwP4m+HviHXvA2pWWje MNP8P+LtJutC1xvDmsahpmswaRqs+lX15a2uqpp815prz/bdOktdQgtbuAA+K/E3/BLD9lc+KtO8 a/BDRbn9kbxBpum+CYR/wy74S+Dfw88P6t4i+GHxJ0D4l/DDxz4n8Iap8K/FHhbxR4t8AXdh4v8A CegXWuaTeaa/gj4sfEfSdW0zUtQuvCmseEgD5s+M/wDwS48fz+HIvhj8BPibrVr4S+Jek694Z/aG +J3j/wCKGkaL8SfG+h+L/wBqL4l/tN64nijwt4d/Zp8S+HfiLY6J4o+N3xbufA+j+DfFH7Nmp2Ev iS98O+KPF/ivwv4i1OPTgD6Sf/gmb8N5PEnibXH+Of7Qp0vU9K/aZ0bwf4Je9+Ctx4O+GNl+1v8A HnwJ+0h8aIvDthffBK81Dxna638S/h/pSWuh/GnVfin4Wj8EahrvgDUdA1Twtq13p8gB3n7Nv7An wt/ZZ1zwPrfwz8afESNPBvgn4n+BJ/Dd3bfCvSvBfiLSPih8U5vi/OjeEfBnww8KaJ4EsvBPiq91 O28A+GfhBa/DjwZo+g6lPpmqeG9caGyurUAxPA37Dvi74R6z+0D4y+Gf7Yv7REnjf4/634q8W6vq PxE8L/speL7PQvGWv6lDN4c1mLVbL9mTQPiR4j0P4VaDEvgn4aeAfFfxE1fwl4c8AxReFbCysjBp +saYAd7+0n+x/H+0f4/+DXxEf9ob47/CDUvgZdeItZ8GaD8M7D9nnxD4Mn8Y6/Fp9pb/ABD1vwr8 fPgD8btKu/iB4S0y0vtI8CeKrKLTtR8H6f4l8WJojW1x4i1K4mAJfBP7GPgXwR8YLP4sW/j/AOKO uWWieLfiX8S/CPwp12+8Cn4ZeDfi58ZbS5s/in8VdBh0XwDovjiTxT4yj1nxpNc6brXjnWPBOj3f xG8dXXhzwlo8mrWP9lAHnfxK/wCCePgv4geAfBXw40v47/H74beG/Bf7Sfxo/ao+y+EP+FCeIrLx f8TPjP8AGX4jfHie18e+G/jD8Bvin4L8VeEfht8RvibrWu/CvQr7wwJPDmq6L4L8T6pf+IPG3g7Q vFNoAfdPhrSr/QvDmgaHqnibW/Gmp6NomlaVqPjHxNB4ctfEfiy+0+xgtLvxL4gtfB3h/wAJ+Ebb W9duIZNU1WDwt4W8NeHIb66nj0TQNH0xbbTrcA26ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKAPyG+O/gb/gqFeP8AtC2nwV+IE1r/AG/4yhvvglrN0/wkgi8J6b/wivxt/sbT 10zUz5mv+E7XxTffA1fFmqarL4I8QaRa6NffZPAPxqTRvGFz8bQDq9c+GX/BQ3X/ABV4kk0/4v8A i/wZpkOs+P8AWdOvdP1r4EXvh/U3uvjVp2q/C3RPDXhvUfhDrWuaP4a0H4CXA8NeMW8V6/qF9r/j 3Rb77LYQ2ouPG/xMAPjf9pfwJ+2EfG3huy+KHhn4mfFmDQtU0BfBviHwX4NvvG+lTfD7R/jT8Om1 GTWNU8B/BH4my/Db4uap8ILT4xWutePfBPh/wJ42fU/F3w31jw1q9/qXgbTpfAYB7Lr/AMBv+Cm2 v+F/EHg3Rfi/a+H/AAv43+DnjvQZJTpPgbSPFs3j3xR8M/iLotz4m8ceL9I1K18QeE/El5r2p/C7 UPC+p+CNP8bX2keKvD/ia91vWNL0MLH4sAPYk+D37XngX4JeJdG+ENx4p0T4oeMvjz8a/i/4m8Ra p4s+EV/4w1rTviJL8bbL4QaFqWv+INA8V+HZD8Mrmx/ZrufiAk2namH+HGkav4S8EX/iq20GLwHq 4Bg3Ef7dXgv44fDPQde8d/Erxrpvj7426nr2pQ+FPB+iXPwy8HfC4ftA/FDUNY0Lxd4ng+D99pmj +HT+zpY/BzTfAGlXnxF8PeO7HxRYeOn1rX/FOs+KNPs9UAP1toAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgDF8SWuq3/AId16x0K7Sw1u80XVLXR7+SSSKOy1W4sZ4dPu5JYop5Y0trt4Znk jgmkRULJFIwCMAfnf4O+Ef8AwUY8K2ul2t78dPhl4oEmq2dj4iutU1jUpNQPhLwz4P8ACHgbTtT0 K41f4NeIILXxz45Twxq3xI8QvcWZ8N+FPiZ441t3074keE9OsNCmAEtfht/wU6sPAMWlRfHX4D3f jTTvDN1Y6bqNxYag2n3XiC3/AOENh0W78R3+ofCvWdS1ewax0rxSmuTWlnpOqXer+IZ9ahl+y/2X 4f8AD4B0Evw6/wCCicejatpmnfG/4VQXth4c8N2/hfWr+K01S81jxLZ6TDp/iK58TwS/BGCHTdK1 C7e81uEWEms38mqRaYiy6ZpEeo6TqAB6B8Yfh1+1L4j1rwzr3wu8Y+GvD+p6Pompgyax8TPF2m6L Za+3jey1iNLvwXofwvvPCXxB0fX/AAPb3vgb7R4w02PUvh//AGmniTRB4m8RaYNT1AA8ovvhp/wU l1PRdRsLz40/BOC9l8K+LPD1jqegya3oOsrqGoWNu/h3xJcX5+FuqaDBqUWsxwjWRa+DnmtfD9lf WHhO/wBC1rxNJ4h0EA7Dx58I/wBs64+J/ibxR8Nfjf4a0jwQ97qieEPCfiDUNTvGgsb3QI5bS/1m K48D63p/9o6d4y8d/EmW20tF1HSj4X+H/wAGNPnnmuZ9WbwsAcf4A+Fv/BSPS7zSE8afH34P3el6 v47vNa8dnS7K71bVNI8J6wfC6aho/wANrjXfhfBa2lxo32TxPe+FbTxHaahptrdalFa6k19pj2dp oABuWvw2/wCCh0Y0Jrn47/CW5vLXwH40j1e/m0his3xHvtN8SP4Nih0ew+GmlaTeeA7XxBa+AH1y e5gtfGcOiDxpZ6HqcFxf201wAfanw8tPHFj4G8J2XxL1TRtb8f2uhafB4v1fw9byWui6lrsUCpf3 mnwS21kyQTzAyZWx0+J3LyQ6dp8Lx2cAB5D+0Z4Z/aP8TaX4cg/Z58YeEvCN/Y6jb6nrj+J9Rn0k anLpvibwhqdjp8l7D4A+IUk3h++0Gx8Y6VremWdjomoXl/qnh66/t1tF0/XfD3iAA+bdY+Gn/BSX VfDniPT3+NPwTttXu/Amv+HvD+raHJrfh3VbPxJqMujRad4gur9vhbr2gw3NvHpkuoXd7F4Kvp7d dQ1nQvDdtoMuq2XinQADufGnhj/goRe+LfEV14I+IfwA0fwX/aemT+ENL1KHXLjWk01reHWtWtPF N4/w41CG6+za3Pe+BrQ6OdPuNT8F2OmeL3vNE8W3N/pFAHDeD/hR/wAFINF0zTNE1r9oX4U6haWX hPxtDPq76c2r+KLnxldW/ji98AzTapq3wt+y3Xh/Tta1DwTpviI3Gm/2rP4X0i8SzebXY5tT14A1 dW+G3/BRYHX5PD3x4+DyXK+D/Cln4au9d0aW7+3eLrbVPC83im48TabZfDe00iy0g6ddfESPRbvw zZWeq31yPBEWuxPa2d0LMA840DwN/wAFHbz4rfF65fxXaeDtD1fR9cXwV4j1jxb4X8UeAX16x8R6 5JoD6L4Bk0TxNrHg7SL3SH8JWcMb2N5qN1otv4yuvEdxaeKbrw4YAD0Px/8ADf8A4KJa/puvaB4V +M3wq0K31LTr3SLTxN9vay1uK1u/CtroEeo2thZfAyaTQvE9vqs2q+LH1uz8SahYP4gh0kaZ4d0P QBc6CoB1/hLwl+35pWo3h8S/E74B6/o6eGvEFjo9mmieJ7a4i8SX0N0ugavql3/YhvL7T/D92dOu IbBb5LvUNKt9R0jWtS1XV9TtvFukAFO78Dft832oaxFbfF74aeHdDF14TfQJ1l0nxN4jayt7y0t/ FtvrE03wA8O6LHdXeitqN7ZXVnpcsV14oTTJYrTw74fS90W5APt/ShqY0vTRrRsm1kWFmNWbTfO/ s5tTFvH9vNh9pVbj7EbrzTa+eqzeRs81Q+4UAX6ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAP kb4zfBv4+eKfiRN8QvhP8cZvBNrbfD7T/C+keA9XS/vPBcXiy3i+Kb3HxBvNNsxtu/EcZ8VeE9F0 2DVY9b8HnSrfWtZ8Q+CvEfi/w78Ldb8GAHEW3wN/a5l0zW28T/tK/wDCVaxqfwF+J/gW2trW2tfA ejaf8WvF+svc+GPH9pL4M8IWWoQWnh3QdL8PaPaSN9p1fRL268UazoxK6nJpdyAO1z4Wft0eIvFv xF16y/aN8G/DjQNZ0DQk+G3gzw74W0PxlZeDfE8er6RNr9zres+Kvh5Z6l4l0p/Dy63pFlEqac13 qn9m6+9rpPmXmloAeVWH7Kv7belS/E1tO/a9ufsXxQ1G8urmw1+XUvE+oeDrS90jVLL7L4P8STaH pkmhJayXMUaw+E9F8GQm9upPE2kDw7c6NY6JeAH2p8DPBPxS8FaR4wT4tfEJ/iN4i8Q+Mo9cstUB SO00/SrfwP4J8Ly2Wnabb6PoVhoFjquv+G9d8Yx+G9Os7m20CTxTNpUmueJ721u/E2rgHt9AHl3x m8I+OfHPw81fw38NvHj/AAz8bXOp+EtQ0PxwuntrA0J9B8Y6B4gvnl0b7VZw65bX2maXe6Xd6He3 MWl6zbXsul6sW0y7u0YA+U9Q+DP7bep6naanqf7TdjDomlfE3WvFzeCfCXh7w7pL+Ifh/Hqeg614 U+HN54tuPBkGs21zpkem33hm81qG4tY9et7671jxFHqFrqjeG9HAOg8bfDz9rPxp8R9C8W/Dn4tT fBf4eX2t6pP468CeKNL8LeJfFsulx+B9P8N6LD4buIf+Fi+EdI8vxJFe+LWNnd2hmuRbpqttfLcX doADyWP9mL9uNvGOiePL39sFr3xB4f8AA/i/wyLKfT0i8Fa/rGs6frC+H9fvvAGj+GdE8J6df6Jc 3ml2aalcab4l1NGsL3XmnvINSg8IaWAc/wCLP2cf28INA0yYftHaj4+urC68QT+I9C8N69H8PtS8 UaX4t8b+FvFN/pGg3Z0PTrTSNU0KTQ9ZGja3qXiaPSoPDvimXwHpXhnQvCvh+403xuAdx8OPgZ+3 LpHhHwa2uftRaiuo2Ys38QeENf0/wPr91caLb+HbCE+Hrnx9N8PvEWrweKb7Xl1afUvGYufFlppR 1C2mstL8SWmjW1hfAEum/AT9vAeL7bxfq37V3hyWez+JOp+To8HhO2k8OP8ABDVh4Vlm8L3GgJ4e 07TZvGsGr+HZNZi8SywyapHZX+qeEtK8RaHpes3N9agHoVl8Nv20U8F/C/S9W+Pfhi/8Y+Grbxf/ AMLL8RaZo/h7RIPiPcan4hs9R8NRQ2lx8Ktet/DA0bwzZX/hS2vtKsk+xXniWPxdqml+MLjwhBoP ikA7b4KfDf8AaS8H+I11T4xftAx/FfRrjwzr9rqGgxeDPCPhqyh8WXfijT7zQda0VtC8L6Tqdnpu meFLa60afSr/AFjVEmvr2S+YzTKlwoB9RUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAU AFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQA UAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQ AUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFAB QAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAZHiC51iy0HW7zw9pkGt6/aaRqVzoej XV+ul22r6xBZzS6ZplxqbxXCadBf3qw2s1+8E62kcrXDRSCMowB+cuu+MP8AgpD8NfAVxZTeDfhl 8T/Enh3wTrSr4z0vTbrxTd+NvH9z4xu7fwNbW3hXQdX+F88WnT+G7rRLfxveXOheE9L8PyRa9r9n qOoW1jb2N+AfTqXfxxi8fftALNpPju58G3PhbR0+Csdte/BSOxh1/SvCl/Lr174d1idf+Eg0m+8T +ItS03S9P0b4peGPF2i6PqHhi48Svr03h7xQ/hDw2AeJ+DfD/wC3E/8AbOoeK/HGrpCmpfB/V9L0 K4034G22ozaVHqPhhfip4Rgn0XRNXsEvF0xvH8lxrWo6ts1a7X4dzeGLjw/CPF+lSAH1P8DE+JS/ Czwqfi/Jqr/EWZdYufEUOtjwW+qacbvxBq11pWi3V78PFh8H6ydC0SbTdGi8R6RYaJ/wk8FhF4hv /DfhjVNTvfD2mAHrNABQAUAFABQAUAfIP7Smk/tRah4s+FNz8CfEmpaL4IstYvZPirZ+H9G+Guu+ ItV0w6RrCadb6dZ/EfXvCFmsX9svo73lzY+LNPu7W2jlmjsdX2yadcgDvhl8O/2m9J+JsmteOvjX qmu/DnT5/iHcxeEdW0TwBc3HiE6t8RPiVb+ArI674Y8NeGL3QbDwz8NP+FZ3s/m2et3mqa42pw3l 2ksN412AeBaHon/BSa2sPCcF/wCJdI1Kz0qK+svHOrardfCfSPiB4rsdd8u61PU/CnhjRvBuv+Ad A8Y+D5/C8ej/AA4uNY8c3PhDUrT4iar4o8e+F7mSHSvAfw1APQ/BWgftxw/FxbnxB4rtpfgi+tT6 xa6X4qvfhpdfEGHS7z4Gf2DYeF9b1HwT8PtM0ZYdM+Lum2/jHU59IttQvYdZ8Rapp9lr/ijwNpen WJAPNLGH/gp1oml+GrTT7jwL4wey8Ma7e6vqvxEs/AukeJfEPjWwm8X3GgaVrem+AvEA8M+EPCeq m58PWN2nhvUPHOs3dnpmlXbeIPCNzrXiC18NAHb/ABIsv+CiF5qXhHXfhrqPwy04XPwr+DV9418G 6xLo8Xhqz+Lvh7xV4l1L4n6No16+la54mj8L+OdE1rQtE1y4l8QarNpujeE7Q+B9Q0rxFd6rrOvA GTqGs/8ABTfU4tXntfCnwI8OXFjdeE5vCljbu2oW+tw3mkPe+JofHUl34ynntItI1S3Gmtb+E7u1 mmuLyOPT9V1XTJJtb0sA96+BXi39pTV/if8AHHwp8cPDPhbT/B3gybwhB8LvFvhfwvreg2njOLVL vxodXvGvtW8Y+JYdVmj0HT/A+p6hZadYabb+GNZ17U/Dzalr81nJLYAH1NQAUAFABQAUAFABQAUA FAHA/FXT/HGq/DL4gad8M9bk8N/EW98HeI4PAuvRw6NcNpfi59Juh4eu/K8RaZrWhMseq/ZfMOra TqVgsZZ7izuI1MbAHfUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUA FABQAUAFABQAUAFABQAUAf/ZUEsDBBQABgAIAAAAIQB0sUijYAYAADIbAAAUAAAAcHB0L3RoZW1l L3RoZW1lMy54bWzsWU9vHDUUvyPxHay5t9k/TchG3VTJ7qaBNm2U3Rb16J31zrjrGY9sb9K9ofaI hIQoiAsSNw4IqNRKXMqnCRRBkfoVeLZndu3MLEnaCBB0I2Vn7J/f//f87L167UHC0CERkvK0HdQv 1wJE0pCPaBq1gzuDnUvrAZIKpyPMeErawYzI4Nrmu+9cxRsqJglBsD6VG7gdxEplGysrMoRhLC/z jKQwN+YiwQpeRbQyEvgI6CZspVGrra0kmKYBSnECZG+PxzQkaKBJBpsF8R6D11RJPRAy0dekSb7C oEaTup6TIhp2mECHmLWDmvkEK5tXV/BGDmCqjNsxnxyXA0aTxmn0DICpMm69pv/m9AwAhyHIX+a9 vd2r9Zo51gHZxzLtJnxaLQ/v0G+WZPZ0s0QNyD5eKeE9mzkg+7hawne3et3ejiePAVn8Wgnf6Da6 61se3oBiRtNJCV2rteCTo+eQMWe7lfBWq9OpFYZfoMD785jRLMY8VV4E2ZgL9FyC73OxAwD9wrCi KVKzjIxxCLHZwYwOBdXy4A2CnRk7FMrSkOaFZChoptrBBxmGOF/Qe/X8u1fPn6JXz58cP3x2/PDH 40ePjh/+YGl5C3dxGrkLX37z6R9ffYR+f/r1y8efV+Oli//l+49//umzaqBygS++ePLrsycvvvzk t28fV8C3BB668AFNiES3yBE64AnoZgzjS06G4nwrBjGm7oqtNJI4xZpLBf2eij30rRlmuAK3TXwL 3hUUKlkF8Pr0vidwPxZTlbvc0+xGnHjAPc7ZNheVVriheTmOH0zTqJq5mLq4A4wPq3h3cOr5tzfN oCDSKpKdmHhi7jOcKhyRlCik5/iEkAoz3KPUs+seDQWXfKzQPYq2Ma00yYAOvWhaLNqlCfhlViUg +Nuzzd5dtM1ZldZdcugjISswqxB+QJhnxut4qnBSRXKAE+Ya/CZWcZWQ/ZkIXVxPKvB0RBhHvRGR smrNbQH6Ok6/AdWj2u17bJb4SKHopIrmTcy5i+zySSfGSVaF7dM0drHvywmEKEb7XFXB97ifIfod /IDTpe6+S4nn7tOrwR0aeSItAkTPTIX2JVRrrwgnNH1bkc9ckbcErUyJ3RN1eBnuZPXtcDGi//7i 28XTdJ9AvJd3oLe1923tDf7ztXdZPp+14i6KLNRf3efYBtm0y8nSbnlMGeurGSM3pWmYJWwYox0Y 1OvM+Y/MT2NZDI95gfdwkcBmDRJcfUhV3I9xBs123fTjkcxJRxJlXMKhzgxX0tZMoWFX9vS3qo8y th5IrPb4yA433UPhnIzZdiJzvCwYNTWBszJrvvdmzOpWqqVm81WrG9FMqfNUm6sMPiyrBoNza0In gqB/ASuvwQlcyw6HFMzISNvdbsKFWzTr4vlCXCRjPCK5j7TeZR/VjZOKWDFnfYidCh+tG9H/0moO t5Ym+wbczuIkl92VJewK772Jl4pTbuEZY5yT6chSNzlZio7aQWu1sRqgEGftYAznW3hMMvC61M0f ZhFc/YRK2LA/NZmN4RfebBWKQfQ5GVevFeMlhb06kAmpuljGNjTMVB4CLNWcrPyNVTDrRSlgI/01 pGiuQzD8Y1KAHX3XkvGYhMp1tjOibWdf81LKp4qIfjw6QkM2FQcY3K9DFfQZUQnXFKYi6BfRDrS1 zZRfnPPCWHHbprlhlsU4L7c6RYtMtnATqnMZzJsjHuhWKbtR7vyqmJS/IFXcMP6fqaL3E7gyaI60 B0K4qBUY6XxtB1yomEMVymIa7ghoHEztgGhBUF30do3guth8C3Kov23OWRqaGoOTnzqgERIU9iMV C0L2oSyZ6DuFWD3fuyzJgpCJKEdcmVmxh+SQsIGugWt6bw9QDKFuqkleBgzuZPz573kGDSPd5Lj5 5tWQ+d5rc+Dv7nxsMoNSfh02DU1h/7mIxlp+52PXm+XF3usqoicWbdaVIiuAmbMVtPK0f00RzrnV 2opV0rixWggHXixrDIPzhiiDix+k/8H+R0XI7G8PekMd8AOorQh+T9DEIGwgqi/ZxgPpAmkHh9A4 2UEbTJqUNW3e3WqrFZv1hbRRCxfM+Z4wtpbsLP4+p7HnzZnPzsvFizR2bmHP1nZsqanBsydTFIbG xUHGOMb8aOX+rsSH98HRXbjrnzIlTTCRB3DNB61n3+QBJL/laJZu/gkAAP//AwBQSwMEFAAGAAgA AAAhANyxcIKIBgAAXRsAABQAAABwcHQvdGhlbWUvdGhlbWUyLnhtbOxZT28cNRS/I/EdrLm32U12 02zUTZX910CbNspui3r0znhn3HjGI9ubdG+oPSIhIQrigsSNAwIqtRKX8mkCRVCkfgWe7ZnZcXZW SdoIEGQPyYz98/v/np891288ihk6JEJSnrS9+tWah0ji84AmYdu7Nxpc2fCQVDgJMOMJaXszIr0b W++/dx1vqojEBMH6RG7ithcplW6urEgfhrG8ylOSwNyEixgreBXhSiDwEdCN2cpqrba+EmOaeCjB MZDtTqXiMeoRScPE28qp9xmwSJTUAz4TQ02bZEvuTibUJwYbHNQ1Qs5klwl0iFnbA0YBPxqRR8pD DEsFE22vZn7eytb1FbyZLWJqydrSuoH5ZeuyBcHBquEpwnHBtD5otK71CvoGwNQirt/vd/v1gp4B YN8HTa0sZZqNwUa9k9MsgezjIu1urVlruPgS/bUFmVudTqfZymSxRA3IPjYW8Bu19cb2qoM3IItv LuAbne1ud93BG5DFry/gB9da6w0Xb0ARo8nBAlo7dDDIqBeQCWc7lfANgG/UMvgcBdFQRJdmMeGJ WhZrMX7IxQAAGsiwoglSs5RMsK/DGDM6FlQzwJsEl2bskC8XhjQvJH1BU9X2PkwxpMSc3puX3795 +Ry9efns+PGL48c/HT95cvz4R0vLWbiDk7C88PW3n/359cfoj+ffvH76RTVelvG//vDJLz9/Xg2E DJpL9OrLZ7+9ePbqq09//+5pBXxb4HEZPqIxkegOOUL7PAbdjGFcyclYnG/FKMK0vGI7CSVOsOZS Qb+vIgd9Z4YZrsB1iGvB+wIqSBXw5vShI/AwElOVudzR7FYUO8BdzlmHi0or3NK8SmYeTZOwmrmY lnH7GB9W8e7ixPFvf5pC6aRVJLsRccTcYzhROCQJUUjP8QNCKuz1gFLHrrvUF1zyiUIPKOpgWmmS ER070TRftENj8MusSkDwt2Ob3fuow1mV1j1y6CIhKzCrEH5EmGPGm3iqcFxFcoRjVjb4bayiKiGH M+GXcX2pwNMhYRz1AyJl1Zq7AvQtOf0WVI9qt++yWewihaIHVTRvY87LyB4/6EY4TquwQ5pEZewH 8gBCFKM9rqrgu9zNEP0OfsDJUnffp8Rx9+nV4B4NHZHmAaJnpkL7Eqq1U4RjmlxW5DNX5G1BK1Ni 50QdXoY7WX27XAT03198e3ia7BGI98Ud6LL2XtZe7z9fe5fl81kr7rzIQv3VfY5tkE27HC/tlieU saGaMXJbmoZZwoYRDGBQrzNHRVKcntIIHrMC7+BCgc0aJLj6iKpoGOEUmu26p4mEMiMdSpRyCYc8 M1xJW+OhYVf2iNjUhwdbDyRWuzyww2t6OD8jFGTMthOag2jOaE0TOCuztWsZUVD7bZjVtVBn5lY3 oplS53ArVAYfLqoGg4U1oRNB0L+AldfhsK5ZwyEFMxJou9tNOHeL8cJFukhGOCCZj7Teiz6qGyfl sWJuBSB2KnykD3ynWK3EraXJvgO3szipzK6xhF3uvXfxUh7Bcy/pvD2RjiwpJydL0FHbazVXmx7y cdr2JnC+hcc4Ba9L3fxhFsItka+EDftTk9lk+dybrVwxNwnqcGVh7b6gsFMHUiFVD8vIhoaZykKA JZqTlX+1CWa9KAVspL+FFGsbEAz/mBRgR9e1ZDIhvio7uzSibWdfs1LKp4qIYRQcoTGbin0M7teh CvoEVMI1hakI+gXu1LS1zZRbnLOkK99kGZwdxyyNcFZudYrmmWzhJo8LGcxbSTzQrVJ2o9z5VTEp f0GqlMP4f6aK3k/gymAt0B7w4U5XYKTzte1xoSIOVSiNqD8Q0DiY2gHRAveyMA1BBTfL5r8gh/q/ zTlLw6Q1nPzUPg2RoLAfqUgQsgdlyUTfKcTq2d5lSbKMkImokrgytWKPySFhI10D1/Xe7qEIQt1U k6wMGNzJ+HPfswwah7rJKeebU0OKvdfmwN/d+dhkBqXcOmwamtz+hYgVu6pdb5bne29ZET0xb7Ma eVYAs9JW0MrS/i1FOOdWayvWgsarzVw48OKixjBYNEQpXPwg/Qf2Pyp8Zr886A11xPehtiL46KCJ QdhAVF+xjQfSBdIOjqFxsoM2mDQpa9qsddJWyzfrC+50C74njK0lO4u/z2nsojlz2Tm5eJHGzizs 2NqOLTU1ePZkisLQJD/IGMeY71vlL1B8/BAc3YO7/ilT0gQTfF8SGFrPockDSH7L0Szd+gsAAP// AwBQSwMEFAAGAAgAAAAhANj9jY+sAAAAtgAAABMAAABwcHQvdGFibGVTdHlsZXMueG1sDMxJDoIw GEDhvYl3aP59LUNRJBTCICt36gEqlCHpQGijEuPdZfnyki/NP0qil1jsZDQD/+ABEro13aQHBo97 g2NA1nHdcWm0YLAKC3m236U8cU95c6sUV+vQpmibcAajc3NCiG1Hobg9mFno7fVmUdxtuQykW/h7 05UkgecdieKTBtSJnsE3qoIgorTAp8vliGlIA1x6NMZxVNbVuan9Kix+QLI/AAAA//8DAFBLAwQU AAYACAAAACEATZO19oABAADrAgAAEQAAAHBwdC9wcmVzUHJvcHMueG1srJHNauMwFIX3hXkHo70i +adObOIU27Kh0EIXMw+gseVEYP1wpbQdhnn3UZ10pqFddNHdFYdz9J17tzfPao4eBThpdIXiFUWR 0IMZpd5X6Mf3Hm9Q5DzXI5+NFhX6JRy62X272trSgnBCe+6D9QGiEKRdySt08N6WhLjhIBR3K2OF DtpkQHEfnrAnI/Cn8IGaSUJpThSXGp398Bm/mSY5CGaGowoApxAQ80LiDtK61zT7mbS3PS6QdqHk MMM9HHdbXjrY/2xniB75XKG+T1NKEXknsKJjXf+B0LZ937YvAvmfakvx7O+cf/kpTNERZIV+d+u8 7YqsxjlNW5zFWYKbomtwzuJ0TWlM62T9BwVPnJWjdAOH8VbxvehG6Rn3/LzKIL+rr+QAxpnJrwaj yGmPxJonAdbIZZUxPd9j6blUDMAB7pKRpXFN86TG62JT4yxNClw3jOGmqTfXeZ7Q65j+YxQTP85+ YWRWfiFeklwAnkCXfYbx7V0fYPcXAAD//wMAUEsDBBQABgAIAAAAIQCDd0EAtgEAAHYEAAARAAAA cHB0L3ZpZXdQcm9wcy54bWyUU81u2zAMvg/oOwi6t3adNkmNOMWAYqceBjTbXZAYR4MsCaKcJn36 0XYS260P6ckUTX4/lLh6PlSG7SGgdrbg93cpZ2ClU9qWBf+z+XW75AyjsEoYZ6HgR0D+vL75sfL5 XsP778AIwGIuCr6L0edJgnIHlcA758HSv60LlYh0DGWigngn4MokWZrOk0poy0/94Zp+t91qCS9O 1hXY2IEEMCKSeNxpj2c0fw2aD4AE03aPJK3JnG1km7+txeZMtdEFUK+wjQw/aFSP2SLjTNTR/VT/ aowFT3kyLN0431Y+PTzOpiqTryxotIKeVL4ZNTj1IUphYL0SOR5Yc20PC84UfdNWAqWPE2niO/X5 3AVdassOBb/N0sbHkaL7edtOdbKnKmuS9IqxcdbGjHppbDRhFz448w4Lnp1azyVdcrk84/UgDfjA VaNp7NnV0Wg7HEKv5ZPt2WzK9TjbEHTDGpqmV06Gz+oubqn4C711EXADh9jLuNRfsC8XQRcwdRHj 9Hc1TUhAFyKEqyTNpt/GOP1dSZ/5y6DVmxeStptJelWLOW04Z5Km3IW0GcSx7/bpPwAAAP//AwBQ SwMEFAAGAAgAAAAhAEQk/ZyJAQAAvgIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHyS3U4bMRCF7yvxDpav2bW9UVpqbRYBJRUqVJXYiqp3 lj0Ei/WPbEPI22Nvkm0QqJf2nPl85ozb0xczoGcIUTu7wKymGIGVTmm7WuDf/bI6wSgmYZUYnIUF 3kDEp93Rp1Z6Ll2AX8F5CElDRJlkI5d+gR9S8pyQKB/AiFhnhc3FexeMSPkYVsQL+ShWQBpKPxMD SSiRBCnAyk9EvEMqOSH9UxhGgJIEBjBgUySsZuSfNkEw8cOGsXKgNDptfJ5pZ/eQreS2OKlfop6E 6/W6Xs9GG9k/I39urm/HUSttS1YScNcqyZNOA3Q/L8/QnQuPOVH0Pbgnj64u+yX6wloyaYpaBhDJ he5CR+nQ7SYmMPEYXVlZj8p9vSQ/iJhu8pLuNajzTfcjx4Cu85LyeVAtea8oTQGedVlz19Bm1EwX +fkxm60HUChPy7fZ7Ct3s4tv/RLnXnpS0VnFaM/mvGG8oX+LvTf9ZfrthdmZ/C+RNVWBNj2lfD7n 9OsBcQ/oRsdvf1z3CgAA//8DAFBLAwQUAAYACAAAACEApcMyZ+0DAADKJAAAKAAAAHBwdC9wcmlu dGVyU2V0dGluZ3MvcHJpbnRlclNldHRpbmdzMS5iaW7kWV9v2jAQZ3sD7QPsMeMdDJQWNqVUrBQN ibZRgUl7qtzEZWlDHCVmHfsg+7w7J3EwSUjZHrokfaiUGvt8d7/763tbqVTewJ/yvlJRz36uLOUH cT2T2qf1drNVV4itU8O0l6f1xXzc6NfPBjX1w+j6fP5Nu1Acy/SYoi0+TyfnSr2B0NBxLILQaD5S tOlkNleABkIXV3Wl/p0x5xNCT09PTcx3NXW64hs9pLnUIS7bTIFYAw40DWbU4ZqA+g47sGqYOhvU quoj2QyAREjMcU2bNTW8JGPqrjB8Xn6hrvmL2gxbN8RTEd8Px8Lj6eeZqT8S1tRdghl1xZmq6jEg v5Sue6B3wV4Vhb/VqpkkTUZWQ9fFmy1RzP8FluCgYGoPjefF4kSAaWvQ66jI/+B0MznyGGZkbOFl xBHsByWSJXEHLRWJT59BJDhUkWBbFWvPI3HtmgRwYGBV4rJI5NTTRcAhRSiucaG29q4G8wLFTMcW mHJ5YIgJFDkC6D93fvAVopwJAJQqHqUIFYGQy2gkGI5ZTvEj0h7BIjRy4hLe+m4e5FkHQ96/Ne17 ehtE/PSwpF1q2kjje8+pQa7wioh9Uub8mzxyaELPDNrJjF5VRW7kKjeCOgU+AzIZUvAtYRkxJYwR qDy2VYU4H691Ao0109L4NgvF8ng1StpwY5TJpVVfi9rl3KRL7Gu8uNreI4Okaxs3rByoOw7sTrU3 NB7WHiMGX7whOiui5f+bgBwoyZ/gP1FaxY06+6egLD7qyvUAnPCXj3snO8uST7y82x2oJgiDJTeE uIRJS/DBa7T7O+CFmO5Z7vXSLeDj7nLOLABUMYH0CN1soaNx0rSzBCtCiN7yv7BxKWP0QRImXfPV Bel0PcFqeaL0YSImbeHVhWnHMcobqvcJJ4XrxUzJQwMTTzdhqzTUJtAi87ftbRUd9lmtVrMDZeW2 68pqJ9nGkTrQ8Ez8Tj9f89w993tdiXbUg2XdkeRVdIhxVrOoyJyK80lGxZt5nFPBqIr8l/hB7S3M CX6/K8GcYET19QqepAOJwWVnDqVWMDkQthE18FkKztuk4BDBJH/lgxh4kOQP88gx7iUj5ZvSJiyh K6W9Ouzrz4QZAcXoySFaS71E48OcGbTm8FLtATrn1KLubGPrMCm6Ny0yGRUapMPF4yiIgqrTP87P SCEBkGMWfcaWKZIMRI4mO0meN+ArFgz2SuYgTlwuDghz1wT5A9Qcxaqx6XqMv9aVCoGEVMVwiCku IRZxoWQoOu1ur9s/Oun2cpsr/JdsbJfMQRJScVTk5+soj8fTh5Th94IX1U2c6n8ry8La7wVbEzm/ Pdud/AEAAP//AwBQSwMEFAAGAAgAAAAhAL/e361MAwAADAgAABAACAFkb2NQcm9wcy9hcHAueG1s IKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFVtb9MwEP6OxH845QMa0ra0XYFt uEFVytgkChXp2EdknEtrSOzIdtqVX8856StEqyCfzneXe3nu8Zm9eyxyWKCxUqtB0D3vBIBK6FSq 2SC4n96cXQZgHVcpz7XCQbBCG7yLnj9jE6NLNE6iBQqh7CCYO1deh6EVcyy4PSezIkumTcEdHc0s 1FkmBY60qApULux1Oq9DfHSoUkzPym3AoIl4vXD/GzTVwtdnv05XJRUcsal2PJ/KAqOrq6sOC3dn 9qBNaqPuRfeChY3MhmWZS8EdYRKNpTDa6szBmAupnLZzmOglmommEwv3fQkUtNRZ/edN3Xj0WZ1Z YRAVJHO9hJP+9cVLFrY4sgk3fGZ4ObdR7/IN+ezOLMlliqSn0tci+6QdaUjRCOxWpimqtZXUB2c2 Hse5LGv/jcgSwXOMCaco47lFCr1VsFvkngMTLo2N2MJdL1A4bcDKX8SCfgDfuUWP7iBYcCO5coSy d2sOtZyX1ploSnSg2GRrzrW477Yvy37Uqx1IeNKxiVV3C1PpcrT/koLgoXr+yuGVTZ+U/BCBJsfn jIbiWgDp9fYRqYtr8GjqfPVthBmvcgcjtHKm9mvdAhNX1uniKY9kGI8hISbAGNHReODu/fQGLvvb 87CaURTonUKv022QXKO+TePpAg+Y561FDGd0Gzl8wYXEZatHQvSuLOgMltr8JEIoges66AZt03gy NKnvLUJMbIGRtKKyftM86XcwyW2UYZpKfyF5Dncp8nandQYYGU4X9uEDxHOaF5rWfDQKYWTpgx6z w4nQytG93Zaza+9OUQKFNFqf1B7rMq6MoRUBd2ej9h4SXRlBW5UWJ/wRuzX/F8y5wxTeP0pbcyIp UUhatPUWas9x5B846bX3evQ/v9taMNr8hxl1RRgtpZvryoE9Xqrf49pSf5/opYDEYdneUoKiMtKt YFjRLap7hxe8KN9CTKOTqtJE2rFWkraYvzk7MsJHAg5a6x6mP2gaB/Q42BF/bIVYFyVXqygmomtI VtZhYU9piuKchRsj+yjVT3tfTvWI5rZZvYdKlhBvMaWXcmPfKdgtbV2T+yDEbjXDdOPzt8G/ZF+b xz3q9s879NUv1kbnH6LNMx79BgAA//8DAFBLAQItABQABgAIAAAAIQDatx5aWwIAAKIZAAATAAAA AAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKPsgiYNAQAA 4gIAAAsAAAAAAAAAAAAAAAAAlAQAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGNcI7TBAAAA NwEAACAAAAAAAAAAAAAAAAAA0gcAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU3LnhtbC5yZWxzUEsB Ai0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAA0QgAAHBwdC9zbGlkZXMvX3Jl bHMvc2xpZGU5LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAGNcI7TBAAAANwEAACAAAAAAAAAAAAAA AAAAzgkAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU2LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1 Pey/AAAANwEAACAAAAAAAAAAAAAAAAAAzQoAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU4LnhtbC5y ZWxzUEsBAi0AFAAGAAgAAAAhAGNcI7TBAAAANwEAACAAAAAAAAAAAAAAAAAAygsAAHBwdC9zbGlk ZXMvX3JlbHMvc2xpZGU0LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACEAAAAA AAAAAAAAAAAAyQwAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxMC54bWwucmVsc1BLAQItABQABgAI AAAAIQBjXCO0wQAAADcBAAAgAAAAAAAAAAAAAAAAAMcNAABwcHQvc2xpZGVzL19yZWxzL3NsaWRl My54bWwucmVsc1BLAQItABQABgAIAAAAIQCgC4drDgEAAEoDAAAgAAAAAAAAAAAAAAAAAMYOAABw cHQvc2xpZGVzL19yZWxzL3NsaWRlMi54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcB AAAgAAAAAAAAAAAAAAAAABIQAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMS54bWwucmVsc1BLAQIt ABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAAAAAAAAAAAA8RAABwcHQvc2xpZGVzL19yZWxz L3NsaWRlNS54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAhAAAAAAAAAAAAAAAA AAwSAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1Dw6 IhoBAADRAgAAIQAAAAAAAAAAAAAAAAAKEwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEyLnhtbC5y ZWxzUEsBAi0AFAAGAAgAAAAhAGyQGG3BAAAANwEAACEAAAAAAAAAAAAAAAAAYxQAAHBwdC9zbGlk ZXMvX3JlbHMvc2xpZGUyMC54bWwucmVsc1BLAQItABQABgAIAAAAIQDy9vMBCgEAAJECAAAhAAAA AAAAAAAAAAAAAGMVAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTkueG1sLnJlbHNQSwECLQAUAAYA CAAAACEAY1wjtMEAAAA3AQAAIQAAAAAAAAAAAAAAAACsFgAAcHB0L3NsaWRlcy9fcmVscy9zbGlk ZTE4LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAGNcI7TBAAAANwEAACEAAAAAAAAAAAAAAAAArBcA AHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxNy54bWwucmVsc1BLAQItABQABgAIAAAAIQBjXCO0wQAA ADcBAAAhAAAAAAAAAAAAAAAAAKwYAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTYueG1sLnJlbHNQ SwECLQAUAAYACAAAACEAY1wjtMEAAAA3AQAAIQAAAAAAAAAAAAAAAACsGQAAcHB0L3NsaWRlcy9f cmVscy9zbGlkZTE1LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAGNcI7TBAAAANwEAACEAAAAAAAAA AAAAAAAArBoAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxNC54bWwucmVsc1BLAQItABQABgAIAAAA IQBjXCO0wQAAADcBAAAhAAAAAAAAAAAAAAAAAKwbAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTMu eG1sLnJlbHNQSwECLQAUAAYACAAAACEAsZY9y8QBAACdDwAAHwAAAAAAAAAAAAAAAACsHAAAcHB0 L19yZWxzL3ByZXNlbnRhdGlvbi54bWwucmVsc1BLAQItABQABgAIAAAAIQBik1CPIwMAABQQAAAU AAAAAAAAAAAAAAAAALUfAABwcHQvcHJlc2VudGF0aW9uLnhtbFBLAQItABQABgAIAAAAIQBGEeYI AQgAAL0rAAAWAAAAAAAAAAAAAAAAAAojAABwcHQvc2xpZGVzL3NsaWRlMTQueG1sUEsBAi0AFAAG AAgAAAAhACeohaYDBgAATBgAABYAAAAAAAAAAAAAAAAAPysAAHBwdC9zbGlkZXMvc2xpZGUxMC54 bWxQSwECLQAUAAYACAAAACEAcjrfbaQIAACXFgAAFQAAAAAAAAAAAAAAAAB2MQAAcHB0L3NsaWRl cy9zbGlkZTkueG1sUEsBAi0AFAAGAAgAAAAhAJkPiQNJAwAAXQkAABUAAAAAAAAAAAAAAAAATToA AHBwdC9zbGlkZXMvc2xpZGU4LnhtbFBLAQItABQABgAIAAAAIQChM1XrlAUAAOMRAAAVAAAAAAAA AAAAAAAAAMk9AABwcHQvc2xpZGVzL3NsaWRlNy54bWxQSwECLQAUAAYACAAAACEAsgz+fKcHAAAL IQAAFQAAAAAAAAAAAAAAAACQQwAAcHB0L3NsaWRlcy9zbGlkZTYueG1sUEsBAi0AFAAGAAgAAAAh AGXo0fO6AwAA5QkAABUAAAAAAAAAAAAAAAAAaksAAHBwdC9zbGlkZXMvc2xpZGU1LnhtbFBLAQIt ABQABgAIAAAAIQDqrYwdAgMAAI0IAAAWAAAAAAAAAAAAAAAAAFdPAABwcHQvc2xpZGVzL3NsaWRl MjAueG1sUEsBAi0AFAAGAAgAAAAhAOGQfrekAwAAPgoAABYAAAAAAAAAAAAAAAAAjVIAAHBwdC9z bGlkZXMvc2xpZGUxMS54bWxQSwECLQAUAAYACAAAACEAheuT510FAABpEQAAFgAAAAAAAAAAAAAA AABlVgAAcHB0L3NsaWRlcy9zbGlkZTEyLnhtbFBLAQItABQABgAIAAAAIQDemPdj/wcAALs4AAAW AAAAAAAAAAAAAAAAAPZbAABwcHQvc2xpZGVzL3NsaWRlMTUueG1sUEsBAi0AFAAGAAgAAAAhALRh WHKBCAAAZE4AABYAAAAAAAAAAAAAAAAAKWQAAHBwdC9zbGlkZXMvc2xpZGUxNi54bWxQSwECLQAU AAYACAAAACEAbw9qc+AFAAAUFgAAFgAAAAAAAAAAAAAAAADebAAAcHB0L3NsaWRlcy9zbGlkZTE3 LnhtbFBLAQItABQABgAIAAAAIQA0jFBHdgQAAIkPAAAWAAAAAAAAAAAAAAAAAPJyAABwcHQvc2xp ZGVzL3NsaWRlMTgueG1sUEsBAi0AFAAGAAgAAAAhAPI/uzVyBAAA0Q0AABYAAAAAAAAAAAAAAAAA nHcAAHBwdC9zbGlkZXMvc2xpZGUxOS54bWxQSwECLQAUAAYACAAAACEA/dgKsUkFAACZEQAAFQAA AAAAAAAAAAAAAABCfAAAcHB0L3NsaWRlcy9zbGlkZTQueG1sUEsBAi0AFAAGAAgAAAAhAAUDxgEv BQAAohUAABUAAAAAAAAAAAAAAAAAvoEAAHBwdC9zbGlkZXMvc2xpZGUzLnhtbFBLAQItABQABgAI AAAAIQCa3fkxMAcAACccAAAVAAAAAAAAAAAAAAAAACCHAABwcHQvc2xpZGVzL3NsaWRlMi54bWxQ SwECLQAUAAYACAAAACEAPHJgN3gEAABXDQAAFgAAAAAAAAAAAAAAAACDjgAAcHB0L3NsaWRlcy9z bGlkZTEzLnhtbFBLAQItABQABgAIAAAAIQBzaCMSIgQAAMgNAAAVAAAAAAAAAAAAAAAAAC+TAABw cHQvc2xpZGVzL3NsaWRlMS54bWxQSwECLQAUAAYACAAAACEA+nFv1JcHAAB5LwAAIQAAAAAAAAAA AAAAAACElwAAcHB0L3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjIueG1sUEsBAi0AFAAGAAgAAAAh AP14jKm+AAAANwEAACwAAAAAAAAAAAAAAAAAWp8AAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xp ZGVMYXlvdXQ4LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAP14jKm+AAAANwEAACwAAAAAAAAAAAAA AAAAYqAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ5LnhtbC5yZWxzUEsBAi0A FAAGAAgAAAAhAP14jKm+AAAANwEAAC0AAAAAAAAAAAAAAAAAaqEAAHBwdC9zbGlkZUxheW91dHMv X3JlbHMvc2xpZGVMYXlvdXQxMS54bWwucmVsc1BLAQItABQABgAIAAAAIQD9eIypvgAAADcBAAAt AAAAAAAAAAAAAAAAAHOiAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTIueG1s LnJlbHNQSwECLQAUAAYACAAAACEA/XiMqb4AAAA3AQAALQAAAAAAAAAAAAAAAAB8owAAcHB0L3Ns aWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAP14 jKm+AAAANwEAAC0AAAAAAAAAAAAAAAAAhaQAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVM YXlvdXQxMC54bWwucmVsc1BLAQItABQABgAIAAAAIQD9eIypvgAAADcBAAAsAAAAAAAAAAAAAAAA AI6lAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ny54bWwucmVsc1BLAQItABQA BgAIAAAAIQD9eIypvgAAADcBAAAsAAAAAAAAAAAAAAAAAJamAABwcHQvc2xpZGVMYXlvdXRzL19y ZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAA AAAAAAAAAAAAAJ6nAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MS54bWwucmVs c1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAKaoAABwcHQvc2xpZGVM YXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Mi54bWwucmVsc1BLAQItABQABgAIAAAAIQD9eIypvgAA ADcBAAAsAAAAAAAAAAAAAAAAAK6pAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0 My54bWwucmVsc1BLAQItABQABgAIAAAAIQD9eIypvgAAADcBAAAsAAAAAAAAAAAAAAAAALaqAABw cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NC54bWwucmVsc1BLAQItABQABgAIAAAA IQD9eIypvgAAADcBAAAsAAAAAAAAAAAAAAAAAL6rAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3Ns aWRlTGF5b3V0Ni54bWwucmVsc1BLAQItABQABgAIAAAAIQALZD++IQgAAJI3AAAhAAAAAAAAAAAA AAAAAMasAABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWxQSwECLQAUAAYACAAAACEA 3vg3I94AAABYAgAALAAAAAAAAAAAAAAAAAAmtQAAcHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlk ZU1hc3RlcjEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA6vhVNyEBAADJBwAALAAAAAAAAAAAAAAA AABOtgAAcHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlkZU1hc3RlcjIueG1sLnJlbHNQSwECLQAU AAYACAAAACEA6iTHTGUFAAC9GwAAIQAAAAAAAAAAAAAAAAC5twAAcHB0L3NsaWRlTGF5b3V0cy9z bGlkZUxheW91dDcueG1sUEsBAi0AFAAGAAgAAAAhAFDev6MDBAAA7hEAACEAAAAAAAAAAAAAAAAA Xb0AAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ2LnhtbFBLAQItABQABgAIAAAAIQAALxs6 ewQAAN8QAAAhAAAAAAAAAAAAAAAAAJ/BAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NS54 bWxQSwECLQAUAAYACAAAACEApUiKU0EDAAAcCwAAIQAAAAAAAAAAAAAAAABZxgAAcHB0L3NsaWRl TGF5b3V0cy9zbGlkZUxheW91dDQueG1sUEsBAi0AFAAGAAgAAAAhAOwo3pcsBAAAixAAACEAAAAA AAAAAAAAAAAA2ckAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQzLnhtbFBLAQItABQABgAI AAAAIQDQsVSfBgQAAFcOAAAhAAAAAAAAAAAAAAAAAETOAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRl TGF5b3V0Mi54bWxQSwECLQAUAAYACAAAACEA9mevJXYDAABFDAAAIQAAAAAAAAAAAAAAAACJ0gAA cHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsBAi0AFAAGAAgAAAAhAGmuNBqYAgAA 7QYAACEAAAAAAAAAAAAAAAAAPtYAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ5LnhtbFBL AQItABQABgAIAAAAIQCb3mVWzgIAAD8IAAAhAAAAAAAAAAAAAAAAABXZAABwcHQvc2xpZGVMYXlv dXRzL3NsaWRlTGF5b3V0OC54bWxQSwECLQAUAAYACAAAACEAQDIcpaEEAADBEQAAIgAAAAAAAAAA AAAAAAAi3AAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDExLnhtbFBLAQItABQABgAIAAAA IQBcdsCHoQMAADMMAAAiAAAAAAAAAAAAAAAAAAPhAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5 b3V0MTMueG1sUEsBAi0AFAAGAAgAAAAhABrOm6nmBAAASBIAACIAAAAAAAAAAAAAAAAA5OQAAHBw dC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMC54bWxQSwECLQAUAAYACAAAACEA1nqNL1sDAABT CwAAIgAAAAAAAAAAAAAAAAAK6gAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEyLnhtbFBL AQItABQABgAIAAAAIQCTqn2YuwAAACQBAAAsAAAAAAAAAAAAAAAAAKXtAABwcHQvbm90ZXNNYXN0 ZXJzL19yZWxzL25vdGVzTWFzdGVyMS54bWwucmVsc1BLAQItABQABgAIAAAAIQCi8bD+zggAAK43 AAAUAAAAAAAAAAAAAAAAAKruAABwcHQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAx BPMJ9gYAAC8kAAAhAAAAAAAAAAAAAAAAAKr3AABwcHQvbm90ZXNNYXN0ZXJzL25vdGVzTWFzdGVy MS54bWxQSwECLQAKAAAAAAAAACEAIerC8NdBAADXQQAAFwAAAAAAAAAAAAAAAADf/gAAZG9jUHJv cHMvdGh1bWJuYWlsLmpwZWdQSwECLQAUAAYACAAAACEAdLFIo2AGAAAyGwAAFAAAAAAAAAAAAAAA AADrQAEAcHB0L3RoZW1lL3RoZW1lMy54bWxQSwECLQAUAAYACAAAACEA3LFwgogGAABdGwAAFAAA AAAAAAAAAAAAAAB9RwEAcHB0L3RoZW1lL3RoZW1lMi54bWxQSwECLQAUAAYACAAAACEA2P2Nj6wA AAC2AAAAEwAAAAAAAAAAAAAAAAA3TgEAcHB0L3RhYmxlU3R5bGVzLnhtbFBLAQItABQABgAIAAAA IQBNk7X2gAEAAOsCAAARAAAAAAAAAAAAAAAAABRPAQBwcHQvcHJlc1Byb3BzLnhtbFBLAQItABQA BgAIAAAAIQCDd0EAtgEAAHYEAAARAAAAAAAAAAAAAAAAAMNQAQBwcHQvdmlld1Byb3BzLnhtbFBL AQItABQABgAIAAAAIQBEJP2ciQEAAL4CAAARAAAAAAAAAAAAAAAAAKhSAQBkb2NQcm9wcy9jb3Jl LnhtbFBLAQItABQABgAIAAAAIQClwzJn7QMAAMokAAAoAAAAAAAAAAAAAAAAAGhVAQBwcHQvcHJp bnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmluUEsBAi0AFAAGAAgAAAAhAL/e361MAwAA DAgAABAAAAAAAAAAAAAAAAAAm1kBAGRvY1Byb3BzL2FwcC54bWxQSwUGAAAAAFYAVgCoGQAAHV4B AAAA --_004_CC3F1CBE38B4Fkentlandfieldmcafeecom_-- From shanna@juniper.net Wed Aug 1 17:59: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 4546211E8181 for ; Wed, 1 Aug 2012 17:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.441 X-Spam-Level: X-Spam-Status: No, score=-106.441 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lf9ov43Hisc5 for ; Wed, 1 Aug 2012 17:59:35 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0387E11E810B for ; Wed, 1 Aug 2012 17:59:34 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUBnQ9uva4VXpTlY4DJ8TwZKwKHqpm0kg@postini.com; Wed, 01 Aug 2012 17:59:35 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 1 Aug 2012 17:57:18 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 1 Aug 2012 17:57:17 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 1 Aug 2012 20:57:16 -0400 From: Stephen Hanna To: "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Date: Wed, 1 Aug 2012 20:57:14 -0400 Thread-Topic: Proposed SACM Charter Thread-Index: Ac1vaWiOyVMyhOX0SPq1pV9F173E/AA2J3hg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AC6674AB7BC78549BB231821ABF7A9AEB833C91EC1EMBX01WFjnprn_" MIME-Version: 1.0 Subject: Re: [sacm] Proposed SACM Charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:59:41 -0000 --_000_AC6674AB7BC78549BB231821ABF7A9AEB833C91EC1EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kent, Thanks for drafting the charter and sending it out for comments. We've got = a good start here but I have a few ideas for refinement: 1. Add "remediation and response" to the first e.g. list. In the SACM= Use Cases document, use cases UC1-UC4 all include response and for good re= ason. Automated attacks proceed quite rapidly. Automated defense must be ab= le to do so also, with appropriate safeguards to ensure that remediation an= d response don't cause more problems than they solve. 2. For "i.e. specifications", I would say "i.e. data formats". We'll = be creating specifications for many things, including data formats and netw= ork protocols. I believe in this instance, you're talking about data format= s. Right? 3. I don't really understand the parenthetical comment "i.e. operatio= ns". I think the preceding phrase ("curating domain concept instance collec= tions in content repositories") means "storing security automation content = into databases". I don't mind using fancy words for that but I don't see wh= at "i.e. operations" has to do with that. Maybe you mean that the security = operations teams will be using that content. But I think that applies to ev= erything we're doing here. 4. When you say "maintain an authoritative point of reference", that = starts to sound like IETF or IANA would be maintaining an authoritative lis= t of vulnerabilities and proper configurations. Of course, that isn't what = you mean. I think we want to enable organizations to maintain their own con= tent repositories. I suggest that you rewrite that sentence to fix this con= fusion and also change from passive voice ("It is one thing ...") to active= voice. Replace that sentence with "Defining a standards representation for= security content is not enough. To enable interoperable security automatio= n, we must define standard protocols for storing, retrieving, and exchangin= g that content." 5. In the numbered list of areas of focus for the WG, why do you say = "device states" in item 1 and "systems' state" in item 2? Those seem to be = two phrases for the same thing. Also, doesn't 2 include 1? And "response" (= including remediation and mitigation) seems to be missing from this list. D= o we just want to monitor our system vulnerabilities and watch them get hac= ked? No, I think we want to be able to use standards to fix vulnerabilities= , install countermeasures and mitigations, and intervene when attacks are d= etected. 6. UC2, UC4, and UC5 from the use cases document do not seem to be ad= dressed in this charter, except perhaps for the last document on "securely = sharing dynamic network state information". Maybe this omission is delibera= te. I have been saying for a while that we have too many work items on our = plate. If we added UC2, UC4, and UC5 to this charter, we'd probably have 3-= 4 times as many work items. So I'm actually OK with deciding that UC2, UC4,= and UC5 aren't in scope for this WG. But we should make that decision expl= icitly. 7. One of the deliverables is "A Standards Track document specifying = interfaces and communication protocols used for security automation and con= tinuous monitoring". That sounds like several documents. Why have one docum= ent that specifies multiple protocols and interfaces? And which protocols a= re these, exactly? I could imagine 20 different ones that could all fit in = this broad category. As I said above, this is a good first draft. Thanks for preparing it and fo= r welcoming comments on it. We've started down the path of finding the prop= er scope for this WG. That's essential. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ken= t_Landfield@McAfee.com Sent: Tuesday, July 31, 2012 6:12 PM To: sacm@ietf.org Subject: [sacm] Proposed SACM Charter Hi all, Here is an initial cut at the proposed SACM Working Group charter. The int= ent of this is to be a starting point for the conversation. Comments are ex= pected, encouraged and welcomed. -------- Security Automation Continuous Monitoring (SACM) Proposed Working Group Charter Chairs: TBD TBD Security Area Directors: Stephen Farrell > Sean Turner > Security Area Advisor: Sean Turner > Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm Description of Working Group Securing information and the systems that store, process, and transmit that= information has become a challenging task for organizations of all sizes, = and we find that security practitioners spend most of their time on manual = processes relegating them to ineffectiveness. Security automation is the ke= y to escaping this rut. This working group will enable security automation = standards in support of information security processes and practices where = practical, such that security practitioners can be better utilized within t= heir organizations and we can meet the more advanced needs of the security = community (e.g. information sharing, continuous monitoring, result aggregat= ion and analysis). The initial focus of this work is toaddress enterprise a= nd SOHO use cases. The working group will achieve this by consuming and con= tinuing (with cooperation) the security automation work already performed b= y various organizations around the world. The initial work has been fruitful, and the specifications previously publi= shed are ready for expansion on the international stage. Of particular inte= rest to this working group are the security automation specifications suppo= rting asset, change, configuration, and vulnerability management. Of second= ary interest to this working group are the emerging security automation spe= cifications relating to event management and continuous monitoring. By undertaking this work, we recognize that there are multiple categories o= f problems in the security automation domain: defining expressions for part= icular domain concepts (i.e. specifications), curating domain concept insta= nce collections in content repositories (i.e. operations), and enabling int= eroperability through the development and use of interfaces and communicati= ons protocols. It is one thing to define an expression for vulnerabilities = and configuration items, but it is quite another to maintain an authoritati= ve point of reference upon which tools (and their users) can rely and suppo= rt the automated exchange of vulnerability and configuration information. This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used for the purpose of assessing, aggregating and com= paring device states against expected values,and reporting on those results= in a predefined or ad hoc manner. 2. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used to continuously monitor and report on systems' st= ate and security process effectiveness in a pre-defined or ad-hoc manner. 3. Create relationships between existing operations management standards to= enable a comprehensive view of security automation, leveraging existing wo= rk and implementations. This working group will produce the following: * An Informational document providing an overview of security automation an= d continuous monitoring to include a reference model * A Standards Track document specifying benchmark configuration representat= ion * An Informational document stating guidelines / requirements for specifyin= g checking languages * Standards Track documents specifying device state checking languages * A Standards Track document specifying an interrogative checking language * A Standards Track document specifying platform naming, matching and appli= cability * A Standards Track document specifying asset identification and reporting = information * A Standards Track document specifying interfaces and communication protoc= ols used for security automation and continuous monitoring * A Standards Track document describing the messages and network protocols = for distributing Security Automation Content * A Standards Track document describing integrating security automation and= Network Endpoint Assessment capabilities * A Standards Track document describing protocols and data formats for secu= rely sharing dynamic network state information among security systems Goals and Milestones Needs to be developed. ------- Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com --_000_AC6674AB7BC78549BB231821ABF7A9AEB833C91EC1EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Kent,

 =

Tha= nks for drafting the charter and sending it out for comments. We’ve g= ot a good start here but I have a few ideas for refinement:

<= o:p> 

1.       <= /span>Add &= #8220;remediation and response” to the first e.g. list. In the SACM U= se Cases document, use cases UC1-UC4 all include response and for good reas= on. Automated attacks proceed quite rapidly. Automated defense must be able= to do so also, with appropriate safeguards to ensure that remediation and = response don’t cause more problems than they solve.=

 

2.       For = 220;i.e. specifications”, I would say “i.e. data formats”= . We’ll be creating specifications for many things, including data fo= rmats and network protocols. I believe in this instance, you’re talki= ng about data formats. Right?

 =

3.       = I don’t really underst= and the parenthetical comment “i.e. operations”. I think the pr= eceding phrase (“curating domain concept instance collections in cont= ent repositories”) means “storing security automation content i= nto databases”. I don’t mind using fancy words for that but I d= on’t see what “i.e. operations” has to do with that. Mayb= e you mean that the security operations teams will be using that content. B= ut I think that applies to everything we’re doing here.

 

4.       W= hen you say “maintain an authoritative point of reference”, tha= t starts to sound like IETF or IANA would be maintaining an authoritative l= ist of vulnerabilities and proper configurations. Of course, that isn’= ;t what you mean. I think we want to enable organizations to maintain their= own content repositories. I suggest that you rewrite that sentence to fix = this confusion and also change from passive voice (“It is one thing &= #8230;”) to active voice. Replace that sentence with “Defining = a standards representation for security content is not enough. To enable in= teroperable security automation, we must define standard protocols for stor= ing, retrieving, and exchanging that content.”

<= p class=3DMsoNormal>&nb= sp;

5.       <= /span>In the numbe= red list of areas of focus for the WG, why do you say “device states&= #8221; in item 1 and “systems’ state” in item 2? Those se= em to be two phrases for the same thing. Also, doesn’t 2 include 1? A= nd “response” (including remediation and mitigation) seems to b= e missing from this list. Do we just want to monitor our system vulnerabili= ties and watch them get hacked? No, I think we want to be able to use stand= ards to fix vulnerabilities, install countermeasures and mitigations, and i= ntervene when attacks are detected.

 <= /span>

6.       UC2, UC4, and UC5 from= the use cases document do not seem to be addressed in this charter, except= perhaps for the last document on “securely sharing dynamic network s= tate information”. Maybe this omission is deliberate. I have been say= ing for a while that we have too many work items on our plate. If we added = UC2, UC4, and UC5 to this charter, we’d probably have 3-4 times as ma= ny work items. So I’m actually OK with deciding that UC2, UC4, and UC= 5 aren’t in scope for this WG. But we should make that decision expli= citly.

 

7.    = ;   One of the deliverables is “A Standards Track docume= nt specifying interfaces and communication protocols used for security auto= mation and continuous monitoring”. That sounds like several documents= . Why have one document that specifies multiple protocols and interfaces? A= nd which protocols are these, exactly? I could imagine 20 different ones th= at could all fit in this broad category.

 

As I said above, this is a good first draft. Thanks for preparing i= t and for welcoming comments on it. We’ve started down the path of fi= nding the proper scope for this WG. That’s essential.

<= o:p> 

Thanks,

 

Steve

 

Fr= om: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of= Kent_Landfield@McAfee.com
Sent: Tuesday, July 31, 2012 6:12 = PM
To: sacm@ietf.org
Subject: [sacm] Proposed SACM Char= ter

 =

Hi all,

 

Here is an initi= al cut at the proposed SACM Working Group charter.  The intent of this= is to be a starting point for the conversation. Comments are expected, enc= ouraged and welcomed.

= &nbs= p;

--------

Security Automation Continuous Monitoring (SACM)=

 

Proposed Worki= ng Group Charter

 <= /p>

TBD

TBD

 

Security Area Directors:

     Stephen Farrell <stephen.farrell@cs.tcd.ie>

     Sean = Turner <t= urners@ieca.com>

 =

Security Area Advisor:

     Sean Turner <turners@ieca.com>=

 

Mailin= g Lists:

     General = Discussion: sacm@ietf.org

  &nb= sp;  To Subscribe: http://www.ietf.org/mailman/listinfo/sacm

=

     Archive:     =     ht= tp://www.ietf.org/mail-archive/web/sacm

 

Description of Working Group=  

Securing information and the systems that store, process, and transmi= t that information has become a challenging task for organizations of = all sizes, and we find that security practitioners spend most of their= time on manual processes relegating them to ineffectiveness. Security= automation is the key to escaping this rut. This working group will e= nable security automation standards in support of information security= processes and practices where practical, such that security practitio= ners can be better utilized within their organizations and we can meet= the more advanced needs of the security community (e.g. information s= haring, continuous monitoring, result aggregation and analysis). The i= nitial focus of this work is toaddress enterprise and SOHO use cases. The w= orking group will achieve this by consuming and continuing (with coope= ration) the security automation work already performed by various orga= nizations around the world.

 

The initial work has been fruitful, and the speci= fications previously published are ready for expansion on the international= stage. Of particular interest to this working group are the security = automation specifications supporting asset, change, configuration, and=  vulnerability management. Of secondary interest to this working group= are the emerging security automation specifications relating to event=  management and continuous monitoring.

 

By undertaking this work, we re= cognize that there are multiple categories of problems in the security= automation domain: defining expressions for particular domain concept= s (i.e. specifications), curating domain concept instance collections = in content repositories (i.e. operations), and enabling interoperabili= ty through the development and use of interfaces and communications protoco= ls. It is one thing to define an expression for vulnerabilities and co= nfiguration items, but it is quite another to maintain an authoritativ= e point of reference upon which tools (and their users) can rely and s= upport the automated exchange of vulnerability and configuration informatio= n.

 

This working group will provide solutions to these categories of p= roblems and the main areas of focus for this working group are describ= ed as follows:

 

1. Define, either by normative reference, adoption, or cr= eation, a set of standards that can be used for the purpose of assessi= ng, aggregating and comparing device states against expected values,and&nbs= p;reporting on those results in a predefined or ad hoc manner. 

 

2. = Define, either by normative reference, adoption, or creation, a set of= standards that can be used to continuously monitor and report on syst= ems’ state and security process effectiveness in a pre-defined o= r ad-hoc manner. 

 

3. Create relationships between existing operations ma= nagement standards to enable a comprehensive view of security automation, l= everaging existing work and implementations.

 

This working group will produce= the following:

 =

* An Informational document providing an = overview of security automation and continuous monitoring to incl= ude a reference model

* A Standards Track = document specifying benchmark configuration representation <= /o:p>

* An Information= al document stating guidelines / requirements for specifying checking langu= ages

* Standards Track documents spec= ifying device state checking languages

* A= Standards Track document specifying an interrogative checking languag= e 

* A Standards Track document speci= fying platform naming, matching and applicability

* A Standards Track document specifying asset identification and re= porting information

* A Standards Track = document specifying interfaces and communication protocols used for securit= y automation and continuous monitoring 

* A Standards Track document describing the messages and network protoc= ols for distributing Security Automation Content 

* A Standards Track document describing integrating security a= utomation and Network Endpoint Assessment capabilities

* A Standards Track document describing protocols and data for= mats for securely sharing dynamic network state information among security = systems

 

Goals and Milestones

 

Needs to be developed.

 =

-------

 

Kent Landfield

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

= --_000_AC6674AB7BC78549BB231821ABF7A9AEB833C91EC1EMBX01WFjnprn_-- From Kent_Landfield@mcafee.com Wed Aug 1 18:02:18 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D081621F8A4D for ; Wed, 1 Aug 2012 18:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.548 X-Spam-Level: X-Spam-Status: No, score=-7.548 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8s6y2omPLdF for ; Wed, 1 Aug 2012 18:02:17 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 1240F21F8A47 for ; Wed, 1 Aug 2012 18:02:17 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 026a_a994_0e1b670e_1ccd_4de1_8ea7_0fdf59cce932; Wed, 01 Aug 2012 20:02:11 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Wed, 1 Aug 2012 20:02:11 -0500 From: To: , Date: Wed, 1 Aug 2012 20:03:09 -0500 Thread-Topic: [mile] [sacm] Agenda and Remote Participation Info for the SACM BOF Thread-Index: Ac1wSnISgwgXVLhoTm2TWsH+mkwKlA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC3F1F4238B54kentlandfieldmcafeecom_" MIME-Version: 1.0 Cc: sacm@ietf.org Subject: Re: [sacm] [mile] Agenda and Remote Participation Info for the SACM BOF X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:02:18 -0000 --_000_CC3F1F4238B54kentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for the suggestion Luis. Please take a look an the slides I recentl= y sent out and see if that is what you are looking for. We have it under th= e Sources for Internet Drafts slide. Talk to you at the meeting. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Luis Nunez > Date: Wednesday, August 1, 2012 11:24 AM To: David Waltermire > Cc: "mile@ietf.org" >, "sacm@ietf.org" > Subject: Re: [mile] [sacm] Agenda and Remote Participation Info for the SAC= M BOF Kent, Dave, can you add to the agenda the IPR issue with the specifications. I think w= e need to inform the community what the issue is. It came up in the MILE s= ession and it directly impacts this group. If someone could clearly articu= late what the issue is, we can at least have a common understanding among t= he community. Thanks. -ln On Jul 30, 2012, at 9:15 PM, Waltermire, David A. wrote: As a reminder, the Security Automation and Continuous Monitoring (SACM) eff= ort is going to have a Side meeting at the IETF 84 meeting in Vancouver lat= er this week. A description of the meeting, the date/time, web meeting det= ails, and the agenda for the meeting follow. SACM Side Meeting IETF 84 Security Automation and Continuous Monitoring =96 SACM (pronounced as Sack-= em) Side Meeting Chairs: David Waltermire, Kent Landfield Description: A side meeting to continue the discussions around security aut= omation and continuous monitoring working group development efforts. In thi= s meeting we will be reviewing the Use Case document and then focusing on a= draft charter for the potential working group. Here are the meeting specifics: Date: Thursday, August 2, 2012 Time: 18:30 =96 20:00 PDT Room: Plaza C Thanks to Nancy Cam-Winget for organizing the webex. See conference call an= d web meeting details below. Agenda: * Agenda Bashing * Status of work since last IETF meeting * Internet Draft Discussions to: - support the charter/use cases - other potential future drafts * Discuss draft WG Charter Current Drafts: - http://www.ietf.org/id/draft-waltermire-sacm-use-cases-01.txt - draft-wal= termire-sacm-use-cases-01 - Analysis of Security Automation and Continuous = Monitoring (SACM) Use Cases - http://www.ietf.org/id/draft-waltermire-content-repository-00.txt - draft= -waltermire-content-repository-00 - Automated XML Content Data Exchange and= Management ________________________________________ From: Nancy Cam-Winget (ncamwing) [ncamwing@cisco.com] Sent: Monday, July 30, 2012 8:05 PM To: Moriarty, Kathleen Subject: FW: (Forward to attendees) Meeting invitation: SACM BOF From: Nancy Cam-Winget > Reply-To: "ncamwing@cisco.com" > Date: Monday, July 30, 2012 5:04 PM To: "ncamwing@cisco.com" > Subject: (Forward to attendees) Meeting invitation: SACM BOF **** You can forward this email invitation to attendees **** Hello , Nancy Cam-Winget invites you to attend this online meeting. Topic: SACM BOF Date: Thursday, August 2, 2012 Time: 6:30 pm, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 205 870 492 Meeting Password: sacm ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D201187757&UID=3D0&PW= =3DNZWYyNWU2YWY3&RT=3DMiM0 2. Enter your name and email address. 3. Enter the meeting password: sacm 4. Click "Join Now". To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?ED=3D201187757&UID=3D0&PW=3DNZWYyN= WU2YWY3&ORT=3DMiM0 ---------------------------------------------------------------- ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/mc 2. On the left navigation bar, click "Support". You can contact me at: ncamwing@cisco.com 1-408-853 0532 To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://cisco.webex.com/ciscosales/j.php?ED=3D201187757&UID=3D0&ICS=3DMI&LD= =3D1&RD=3D2&ST=3D1&SHA2=3DTkz-bhelFlmrhUuPkK7v2d/0gsYehkMU1WW8szSvQnM=3D&RT= =3DMiM0 The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://cisco.webex.com/ciscosales/systemdiagnosis.php. http://www.webex.com CCP:+14085256800x205870492# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. _______________________________________________ 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 --_000_CC3F1F4238B54kentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

From: = Luis Nunez <lnunez@c3isecurit= y.com>
Date: Wednesday, = August 1, 2012 11:24 AM
To: Dav= id Waltermire <david.walter= mire@nist.gov>
Cc: "= ;mile@ietf.org" <mile@ietf.org>, "sacm@ietf.org" <sacm@ie= tf.org>
Subject: Re: [mi= le] [sacm] Agenda and Remote Participation Info for the SACM BOF
<= div>
Kent, Dave,
can you add to the agenda the IPR issue with = the specifications.  I think we need to inform the community what= the issue is.  It came up in the MILE session and it directly im= pacts this group.  If someone could clearly articulate what the i= ssue is, we can at least have a common understanding among the community.

Thanks.

-ln

=
On Jul 30, 2012, at 9:15 PM, Waltermire, David A. wrote:

As a= reminder, the Security Automation and Continuous Monitoring (SACM) effort = is going to have a Side meeting at the IETF 84 meeting in Vancouver later t= his week.  A description of the meeting, the date/time, web meeti= ng details, and the agenda for the meeting follow.
S= ACM Side Meeting IETF 84
Security Automation and Con= tinuous Monitoring =96 SACM (pronounced as Sack-em)
= Side Meeting Chairs: David Waltermire, Kent Landfield
Description: A side meeting to continue the discussions around security a= utomation and continuous monitoring working group development efforts. In t= his meeting we will be reviewing the Use Case document and then focusing on= a draft charter for the potential working group.
He= re are the meeting specifics:
Date: Thursday, August= 2, 2012
Time: 18:30 =96 20:00 PDT
Room: Plaza C
Thanks to Nancy Cam-Winget for organizing the webex. See= conference call and web meeting details below.
Agen= da:
          =   * Agenda Bashing
      =       * Status of work since last IETF meetin= g
          &nb= sp; * Internet Draft Discussions to:
    = ;            &n= bsp; - support the charter/use cases
    = ;            &n= bsp; - other potential future drafts
    = ;        * Discuss draft WG Charter=
Current Drafts:
- http://www.ietf.org/id/= draft-waltermire-sacm-use-cases-01.txt - draft-waltermire-sacm-use-case= s-01 - Analysis of Security Automation and Continuous Monitoring (SACM) Use= Cases
- http://www.ietf.org/id/draft-waltermire-content-repo= sitory-00.txt - draft-waltermire-content-repository-00 - Automated XML = Content Data Exchange and Management
_______________= _________________________
From: Nancy Cam-Winget (ncamwing) [ncamwing@cisco.com]
Sent:= Monday, July 30, 2012 8:05 PM
To: Moriarty, Kathleen
= Subject: FW: (Forward to attendees) Meeting invitation: SACM BOF
Da= te: Monday, July 30, 2012 5:04 PM
Subject: (Forwa= rd to attendees) Meeting invitation: SACM BOF
**** Y= ou can forward this email invitation to attendees ****
Hello ,
Nancy Cam-Winget invites you to attend th= is online meeting.
Topic: SACM BOF
Date: = Thursday, August 2, 2012
Time: 6:30 pm, Pacific Daylight Time (S= an Francisco, GMT-07:00)
Meeting Number: 205 870 492
= Meeting Password: sacm
-----------------= --------------------------------------
To join the online meetin= g (Now from mobile devices!)
-----------------------------------= --------------------
2. Enter your name an= d email address.
3. Enter the meeting password: sacm
= 4. Click "Join Now".
To view in other time= zones or languages, please click the link:
=
----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------
The affected toll free numbers are: (866) 432-9903 for= the San Jose/Milpitas area and (866) 349-3520 for the RTP area.
=
Please dial the local access number for your area from the lis= t below:
- San Jose/Milpitas (408) area: 525-6800
- R= TP (919) area: 392-3330
----------------------------= ---------------------------
To join the teleconference only
-------------------------------------------------------
1= . Dial into Cisco WebEx (view all Global Access Numbers at
= http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or= Access Code followed by the # sign.
San Jose, CA: &= #43;1.408.525.6800 RTP: +1.919.392.3330
US/Canad= a: +1.866.432.9903 United Kingdom: +44.20.8824.0117
India: +91.80.4350.1111 Germany: +49.619.6773.9002
Japan: +81.3.5763.9394 China: +86.10.8515.5666
=
-------------------------------------------------------
For assistance
---------------------------------------= ----------------
2. On the = left navigation bar, click "Support".
You = can contact me at:
1-408-853 0532
To add thi= s meeting to your calendar program (for example Microsoft Outlook), click t= his link:
The playback of UC= F (Universal Communications Format) rich media files requires appropriate p= layers. To view this type of rich media files in the meeting, please check = whether you have the players installed on your computer by going to https://cisco.w= ebex.com/ciscosales/systemdiagnosis.php.
<= div>
CCP:+14085256800x205870492#
IMPORTANT NOTICE: This WebEx service includes a feature that= allows audio and any documents and other materials exchanged or viewed dur= ing the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, discuss= your concerns with the meeting host prior to the start of the recording or= do not join the session. Please note that any such recordings may be subje= ct to discovery in the event of litigation.
____________________= ___________________________
sacm mailing list

______________________________= _________________
mile mailing list
<= div>
--_000_CC3F1F4238B54kentlandfieldmcafeecom_-- From Kent_Landfield@mcafee.com Wed Aug 1 18:18:26 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 6FB6411E811D for ; Wed, 1 Aug 2012 18:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fGkkIepWO47 for ; Wed, 1 Aug 2012 18:18:24 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 77DC911E80FD for ; Wed, 1 Aug 2012 18:18:24 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 0277_1472_23907c50_c388_4d71_bef2_51e7a3ba1b03; Wed, 01 Aug 2012 20:18:19 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Wed, 1 Aug 2012 20:18:13 -0500 From: To: , Date: Wed, 1 Aug 2012 20:18:12 -0500 Thread-Topic: Proposed SACM Charter Thread-Index: Ac1wTK82YHNqpKKCRFSYCvY5VdfRtQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC3F21EE38B5Ckentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] Proposed SACM Charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:18:26 -0000 --_000_CC3F21EE38B5Ckentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Steve, This is great feedback and just what I was hoping for. Thank you. Let's ta= lk about this tomorrow in the Side Meeting. Thanks again. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Stephen Hanna > Date: Wednesday, August 1, 2012 5:57 PM To: Kent Landfield >, "sacm@ietf.org" > Subject: RE: Proposed SACM Charter Kent, Thanks for drafting the charter and sending it out for comments. We=92ve go= t a good start here but I have a few ideas for refinement: 1. Add =93remediation and response=94 to the first e.g. list. In the = SACM Use Cases document, use cases UC1-UC4 all include response and for goo= d reason. Automated attacks proceed quite rapidly. Automated defense must b= e able to do so also, with appropriate safeguards to ensure that remediatio= n and response don=92t cause more problems than they solve. 2. For =93i.e. specifications=94, I would say =93i.e. data formats=94= . We=92ll be creating specifications for many things, including data format= s and network protocols. I believe in this instance, you=92re talking about= data formats. Right? 3. I don=92t really understand the parenthetical comment =93i.e. oper= ations=94. I think the preceding phrase (=93curating domain concept instanc= e collections in content repositories=94) means =93storing security automat= ion content into databases=94. I don=92t mind using fancy words for that bu= t I don=92t see what =93i.e. operations=94 has to do with that. Maybe you m= ean that the security operations teams will be using that content. But I th= ink that applies to everything we=92re doing here. 4. When you say =93maintain an authoritative point of reference=94, t= hat starts to sound like IETF or IANA would be maintaining an authoritative= list of vulnerabilities and proper configurations. Of course, that isn=92t= what you mean. I think we want to enable organizations to maintain their o= wn content repositories. I suggest that you rewrite that sentence to fix th= is confusion and also change from passive voice (=93It is one thing =85=94)= to active voice. Replace that sentence with =93Defining a standards repres= entation for security content is not enough. To enable interoperable securi= ty automation, we must define standard protocols for storing, retrieving, a= nd exchanging that content.=94 5. In the numbered list of areas of focus for the WG, why do you say = =93device states=94 in item 1 and =93systems=92 state=94 in item 2? Those s= eem to be two phrases for the same thing. Also, doesn=92t 2 include 1? And = =93response=94 (including remediation and mitigation) seems to be missing f= rom this list. Do we just want to monitor our system vulnerabilities and wa= tch them get hacked? No, I think we want to be able to use standards to fix= vulnerabilities, install countermeasures and mitigations, and intervene wh= en attacks are detected. 6. UC2, UC4, and UC5 from the use cases document do not seem to be ad= dressed in this charter, except perhaps for the last document on =93securel= y sharing dynamic network state information=94. Maybe this omission is deli= berate. I have been saying for a while that we have too many work items on = our plate. If we added UC2, UC4, and UC5 to this charter, we=92d probably h= ave 3-4 times as many work items. So I=92m actually OK with deciding that U= C2, UC4, and UC5 aren=92t in scope for this WG. But we should make that dec= ision explicitly. 7. One of the deliverables is =93A Standards Track document specifyin= g interfaces and communication protocols used for security automation and c= ontinuous monitoring=94. That sounds like several documents. Why have one d= ocument that specifies multiple protocols and interfaces? And which protoco= ls are these, exactly? I could imagine 20 different ones that could all fit= in this broad category. As I said above, this is a good first draft. Thanks for preparing it and fo= r welcoming comments on it. We=92ve started down the path of finding the pr= oper scope for this WG. That=92s essential. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Tuesday, July 31, 2012 6:12 PM To: sacm@ietf.org Subject: [sacm] Proposed SACM Charter Hi all, Here is an initial cut at the proposed SACM Working Group charter. The int= ent of this is to be a starting point for the conversation. Comments are ex= pected, encouraged and welcomed. -------- Security Automation Continuous Monitoring (SACM) Proposed Working Group Charter Chairs: TBD TBD Security Area Directors: Stephen Farrell > Sean Turner > Security Area Advisor: Sean Turner > Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm Description of Working Group Securing information and the systems that store, process, and transmit that= information has become a challenging task for organizations of all sizes, = and we find that security practitioners spend most of their time on manual = processes relegating them to ineffectiveness. Security automation is the ke= y to escaping this rut. This working group will enable security automation = standards in support of information security processes and practices where = practical, such that security practitioners can be better utilized within t= heir organizations and we can meet the more advanced needs of the security = community (e.g. information sharing, continuous monitoring, result aggregat= ion and analysis). The initial focus of this work is toaddress enterprise a= nd SOHO use cases. The working group will achieve this by consuming and con= tinuing (with cooperation) the security automation work already performed b= y various organizations around the world. The initial work has been fruitful, and the specifications previously publi= shed are ready for expansion on the international stage. Of particular inte= rest to this working group are the security automation specifications suppo= rting asset, change, configuration, and vulnerability management. Of second= ary interest to this working group are the emerging security automation spe= cifications relating to event management and continuous monitoring. By undertaking this work, we recognize that there are multiple categories o= f problems in the security automation domain: defining expressions for part= icular domain concepts (i.e. specifications), curating domain concept insta= nce collections in content repositories (i.e. operations), and enabling int= eroperability through the development and use of interfaces and communicati= ons protocols. It is one thing to define an expression for vulnerabilities = and configuration items, but it is quite another to maintain an authoritati= ve point of reference upon which tools (and their users) can rely and suppo= rt the automated exchange of vulnerability and configuration information. This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used for the purpose of assessing, aggregating and com= paring device states against expected values,and reporting on those results= in a predefined or ad hoc manner. 2. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used to continuously monitor and report on systems=92 = state and security process effectiveness in a pre-defined or ad-hoc manner. 3. Create relationships between existing operations management standards to= enable a comprehensive view of security automation, leveraging existing wo= rk and implementations. This working group will produce the following: * An Informational document providing an overview of security automation an= d continuous monitoring to include a reference model * A Standards Track document specifying benchmark configuration representat= ion * An Informational document stating guidelines / requirements for specifyin= g checking languages * Standards Track documents specifying device state checking languages * A Standards Track document specifying an interrogative checking language * A Standards Track document specifying platform naming, matching and appli= cability * A Standards Track document specifying asset identification and reporting = information * A Standards Track document specifying interfaces and communication protoc= ols used for security automation and continuous monitoring * A Standards Track document describing the messages and network protocols = for distributing Security Automation Content * A Standards Track document describing integrating security automation and= Network Endpoint Assessment capabilities * A Standards Track document describing protocols and data formats for secu= rely sharing dynamic network state information among security systems Goals and Milestones Needs to be developed. ------- Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com --_000_CC3F21EE38B5Ckentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Steve,

This is great feedback and just what I was hoping for.= Thank you.  Let's talk about this tomorrow in the Side Meeting. =

Thanks again.

Kent Landfield= <= br>
McAfe= e | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcaf= ee.com

From: Stephen Hanna <shanna@juniper.net>
Date: Wednesday, August 1, 2012 5:57 PM
To: Kent Landfield <Kent_Landfield@McAfee.com>, "sacm@ietf.org" <sac= m@ietf.org>
Subject: RE:= Proposed SACM Charter

Kent,

 =

Thanks for drafting the charter and sending it out for comments. We= =92ve got a good start here but I have a few ideas for refinement:

 

1.=    &n= bsp;   Add =93remediation and response=94 to the first e.g. list. In the SA= CM Use Cases document, use cases UC1-UC4 all include response and for good = reason. Automated attacks proceed quite rapidly. Automated defense must be able to do so also, with appropriate safeguards = to ensure that remediation and response don=92t cause more problems than th= ey solve.

 

2.&n= bsp;      For =93i.e. specifications=94, I would say =93i.e. data formats=94. = We=92ll be creating specifications for many things, including data formats = and network protocols. I believe in this instance, you=92re talking about data formats. Right?

&= nbsp;

3.     &nbs= p; I don=92t really understand the parenthetical comment =93i.e. operat= ions=94. I think the preceding phrase (=93curating domain concept instance = collections in content repositories=94) means =93storing security automatio= n content into databases=94. I don=92t mind using fancy words for that but = I don=92t see what =93i.e. operations=94 has to do with that. Maybe you mea= n that the security operations teams will be using that content. But I thin= k that applies to everything we=92re doing here.

 

= 4.       When you say =93maintain an authoritative point of reference=94, tha= t starts to sound like IETF or IANA would be maintaining an authoritative l= ist of vulnerabilities and proper configurations. Of course, that isn=92t what you mean. I think we want to enable organizat= ions to maintain their own content repositories. I suggest that you rewrite= that sentence to fix this confusion and also change from passive voice (= =93It is one thing =85=94) to active voice. Replace that sentence with =93Defining a standards representation for secu= rity content is not enough. To enable interoperable security automation, we= must define standard protocols for storing, retrieving, and exchanging tha= t content.=94

 

5.       In the numbered list of areas of focus for the WG, why do you say = =93device states=94 in item 1 and =93systems=92 state=94 in item 2? Those s= eem to be two phrases for the same thing. Also, doesn=92t 2 include 1? And =93response=94 (including remediation and mitigation) see= ms to be missing from this list. Do we just want to monitor our system vuln= erabilities and watch them get hacked? No, I think we want to be able to us= e standards to fix vulnerabilities, install countermeasures and mitigations, and intervene when attacks are de= tected.

 

6.       UC2, UC4, and UC5 from the use cases document do not seem to be addr= essed in this charter, except perhaps for the last document on =93securely = sharing dynamic network state information=94. Maybe this omission is deliberate. I have been saying for a while that we = have too many work items on our plate. If we added UC2, UC4, and UC5 to thi= s charter, we=92d probably have 3-4 times as many work items. So I=92m actu= ally OK with deciding that UC2, UC4, and UC5 aren=92t in scope for this WG. But we should make that decision ex= plicitly.

 

7.&n= bsp;      One of the deliverables is =93A Standards Track document specifying = interfaces and communication protocols used for security automation and con= tinuous monitoring=94. That sounds like several documents. Why have one document that specifies multiple protocols and int= erfaces? And which protocols are these, exactly? I could imagine 20 differe= nt ones that could all fit in this broad category.

<= o:p> 

As I said above, this is a good first draft. Thanks f= or preparing it and for welcoming comments on it. We=92ve started down the = path of finding the proper scope for this WG. That=92s essential.

 

Thanks,

 

Steve

 

<= p class=3D"MsoNormal">From: sacm-bou= nces@ietf.org [mailto:sacm-bou= nces@ietf.org] On Behalf Of Kent_Landf= ield@McAfee.com
Sent: Tuesday, July 31, 2012 6:12 PM
To= : sacm@ietf.org
Subject:= [sacm] Proposed SACM Charter

 

Hi all,

 

Here is an initial cut at the proposed SACM W= orking Group charter.  The intent of this is to be a starting point fo= r the conversation. Comments are expected, encouraged and welcomed.

 

--------

Security Automation Continuous Monitoring (SACM)=

 

Proposed Working Group Charter

 

Chairs:

TBD

TBD<= /o:p>

 

Security Area Directors:

<= span style=3D"color: black; font-family: 'Times New Roman', serif; "> =     Stephen Farrell <stephen.farrell@cs.tcd.ie>= ;

     Sean Turn= er <turne= rs@ieca.com>

 

Security Area Advisor:

     Sean Turner <turners@ieca.com>

 

Mailing Lists:

&= nbsp;    General Discussion: sacm@ietf.org

     To Subscribe: http://www.ietf.org/mailman/= listinfo/sacm

  &nbs= p;  Archive:         http://www.ietf.o= rg/mail-archive/web/sacm

&= nbsp;

Description of Working Grou= p

 

=

Securing information and the systems that store, process,= and transmit that information has become a challenging task for = organizations of all sizes, and we find that security practitioners spend most of their time on manual processes relegating= them to ineffectiveness. Security automation is the key to escaping t= his rut. This working group will enable security automation standards = in support of information security processes and practices where practical, such that security practitioners can be be= tter utilized within their organizations and we can meet the more adva= nced needs of the security community (e.g. information sharing, contin= uous monitoring, result aggregation and analysis). The initial focus of this work is toaddress enterprise and SOHO use cases.= The working group will achieve this by consuming and continuing (with= cooperation) the security automation work already performed by variou= s organizations around the world.

&n= bsp;

The initial work has been fruit= ful, and the specifications previously published are ready for expansion on= the international stage. Of particular interest to this working group are the security automation specifications supporting asset, change, = configuration, and vulnerability management. Of secondary interest to = this working group are the emerging security automation specifications= relating to event management and continuous monitoring.

 

By = undertaking this work, we recognize that there are multiple categories = ;of problems in the security automation domain: defining expressions f= or particular domain concepts (i.e. specifications), curating domain concept instance collections i= n content repositories (i.e. operations), and enabling interoperabilit= y through the development and use of interfaces and communications protocol= s. It is one thing to define an expression for vulnerabilities and configuration items, but it is quite another = to maintain an authoritative point of reference upon which tools (and&= nbsp;their users) can rely and support the automated exchange of vulnerabil= ity and configuration information.

 

This working group will provide solutions to these categori= es of problems and the main areas of focus for this working group are = described as follows:

 

1. Define, either by normative referen= ce, adoption, or creation, a set of standards that can be used for the= purpose of assessing, aggregating and comparing device states against expected values,and reporting on those results in a predefined or ad = hoc manner. 

 

2. Define, either by normative reference= , adoption, or creation, a set of standards that can be used to contin= uously monitor and report on systems=92 state and security process effectiveness in a pre-defined or ad-hoc manner. 

 

3. C= reate relationships between existing operations management standards to ena= ble a comprehensive view of security automation, leveraging existing work a= nd implementations.

 

This working group will produce the following= :

 

* An Informational document providing= an overview of security automation and continuous monitoring to = include a reference model

* A Standa= rds Track document specifying benchmark configuration representation&n= bsp;

* St= andards Track documents specifying device state checking languages

* A Standards Track document specifying an i= nterrogative checking language 

* A Standards Track document specifying platform naming, matching and= applicability

* A Standards Track d= ocument specifying asset identification and reporting information

* A Standards Track document specifying inter= faces and communication protocols used for security automation and continuo= us monitoring 

* A Standards Tr= ack document describing the messages and network protocols for distributing= Security Automation Content 

*= A Standards Track document describing integrating security automation and = Network Endpoint Assessment capabilities

* A Standards Track document describing protocols and data formats for= securely sharing dynamic network state information among security systems<= o:p>

 

Goals and Milestones<= /p>

 

Needs to be developed.

<= p class=3D"MsoNormal"> 

-------

 

Kent = Landfield

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

 --_000_CC3F21EE38B5Ckentlandfieldmcafeecom_-- From amontville@tripwire.com Wed Aug 1 18:32:46 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FEA11E8164 for ; Wed, 1 Aug 2012 18:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.049 X-Spam-Level: X-Spam-Status: No, score=-5.049 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PgDX4Rlvwd1 for ; Wed, 1 Aug 2012 18:32:45 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD8F11E8138 for ; Wed, 1 Aug 2012 18:32:45 -0700 (PDT) Received: from mail43-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 2 Aug 2012 01:32:44 +0000 Received: from mail43-tx2 (localhost [127.0.0.1]) by mail43-tx2-R.bigfish.com (Postfix) with ESMTP id 3CAF8440107; Thu, 2 Aug 2012 01:32:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -42 X-BigFish: VPS-42(zz98dI9371I1503M9f17R148cI1418I4015I111aI14ffIzz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h946hd25he5bhf0ah107ah) Received: from mail43-tx2 (localhost.localdomain [127.0.0.1]) by mail43-tx2 (MessageSwitch) id 1343871161801237_31761; Thu, 2 Aug 2012 01:32:41 +0000 (UTC) Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.239]) by mail43-tx2.bigfish.com (Postfix) with ESMTP id B6B9320103; Thu, 2 Aug 2012 01:32:41 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 2 Aug 2012 01:32:41 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 1 Aug 2012 18:33:47 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Wed, 1 Aug 2012 18:32:39 -0700 From: Adam Montville To: "Kent_Landfield@McAfee.com" Thread-Topic: [sacm] Proposed SACM Charter Thread-Index: AQHNcE6z+Xnpw/ospkS3nyu4eFnOcw== Date: Thu, 2 Aug 2012 01:32:39 +0000 Message-ID: <38697CD7-279C-450E-B43C-FE09118F5053@tripwire.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Cc: "shanna@juniper.net" , "sacm@ietf.org" Subject: Re: [sacm] Proposed SACM Charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:32:46 -0000 I completely agree - thanks, Steve, and I'm really looking forward to a goo= d discussion tomorrow evening. Sent from my iPad On Aug 1, 2012, at 6:18 PM, "Kent_Landfield@McAfee.com" = > wrote: Steve, This is great feedback and just what I was hoping for. Thank you. Let's ta= lk about this tomorrow in the Side Meeting. Thanks again. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Stephen Hanna > Date: Wednesday, August 1, 2012 5:57 PM To: Kent Landfield >, "sacm@ietf.org" > Subject: RE: Proposed SACM Charter Kent, Thanks for drafting the charter and sending it out for comments. We=92ve go= t a good start here but I have a few ideas for refinement: 1. Add =93remediation and response=94 to the first e.g. list. In the = SACM Use Cases document, use cases UC1-UC4 all include response and for goo= d reason. Automated attacks proceed quite rapidly. Automated defense must b= e able to do so also, with appropriate safeguards to ensure that remediatio= n and response don=92t cause more problems than they solve. 2. For =93i.e. specifications=94, I would say =93i.e. data formats=94= . We=92ll be creating specifications for many things, including data format= s and network protocols. I believe in this instance, you=92re talking about= data formats. Right? 3. I don=92t really understand the parenthetical comment =93i.e. oper= ations=94. I think the preceding phrase (=93curating domain concept instanc= e collections in content repositories=94) means =93storing security automat= ion content into databases=94. I don=92t mind using fancy words for that bu= t I don=92t see what =93i.e. operations=94 has to do with that. Maybe you m= ean that the security operations teams will be using that content. But I th= ink that applies to everything we=92re doing here. 4. When you say =93maintain an authoritative point of reference=94, t= hat starts to sound like IETF or IANA would be maintaining an authoritative= list of vulnerabilities and proper configurations. Of course, that isn=92t= what you mean. I think we want to enable organizations to maintain their o= wn content repositories. I suggest that you rewrite that sentence to fix th= is confusion and also change from passive voice (=93It is one thing =85=94)= to active voice. Replace that sentence with =93Defining a standards repres= entation for security content is not enough. To enable interoperable securi= ty automation, we must define standard protocols for storing, retrieving, a= nd exchanging that content.=94 5. In the numbered list of areas of focus for the WG, why do you say = =93device states=94 in item 1 and =93systems=92 state=94 in item 2? Those s= eem to be two phrases for the same thing. Also, doesn=92t 2 include 1? And = =93response=94 (including remediation and mitigation) seems to be missing f= rom this list. Do we just want to monitor our system vulnerabilities and wa= tch them get hacked? No, I think we want to be able to use standards to fix= vulnerabilities, install countermeasures and mitigations, and intervene wh= en attacks are detected. 6. UC2, UC4, and UC5 from the use cases document do not seem to be ad= dressed in this charter, except perhaps for the last document on =93securel= y sharing dynamic network state information=94. Maybe this omission is deli= berate. I have been saying for a while that we have too many work items on = our plate. If we added UC2, UC4, and UC5 to this charter, we=92d probably h= ave 3-4 times as many work items. So I=92m actually OK with deciding that U= C2, UC4, and UC5 aren=92t in scope for this WG. But we should make that dec= ision explicitly. 7. One of the deliverables is =93A Standards Track document specifyin= g interfaces and communication protocols used for security automation and c= ontinuous monitoring=94. That sounds like several documents. Why have one d= ocument that specifies multiple protocols and interfaces? And which protoco= ls are these, exactly? I could imagine 20 different ones that could all fit= in this broad category. As I said above, this is a good first draft. Thanks for preparing it and fo= r welcoming comments on it. We=92ve started down the path of finding the pr= oper scope for this WG. That=92s essential. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Tuesday, July 31, 2012 6:12 PM To: sacm@ietf.org Subject: [sacm] Proposed SACM Charter Hi all, Here is an initial cut at the proposed SACM Working Group charter. The int= ent of this is to be a starting point for the conversation. Comments are ex= pected, encouraged and welcomed. -------- Security Automation Continuous Monitoring (SACM) Proposed Working Group Charter Chairs: TBD TBD Security Area Directors: Stephen Farrell > Sean Turner > Security Area Advisor: Sean Turner > Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm Description of Working Group Securing information and the systems that store, process, and transmit that= information has become a challenging task for organizations of all sizes, = and we find that security practitioners spend most of their time on manual = processes relegating them to ineffectiveness. Security automation is the ke= y to escaping this rut. This working group will enable security automation = standards in support of information security processes and practices where = practical, such that security practitioners can be better utilized within t= heir organizations and we can meet the more advanced needs of the security = community (e.g. information sharing, continuous monitoring, result aggregat= ion and analysis). The initial focus of this work is toaddress enterprise a= nd SOHO use cases. The working group will achieve this by consuming and con= tinuing (with cooperation) the security automation work already performed b= y various organizations around the world. The initial work has been fruitful, and the specifications previously publi= shed are ready for expansion on the international stage. Of particular inte= rest to this working group are the security automation specifications suppo= rting asset, change, configuration, and vulnerability management. Of second= ary interest to this working group are the emerging security automation spe= cifications relating to event management and continuous monitoring. By undertaking this work, we recognize that there are multiple categories o= f problems in the security automation domain: defining expressions for part= icular domain concepts (i.e. specifications), curating domain concept insta= nce collections in content repositories (i.e. operations), and enabling int= eroperability through the development and use of interfaces and communicati= ons protocols. It is one thing to define an expression for vulnerabilities = and configuration items, but it is quite another to maintain an authoritati= ve point of reference upon which tools (and their users) can rely and suppo= rt the automated exchange of vulnerability and configuration information. This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used for the purpose of assessing, aggregating and com= paring device states against expected values,and reporting on those results= in a predefined or ad hoc manner. 2. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used to continuously monitor and report on systems=92 = state and security process effectiveness in a pre-defined or ad-hoc manner. 3. Create relationships between existing operations management standards to= enable a comprehensive view of security automation, leveraging existing wo= rk and implementations. This working group will produce the following: * An Informational document providing an overview of security automation an= d continuous monitoring to include a reference model * A Standards Track document specifying benchmark configuration representat= ion * An Informational document stating guidelines / requirements for specifyin= g checking languages * Standards Track documents specifying device state checking languages * A Standards Track document specifying an interrogative checking language * A Standards Track document specifying platform naming, matching and appli= cability * A Standards Track document specifying asset identification and reporting = information * A Standards Track document specifying interfaces and communication protoc= ols used for security automation and continuous monitoring * A Standards Track document describing the messages and network protocols = for distributing Security Automation Content * A Standards Track document describing integrating security automation and= Network Endpoint Assessment capabilities * A Standards Track document describing protocols and data formats for secu= rely sharing dynamic network state information among security systems Goals and Milestones Needs to be developed. ------- Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From shanna@juniper.net Wed Aug 1 18:33: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 08D3B11E815F for ; Wed, 1 Aug 2012 18:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.686 X-Spam-Level: X-Spam-Status: No, score=-106.686 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pWs-4sCWz19 for ; Wed, 1 Aug 2012 18:33:21 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 23A9611E8152 for ; Wed, 1 Aug 2012 18:33:18 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUBnY2hUDQv1RqitgGZ+UIAiJKRFRze8P@postini.com; Wed, 01 Aug 2012 18:33:20 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 1 Aug 2012 18:32:37 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 1 Aug 2012 21:32:36 -0400 From: Stephen Hanna To: "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Date: Wed, 1 Aug 2012 21:32:34 -0400 Thread-Topic: SACM IETF 84 Presentation Thread-Index: Ac1wSXSZxAdEXNIWS5WQE2NEmeZ7KQAA9Mpw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AC6674AB7BC78549BB231821ABF7A9AEB833C91EF2EMBX01WFjnprn_" MIME-Version: 1.0 Cc: "scap-dev@nist.gov" Subject: Re: [sacm] SACM IETF 84 Presentation X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:33:23 -0000 --_000_AC6674AB7BC78549BB231821ABF7A9AEB833C91EF2EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You didn't ask for feedback on the slides but I'm on a roll now... ;-) The Use Cases document references a bunch of existing specs. Some are liste= d in the Internet Discussion slides but some are not. I guess you left out = the RFCs (PA-TNC, PB-TNC, RADIUS, DIAMETER, etc.) because they're already s= et from an IETF perspective. Here are the ones that are not RFCs but are mi= ssing from the slides: PT-TLS (already an I-D in NEA, soon to be an RFC), P= T-EAP (already an I-D in NEA, soon to be an RFC), draft-ietf-mile-sci (alre= ady an I-D in MILE), and IF-MAP (not an I-D yet, currently a TCG Specificat= ion owned by TCG but TCG has donated several specs to IETF before so we mig= ht hope they'd do so again). I'll leave it to you to decide whether to add one or more of those specs to= your slides. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ken= t_Landfield@McAfee.com Sent: Wednesday, August 01, 2012 8:56 PM To: sacm@ietf.org Cc: scap-dev@nist.gov Subject: [sacm] SACM IETF 84 Presentation All, Here are the slides Dave and I will be using tomorrow during the SACM Side= Meeting. We look forward to seeing / hearing you there. Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com --_000_AC6674AB7BC78549BB231821ABF7A9AEB833C91EF2EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You didn&= #8217;t ask for feedback on the slides but I’m on a roll now… ;= -)


The Use Cases docum= ent references a bunch of existing specs. Some are listed in the Internet D= iscussion slides but some are not. I guess you left out the RFCs (PA-TNC, P= B-TNC, RADIUS, DIAMETER, etc.) because they’re already set from an IE= TF perspective. Here are the ones that are not RFCs but are missing from th= e slides: PT-TLS (already an I-D in NEA, soon to be an RFC), PT-EAP (alread= y an I-D in NEA, soon to be an RFC), draft-ietf-mile-sci (already an I-D in= MILE), and IF-MAP (not an I-D yet, currently a TCG Specification owned by = TCG but TCG has donated several specs to IETF before so we might hope they&= #8217;d do so again).

 

I’ll leave it to = you to decide whether to add one or more of those specs to your slides.

 

<= p class=3DMsoNormal>Thanks,

 

Steve=

 

From: sacm-bounces@ietf.org [mailto:s= acm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com
S= ent: Wednesday, August 01, 2012 8:56 PM
To: sacm@ietf.org
= Cc: scap-dev@nist.gov
Subject: [sacm] SACM IETF 84 Present= ation

 

All,<= o:p>

 

Here are the slides  Dave and I will be using tomor= row during the SACM Side Meeting. We look forward to seeing / hearing you t= here.

 

Thanks.

 

=

Kent Landfield

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

= --_000_AC6674AB7BC78549BB231821ABF7A9AEB833C91EF2EMBX01WFjnprn_-- From Kent_Landfield@mcafee.com Wed Aug 1 19:11: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 4A31711E8164 for ; Wed, 1 Aug 2012 19:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.648 X-Spam-Level: X-Spam-Status: No, score=-6.648 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upi1RGZb1vOf for ; Wed, 1 Aug 2012 19:11:15 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 54E7411E80EF for ; Wed, 1 Aug 2012 19:11:15 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 0276_7a07_8728db9b_d453_499a_b49e_9ac3f4be7ceb; Wed, 01 Aug 2012 21:11:10 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Wed, 1 Aug 2012 21:11:10 -0500 From: To: , Date: Wed, 1 Aug 2012 21:12:08 -0500 Thread-Topic: SACM IETF 84 Presentation Thread-Index: Ac1wVBT5G7StUJEKRvmzCwYoOVcKww== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC3F2B4538B69kentlandfieldmcafeecom_" MIME-Version: 1.0 Cc: scap-dev@nist.gov Subject: Re: [sacm] SACM IETF 84 Presentation X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 02:11:16 -0000 --_000_CC3F2B4538B69kentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Steve, You are definitely on a roll. ;-) That's why we asked if there were other = specifications / efforts that should be included IN the slides=85 ;-) The = intent is to indicate what related documentation existed that we may be abl= e to consider for I-D development input. Just because it is listed does not= mean it will be. The slides are for informational purposes only. The inte= nt is to help frame the discussion around the working group charter while i= nforming all as to the status of the documents from an IPR perspective. Ad= ditionally the slides were focused on specifications that are not already I= -Ds or RFCs. I would like to include IF-MAP as well as I feel it is approp= riate to the SACM efforts and goals. I see the Use Case I-D as being a broader document than just what SACM is c= onsidering doing. I see that as a more of an overarching document that pul= ls many of the related efforts in while also describing SACM uses. Thanks for all your great feedback and help today! Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Stephen Hanna > Date: Wednesday, August 1, 2012 6:32 PM To: Kent Landfield >, "sacm@ietf.org" > Cc: "scap-dev@nist.gov" > Subject: RE: SACM IETF 84 Presentation You didn=92t ask for feedback on the slides but I=92m on a roll now=85 ;-) The Use Cases document references a bunch of existing specs. Some are liste= d in the Internet Discussion slides but some are not. I guess you left out = the RFCs (PA-TNC, PB-TNC, RADIUS, DIAMETER, etc.) because they=92re already= set from an IETF perspective. Here are the ones that are not RFCs but are = missing from the slides: PT-TLS (already an I-D in NEA, soon to be an RFC),= PT-EAP (already an I-D in NEA, soon to be an RFC), draft-ietf-mile-sci (al= ready an I-D in MILE), and IF-MAP (not an I-D yet, currently a TCG Specific= ation owned by TCG but TCG has donated several specs to IETF before so we m= ight hope they=92d do so again). I=92ll leave it to you to decide whether to add one or more of those specs = to your slides. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Wednesday, August 01, 2012 8:56 PM To: sacm@ietf.org Cc: scap-dev@nist.gov Subject: [sacm] SACM IETF 84 Presentation All, Here are the slides Dave and I will be using tomorrow during the SACM Side= Meeting. We look forward to seeing / hearing you there. Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com --_000_CC3F2B4538B69kentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Steve, = ;

You are definitely on a roll. ;-)  That's w= hy we asked if there were other specifications / efforts that should be inc= luded IN the slides=85 ;-)  The intent is to indicate what related doc= umentation existed that we may be able to consider for I-D development inpu= t. Just because it is listed does not mean it will be. The slides are for i= nformational purposes only.  The intent is to help frame the discussio= n around the working group charter while informing all as to the status of = the documents from an IPR perspective.  Additionally the slides were f= ocused on specifications that are not already I-Ds or RFCs.  I would l= ike to include IF-MAP as well as I feel it is appropriate to the SACM effor= ts and goals.

I see the Use Case I-D as being a br= oader document than just what SACM is considering doing.  I see that a= s a more of an overarching document that pulls many of the related efforts = in while also describing SACM uses.

Thanks for all= your great feedback and help today!

Kent Landfield
=
McAfee |= An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.c= om

From: Stephen Hanna <shanna@juniper.net>
Da= te: Wednesday, August 1, 2012 6:32 PM
To: Kent Landfield <Kent_Landfield@McAfee.com>, "sacm@ietf.org" <sacm@ie= tf.org>
Cc: "scap-dev@nist.gov" <scap-dev@nist.gov>
Subject: RE: SACM IETF 84 Presentation

You didn=92t ask for feedback on the slides but I=92m on a roll now= =85 ;-)


The Use Cases document references a bunch of existing specs. Some are liste= d in the Internet Discussion slides but some are not. I guess you left out = the RFCs (PA-TNC, PB-TNC, RADIUS, DIAMETER, etc.) because they=92re already= set from an IETF perspective. Here are the ones that are not RFCs but are missing from the slides: PT-TLS (al= ready an I-D in NEA, soon to be an RFC), PT-EAP (already an I-D in NEA, soo= n to be an RFC), draft-ietf-mile-sci (already an I-D in MILE), and IF-MAP (= not an I-D yet, currently a TCG Specification owned by TCG but TCG has donated several specs to IETF befor= e so we might hope they=92d do so again).

 

I=92ll leave it to you to decide whether to add one = or more of those specs to your slides.

 

Thanks,

 

Steve

<= b>From:<= /span>sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landf= ield@McAfee.com
Sent: Wednesday, August 01, 2012 8:56 PM
<= b>To: sacm@ietf.org
Cc: = scap-dev@nist.gov
Subject: [sacm] SACM IETF 84 Presentation

 

All,

 

Here are the slid= es  Dave and I will be using tomorrow during the SACM Side Meeting. We= look forward to seeing / hearing you there.

 

Thanks.=

 

Kent Landfield
=
McAfee | An In= tel Company
Direct: = 3;1.972.963.7096 
Mobile: &= #43;1.817.637.8026
Web: www.mcafee.com

=
--_000_CC3F2B4538B69kentlandfieldmcafeecom_-- From shanna@juniper.net Wed Aug 1 19:22:45 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4292F11E8194 for ; Wed, 1 Aug 2012 19:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.676 X-Spam-Level: X-Spam-Status: No, score=-106.676 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-0w+T5rO6VY for ; Wed, 1 Aug 2012 19:22:42 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 0A15511E8192 for ; Wed, 1 Aug 2012 19:22:40 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUBnkb8A0i3IM+Au27xsIkwpNTlsPlnCu@postini.com; Wed, 01 Aug 2012 19:22:41 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 1 Aug 2012 19:19:48 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 1 Aug 2012 22:19:43 -0400 From: Stephen Hanna To: "Kent_Landfield@mcafee.com" , "sacm@ietf.org" Date: Wed, 1 Aug 2012 22:19:41 -0400 Thread-Topic: SACM IETF 84 Presentation Thread-Index: Ac1wVBT5G7StUJEKRvmzCwYoOVcKwwAAJf5A Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AC6674AB7BC78549BB231821ABF7A9AEB833C91F14EMBX01WFjnprn_" MIME-Version: 1.0 Cc: "scap-dev@nist.gov" Subject: Re: [sacm] SACM IETF 84 Presentation X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 02:22:45 -0000 --_000_AC6674AB7BC78549BB231821ABF7A9AEB833C91F14EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kent, Feel free to add IF-MAP to the slides if you want. I see what you mean about the Use Case I-D. But if we decide to include wor= k item for "an overview of security automation and continuous monitoring", = I think that should span all these use cases. Otherwise, we'll end up with = an architecture that only covers a tiny part of the security automation spa= ce. There's a desperate need for someone to provide a blueprint that shows = how MILE, NEA, SACM, and other future work all fits together. I hope that S= ACM can provide that. We can even point out gaps that other groups can work= on filling in. Thanks, Steve From: Kent_Landfield@mcafee.com [mailto:Kent_Landfield@mcafee.com] Sent: Wednesday, August 01, 2012 10:12 PM To: Stephen Hanna; sacm@ietf.org Cc: scap-dev@nist.gov Subject: Re: SACM IETF 84 Presentation Steve, You are definitely on a roll. ;-) That's why we asked if there were other = specifications / efforts that should be included IN the slides... ;-) The = intent is to indicate what related documentation existed that we may be abl= e to consider for I-D development input. Just because it is listed does not= mean it will be. The slides are for informational purposes only. The inte= nt is to help frame the discussion around the working group charter while i= nforming all as to the status of the documents from an IPR perspective. Ad= ditionally the slides were focused on specifications that are not already I= -Ds or RFCs. I would like to include IF-MAP as well as I feel it is approp= riate to the SACM efforts and goals. I see the Use Case I-D as being a broader document than just what SACM is c= onsidering doing. I see that as a more of an overarching document that pul= ls many of the related efforts in while also describing SACM uses. Thanks for all your great feedback and help today! Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Stephen Hanna > Date: Wednesday, August 1, 2012 6:32 PM To: Kent Landfield >, "sacm@ietf.org" > Cc: "scap-dev@nist.gov" > Subject: RE: SACM IETF 84 Presentation You didn't ask for feedback on the slides but I'm on a roll now... ;-) The Use Cases document references a bunch of existing specs. Some are liste= d in the Internet Discussion slides but some are not. I guess you left out = the RFCs (PA-TNC, PB-TNC, RADIUS, DIAMETER, etc.) because they're already s= et from an IETF perspective. Here are the ones that are not RFCs but are mi= ssing from the slides: PT-TLS (already an I-D in NEA, soon to be an RFC), P= T-EAP (already an I-D in NEA, soon to be an RFC), draft-ietf-mile-sci (alre= ady an I-D in MILE), and IF-MAP (not an I-D yet, currently a TCG Specificat= ion owned by TCG but TCG has donated several specs to IETF before so we mig= ht hope they'd do so again). I'll leave it to you to decide whether to add one or more of those specs to= your slides. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Wednesday, August 01, 2012 8:56 PM To: sacm@ietf.org Cc: scap-dev@nist.gov Subject: [sacm] SACM IETF 84 Presentation All, Here are the slides Dave and I will be using tomorrow during the SACM Side= Meeting. We look forward to seeing / hearing you there. Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com --_000_AC6674AB7BC78549BB231821ABF7A9AEB833C91F14EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Kent,

 

<= p class=3DMsoNormal>Feel free to add IF-MAP to the slides if you wan= t.

 

I see what you mean about the Use Case I-D= . But if we decide to include work item for “an overview of security = automation and continuous monitoring”, I think that should span all t= hese use cases. Otherwise, we’ll end up with an architecture that onl= y covers a tiny part of the security automation space. There’s a desp= erate need for someone to provide a blueprint that shows how MILE, NEA, SAC= M, and other future work all fits together. I hope that SACM can provide th= at. We can even point out gaps that other groups can work on filling in.

 

=

Thanks,

 

Steve

 

<= div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4= .0pt'>

From: Kent_Landfield@mcafee.com [mai= lto:Kent_Landfield@mcafee.com]
Sent: Wednesday, August 01, 2012 = 10:12 PM
To: Stephen Hanna; sacm@ietf.org
Cc: scap-dev@= nist.gov
Subject: Re: SACM IETF 84 Presentation=

 

Steve, 

&nbs= p;

You are definitely on a roll. ;-)  That's why we asked if there we= re other specifications / efforts that should be included IN the slidesR= 30; ;-)  The intent is to indicate what related documentation existed = that we may be able to consider for I-D development input. Just because it = is listed does not mean it will be. The slides are for informational purpos= es only.  The intent is to help frame the discussion around the workin= g group charter while informing all as to the status of the documents from = an IPR perspective.  Additionally the slides were focused on specifica= tions that are not already I-Ds or RFCs.  I would like to include IF-M= AP as well as I feel it is appropriate to the SACM efforts and goals.<= /o:p>

 

I see the Use Case I-D as being a broader document than just = what SACM is considering doing.  I see that as a more of an overarchin= g document that pulls many of the related efforts in while also describing = SACM uses.

 

Thanks for all your great feedback and help t= oday!

 

Kent Landfield

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

=

 

= From: Stephen Hanna <shanna@juniper.net>
Date: Wednesday, August 1, 2012 6:3= 2 PM
To: Kent Landfield <Kent_Landfield@McAfee.com>, "sacm@ietf.org" <sacm@ie= tf.org>
Cc: "sca= p-dev@nist.gov" <scap-dev@= nist.gov>
Subject: RE: SACM IETF 84 Presentation

 

You didn’t ask for feedback on the slides but I’m= on a roll now… ;-)


The Use Cases document references a = bunch of existing specs. Some are listed in the Internet Discussion slides = but some are not. I guess you left out the RFCs (PA-TNC, PB-TNC, RADIUS, DI= AMETER, etc.) because they’re already set from an IETF perspective. H= ere are the ones that are not RFCs but are missing from the slides: PT-TLS = (already an I-D in NEA, soon to be an RFC), PT-EAP (already an I-D in NEA, = soon to be an RFC), draft-ietf-mile-sci (already an I-D in MILE), and IF-MA= P (not an I-D yet, currently a TCG Specification owned by TCG but TCG has d= onated several specs to IETF before so we might hope they’d do so aga= in).

 

I’ll leave it to you to decide whether = to add one or more of those specs to your slides.

 

= Thanks,

 

Steve

 

From: sac= m-bounces@ietf.org [mailto:sac= m-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com
Sent: Wednesday, Augu= st 01, 2012 8:56 PM
To: sacm@iet= f.org
Cc: scap-dev@nist.= gov
Subject: [sacm] SACM IETF 84 Presentation

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

All,

 

Here ar= e the slides  Dave and I will be using tomorrow during the SACM Side M= eeting. We look forward to seeing / hearing you there.

 

T= hanks.

 

Kent Landfield

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

= = --_000_AC6674AB7BC78549BB231821ABF7A9AEB833C91F14EMBX01WFjnprn_-- From david.waltermire@nist.gov Wed Aug 1 19:34:15 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB2411E818E for ; Wed, 1 Aug 2012 19:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.141 X-Spam-Level: X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2r2HWlqrQv26 for ; Wed, 1 Aug 2012 19:34:14 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id A3FEA11E809B for ; Wed, 1 Aug 2012 19:34:13 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 1 Aug 2012 22:33:44 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 1 Aug 2012 22:32:51 -0400 From: "Waltermire, David A." To: "'shanna@juniper.net'" , "'Kent_Landfield@McAfee.com'" , "'sacm@ietf.org'" Date: Wed, 1 Aug 2012 22:32:51 -0400 Thread-Topic: [sacm] SACM IETF 84 Presentation Thread-Index: Ac1wVBT5G7StUJEKRvmzCwYoOVcKwwAAJf5AAACcCe0= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E5EMBCLUSTERxcha_" MIME-Version: 1.0 Cc: SCAP-DEV Subject: Re: [sacm] SACM IETF 84 Presentation X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 02:34:15 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E5EMBCLUSTERxcha_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgZ3JlYXQgZmVlZGJhY2sgU3RldmUhICsxIG9uIHRoZSBvdmVydmlldyBj b21tZW50LiBJIHNlZSB0aGlzIGVmZm9ydCBjb25uZWN0aW5nIE1JTEUsIE5FQSwgU0FDTSwgTkVU Q09ORiwgREFORSBhbmQgbWFueSBvdGhlcnMuIEl0IHdvdWxkIGJlIGV4dHJlbWVseSB1c2VmdWwg dG8gcHV0IHRvZ2V0aGVyIGEgZHJhZnQgdGhhdCBkZXNjcmliZXMgYWxsIG9mIHRoaXMuDQoNClRo YW5rcywNCkRhdmUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IHNh Y20tYm91bmNlc0BpZXRmLm9yZyA8c2FjbS1ib3VuY2VzQGlldGYub3JnPg0KVG86IEtlbnRfTGFu ZGZpZWxkQG1jYWZlZS5jb20gPEtlbnRfTGFuZGZpZWxkQG1jYWZlZS5jb20+OyBzYWNtQGlldGYu b3JnIDxzYWNtQGlldGYub3JnPg0KQ2M6IFNDQVAtREVWDQpTZW50OiBXZWQgQXVnIDAxIDIyOjE5 OjQxIDIwMTINClN1YmplY3Q6IFJlOiBbc2FjbV0gU0FDTSBJRVRGIDg0IFByZXNlbnRhdGlvbg0K DQpLZW50LA0KDQpGZWVsIGZyZWUgdG8gYWRkIElGLU1BUCB0byB0aGUgc2xpZGVzIGlmIHlvdSB3 YW50Lg0KDQpJIHNlZSB3aGF0IHlvdSBtZWFuIGFib3V0IHRoZSBVc2UgQ2FzZSBJLUQuIEJ1dCBp ZiB3ZSBkZWNpZGUgdG8gaW5jbHVkZSB3b3JrIGl0ZW0gZm9yIOKAnGFuIG92ZXJ2aWV3IG9mIHNl Y3VyaXR5IGF1dG9tYXRpb24gYW5kIGNvbnRpbnVvdXMgbW9uaXRvcmluZ+KAnSwgSSB0aGluayB0 aGF0IHNob3VsZCBzcGFuIGFsbCB0aGVzZSB1c2UgY2FzZXMuIE90aGVyd2lzZSwgd2XigJlsbCBl bmQgdXAgd2l0aCBhbiBhcmNoaXRlY3R1cmUgdGhhdCBvbmx5IGNvdmVycyBhIHRpbnkgcGFydCBv ZiB0aGUgc2VjdXJpdHkgYXV0b21hdGlvbiBzcGFjZS4gVGhlcmXigJlzIGEgZGVzcGVyYXRlIG5l ZWQgZm9yIHNvbWVvbmUgdG8gcHJvdmlkZSBhIGJsdWVwcmludCB0aGF0IHNob3dzIGhvdyBNSUxF LCBORUEsIFNBQ00sIGFuZCBvdGhlciBmdXR1cmUgd29yayBhbGwgZml0cyB0b2dldGhlci4gSSBo b3BlIHRoYXQgU0FDTSBjYW4gcHJvdmlkZSB0aGF0LiBXZSBjYW4gZXZlbiBwb2ludCBvdXQgZ2Fw cyB0aGF0IG90aGVyIGdyb3VwcyBjYW4gd29yayBvbiBmaWxsaW5nIGluLg0KDQpUaGFua3MsDQoN ClN0ZXZlDQoNCkZyb206IEtlbnRfTGFuZGZpZWxkQG1jYWZlZS5jb20gW21haWx0bzpLZW50X0xh bmRmaWVsZEBtY2FmZWUuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMDEsIDIwMTIgMTA6 MTIgUE0NClRvOiBTdGVwaGVuIEhhbm5hOyBzYWNtQGlldGYub3JnDQpDYzogc2NhcC1kZXZAbmlz dC5nb3YNClN1YmplY3Q6IFJlOiBTQUNNIElFVEYgODQgUHJlc2VudGF0aW9uDQoNClN0ZXZlLA0K DQpZb3UgYXJlIGRlZmluaXRlbHkgb24gYSByb2xsLiA7LSkgIFRoYXQncyB3aHkgd2UgYXNrZWQg aWYgdGhlcmUgd2VyZSBvdGhlciBzcGVjaWZpY2F0aW9ucyAvIGVmZm9ydHMgdGhhdCBzaG91bGQg YmUgaW5jbHVkZWQgSU4gdGhlIHNsaWRlc+KApiA7LSkgIFRoZSBpbnRlbnQgaXMgdG8gaW5kaWNh dGUgd2hhdCByZWxhdGVkIGRvY3VtZW50YXRpb24gZXhpc3RlZCB0aGF0IHdlIG1heSBiZSBhYmxl IHRvIGNvbnNpZGVyIGZvciBJLUQgZGV2ZWxvcG1lbnQgaW5wdXQuIEp1c3QgYmVjYXVzZSBpdCBp cyBsaXN0ZWQgZG9lcyBub3QgbWVhbiBpdCB3aWxsIGJlLiBUaGUgc2xpZGVzIGFyZSBmb3IgaW5m b3JtYXRpb25hbCBwdXJwb3NlcyBvbmx5LiAgVGhlIGludGVudCBpcyB0byBoZWxwIGZyYW1lIHRo ZSBkaXNjdXNzaW9uIGFyb3VuZCB0aGUgd29ya2luZyBncm91cCBjaGFydGVyIHdoaWxlIGluZm9y bWluZyBhbGwgYXMgdG8gdGhlIHN0YXR1cyBvZiB0aGUgZG9jdW1lbnRzIGZyb20gYW4gSVBSIHBl cnNwZWN0aXZlLiAgQWRkaXRpb25hbGx5IHRoZSBzbGlkZXMgd2VyZSBmb2N1c2VkIG9uIHNwZWNp ZmljYXRpb25zIHRoYXQgYXJlIG5vdCBhbHJlYWR5IEktRHMgb3IgUkZDcy4gIEkgd291bGQgbGlr ZSB0byBpbmNsdWRlIElGLU1BUCBhcyB3ZWxsIGFzIEkgZmVlbCBpdCBpcyBhcHByb3ByaWF0ZSB0 byB0aGUgU0FDTSBlZmZvcnRzIGFuZCBnb2Fscy4NCg0KSSBzZWUgdGhlIFVzZSBDYXNlIEktRCBh cyBiZWluZyBhIGJyb2FkZXIgZG9jdW1lbnQgdGhhbiBqdXN0IHdoYXQgU0FDTSBpcyBjb25zaWRl cmluZyBkb2luZy4gIEkgc2VlIHRoYXQgYXMgYSBtb3JlIG9mIGFuIG92ZXJhcmNoaW5nIGRvY3Vt ZW50IHRoYXQgcHVsbHMgbWFueSBvZiB0aGUgcmVsYXRlZCBlZmZvcnRzIGluIHdoaWxlIGFsc28g ZGVzY3JpYmluZyBTQUNNIHVzZXMuDQoNClRoYW5rcyBmb3IgYWxsIHlvdXIgZ3JlYXQgZmVlZGJh Y2sgYW5kIGhlbHAgdG9kYXkhDQoNCktlbnQgTGFuZGZpZWxkDQoNCk1jQWZlZSB8IEFuIEludGVs IENvbXBhbnkNCkRpcmVjdDogKzEuOTcyLjk2My43MDk2DQpNb2JpbGU6ICsxLjgxNy42MzcuODAy Ng0KV2ViOiB3d3cubWNhZmVlLmNvbTxodHRwOi8vd3d3Lm1jYWZlZS5jb20vPg0KDQpGcm9tOiBT dGVwaGVuIEhhbm5hIDxzaGFubmFAanVuaXBlci5uZXQ8bWFpbHRvOnNoYW5uYUBqdW5pcGVyLm5l dD4+DQpEYXRlOiBXZWRuZXNkYXksIEF1Z3VzdCAxLCAyMDEyIDY6MzIgUE0NClRvOiBLZW50IExh bmRmaWVsZCA8S2VudF9MYW5kZmllbGRATWNBZmVlLmNvbTxtYWlsdG86S2VudF9MYW5kZmllbGRA TWNBZmVlLmNvbT4+LCAic2FjbUBpZXRmLm9yZzxtYWlsdG86c2FjbUBpZXRmLm9yZz4iIDxzYWNt QGlldGYub3JnPG1haWx0bzpzYWNtQGlldGYub3JnPj4NCkNjOiAic2NhcC1kZXZAbmlzdC5nb3Y8 bWFpbHRvOnNjYXAtZGV2QG5pc3QuZ292PiIgPHNjYXAtZGV2QG5pc3QuZ292PG1haWx0bzpzY2Fw LWRldkBuaXN0Lmdvdj4+DQpTdWJqZWN0OiBSRTogU0FDTSBJRVRGIDg0IFByZXNlbnRhdGlvbg0K DQpZb3UgZGlkbuKAmXQgYXNrIGZvciBmZWVkYmFjayBvbiB0aGUgc2xpZGVzIGJ1dCBJ4oCZbSBv biBhIHJvbGwgbm934oCmIDstKQ0KDQpUaGUgVXNlIENhc2VzIGRvY3VtZW50IHJlZmVyZW5jZXMg YSBidW5jaCBvZiBleGlzdGluZyBzcGVjcy4gU29tZSBhcmUgbGlzdGVkIGluIHRoZSBJbnRlcm5l dCBEaXNjdXNzaW9uIHNsaWRlcyBidXQgc29tZSBhcmUgbm90LiBJIGd1ZXNzIHlvdSBsZWZ0IG91 dCB0aGUgUkZDcyAoUEEtVE5DLCBQQi1UTkMsIFJBRElVUywgRElBTUVURVIsIGV0Yy4pIGJlY2F1 c2UgdGhleeKAmXJlIGFscmVhZHkgc2V0IGZyb20gYW4gSUVURiBwZXJzcGVjdGl2ZS4gSGVyZSBh cmUgdGhlIG9uZXMgdGhhdCBhcmUgbm90IFJGQ3MgYnV0IGFyZSBtaXNzaW5nIGZyb20gdGhlIHNs aWRlczogUFQtVExTIChhbHJlYWR5IGFuIEktRCBpbiBORUEsIHNvb24gdG8gYmUgYW4gUkZDKSwg UFQtRUFQIChhbHJlYWR5IGFuIEktRCBpbiBORUEsIHNvb24gdG8gYmUgYW4gUkZDKSwgZHJhZnQt aWV0Zi1taWxlLXNjaSAoYWxyZWFkeSBhbiBJLUQgaW4gTUlMRSksIGFuZCBJRi1NQVAgKG5vdCBh biBJLUQgeWV0LCBjdXJyZW50bHkgYSBUQ0cgU3BlY2lmaWNhdGlvbiBvd25lZCBieSBUQ0cgYnV0 IFRDRyBoYXMgZG9uYXRlZCBzZXZlcmFsIHNwZWNzIHRvIElFVEYgYmVmb3JlIHNvIHdlIG1pZ2h0 IGhvcGUgdGhleeKAmWQgZG8gc28gYWdhaW4pLg0KDQpJ4oCZbGwgbGVhdmUgaXQgdG8geW91IHRv IGRlY2lkZSB3aGV0aGVyIHRvIGFkZCBvbmUgb3IgbW9yZSBvZiB0aG9zZSBzcGVjcyB0byB5b3Vy IHNsaWRlcy4NCg0KVGhhbmtzLA0KDQpTdGV2ZQ0KDQpGcm9tOiBzYWNtLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpzYWNtLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBLZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tPG1haWx0bzpLZW50 X0xhbmRmaWVsZEBNY0FmZWUuY29tPg0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMDEsIDIwMTIg ODo1NiBQTQ0KVG86IHNhY21AaWV0Zi5vcmc8bWFpbHRvOnNhY21AaWV0Zi5vcmc+DQpDYzogc2Nh cC1kZXZAbmlzdC5nb3Y8bWFpbHRvOnNjYXAtZGV2QG5pc3QuZ292Pg0KU3ViamVjdDogW3NhY21d IFNBQ00gSUVURiA4NCBQcmVzZW50YXRpb24NCg0KQWxsLA0KDQpIZXJlIGFyZSB0aGUgc2xpZGVz ICBEYXZlIGFuZCBJIHdpbGwgYmUgdXNpbmcgdG9tb3Jyb3cgZHVyaW5nIHRoZSBTQUNNIFNpZGUg TWVldGluZy4gV2UgbG9vayBmb3J3YXJkIHRvIHNlZWluZyAvIGhlYXJpbmcgeW91IHRoZXJlLg0K DQpUaGFua3MuDQoNCktlbnQgTGFuZGZpZWxkDQoNCk1jQWZlZSB8IEFuIEludGVsIENvbXBhbnkN CkRpcmVjdDogKzEuOTcyLjk2My43MDk2DQpNb2JpbGU6ICsxLjgxNy42MzcuODAyNg0KV2ViOiB3 d3cubWNhZmVlLmNvbTxodHRwOi8vd3d3Lm1jYWZlZS5jb20vPg0K --_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E5EMBCLUSTERxcha_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1XaW5kb3dzLTEyNTIiPjxtZXRhIG5hbWU9IkdlbmVy YXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPjxzdHls ZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21z by1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+PGRpdj48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPg0K VGhhbmtzIGZvciB0aGUgZ3JlYXQgZmVlZGJhY2sgU3RldmUhICArMSBvbiB0aGUgb3ZlcnZpZXcg Y29tbWVudC4gIEkgc2VlIHRoaXMgZWZmb3J0IGNvbm5lY3RpbmcgTUlMRSwgTkVBLCBTQUNNLCBO RVRDT05GLCBEQU5FIGFuZCBtYW55IG90aGVycy4gIEl0IHdvdWxkIGJlIGV4dHJlbWVseSB1c2Vm dWwgdG8gcHV0IHRvZ2V0aGVyIGEgZHJhZnQgdGhhdCBkZXNjcmliZXMgYWxsIG9mIHRoaXMuPGJy Pjxicj5UaGFua3MsPGJyPkRhdmU8L2ZvbnQ+PC9kaXY+DQo8YnI+PGRpdj48aHIgc2l6ZT0yIHdp ZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXIgdGFiaW5kZXg9LTE+DQo8Zm9udCBmYWNlPVRhaG9tYSBz aXplPTI+DQo8Yj5Gcm9tPC9iPjogc2FjbS1ib3VuY2VzQGlldGYub3JnICZsdDtzYWNtLWJvdW5j ZXNAaWV0Zi5vcmcmZ3Q7DTxicj48Yj5UbzwvYj46IEtlbnRfTGFuZGZpZWxkQG1jYWZlZS5jb20g Jmx0O0tlbnRfTGFuZGZpZWxkQG1jYWZlZS5jb20mZ3Q7OyBzYWNtQGlldGYub3JnICZsdDtzYWNt QGlldGYub3JnJmd0Ow08YnI+PGI+Q2M8L2I+OiBTQ0FQLURFVg08YnI+PGI+U2VudDwvYj46IFdl ZCBBdWcgMDEgMjI6MTk6NDEgMjAxMjxicj48Yj5TdWJqZWN0PC9iPjogUmU6IFtzYWNtXSBTQUNN IElFVEYgODQgUHJlc2VudGF0aW9uDTxicj48L2ZvbnQ+PGJyPjwvZGl2Pg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+S2VudCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RmVlbCBmcmVlIHRvIGFkZCBJRi1NQVAg dG8gdGhlIHNsaWRlcyBpZiB5b3Ugd2FudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBzZWUgd2hhdCB5b3UgbWVhbiBhYm91 dCB0aGUgVXNlIENhc2UgSS1ELiBCdXQgaWYgd2UgZGVjaWRlIHRvIGluY2x1ZGUgd29yayBpdGVt IGZvciDigJxhbiBvdmVydmlldyBvZiBzZWN1cml0eSBhdXRvbWF0aW9uIGFuZCBjb250aW51b3Vz IG1vbml0b3JpbmfigJ0sIEkgdGhpbmsgdGhhdCBzaG91bGQgc3BhbiBhbGwgdGhlc2UgdXNlIGNh c2VzLiBPdGhlcndpc2UsIHdl4oCZbGwgZW5kIHVwIHdpdGggYW4gYXJjaGl0ZWN0dXJlIHRoYXQg b25seSBjb3ZlcnMgYSB0aW55IHBhcnQgb2YgdGhlIHNlY3VyaXR5IGF1dG9tYXRpb24gc3BhY2Uu IFRoZXJl4oCZcyBhIGRlc3BlcmF0ZSBuZWVkIGZvciBzb21lb25lIHRvIHByb3ZpZGUgYSBibHVl cHJpbnQgdGhhdCBzaG93cyBob3cgTUlMRSwgTkVBLCBTQUNNLCBhbmQgb3RoZXIgZnV0dXJlIHdv cmsgYWxsIGZpdHMgdG9nZXRoZXIuIEkgaG9wZSB0aGF0IFNBQ00gY2FuIHByb3ZpZGUgdGhhdC4g V2UgY2FuIGV2ZW4gcG9pbnQgb3V0IGdhcHMgdGhhdCBvdGhlciBncm91cHMgY2FuIHdvcmsgb24g ZmlsbGluZyBpbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TdGV2ZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dCI+PGRpdj48ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IEtlbnRfTGFuZGZpZWxkQG1jYWZlZS5jb20gW21haWx0bzpLZW50X0xh bmRmaWVsZEBtY2FmZWUuY29tXSA8YnI+PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDAx LCAyMDEyIDEwOjEyIFBNPGJyPjxiPlRvOjwvYj4gU3RlcGhlbiBIYW5uYTsgc2FjbUBpZXRmLm9y Zzxicj48Yj5DYzo8L2I+IHNjYXAtZGV2QG5pc3QuZ292PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTog U0FDTSBJRVRGIDg0IFByZXNlbnRhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rp dj48cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PGRp dj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlN0ZXZlLCZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Z b3UgYXJlIGRlZmluaXRlbHkgb24gYSByb2xsLiA7LSkgJm5ic3A7VGhhdCdzIHdoeSB3ZSBhc2tl ZCBpZiB0aGVyZSB3ZXJlIG90aGVyIHNwZWNpZmljYXRpb25zIC8gZWZmb3J0cyB0aGF0IHNob3Vs ZCBiZSBpbmNsdWRlZCBJTiB0aGUgc2xpZGVz4oCmIDstKSAmbmJzcDtUaGUgaW50ZW50IGlzIHRv IGluZGljYXRlIHdoYXQgcmVsYXRlZCBkb2N1bWVudGF0aW9uIGV4aXN0ZWQgdGhhdCB3ZSBtYXkg YmUgYWJsZSB0byBjb25zaWRlciBmb3IgSS1EIGRldmVsb3BtZW50IGlucHV0LiBKdXN0IGJlY2F1 c2UgaXQgaXMgbGlzdGVkIGRvZXMgbm90IG1lYW4gaXQgd2lsbCBiZS4gVGhlIHNsaWRlcyBhcmUg Zm9yIGluZm9ybWF0aW9uYWwgcHVycG9zZXMgb25seS4gJm5ic3A7VGhlIGludGVudCBpcyB0byBo ZWxwIGZyYW1lIHRoZSBkaXNjdXNzaW9uIGFyb3VuZCB0aGUgd29ya2luZyBncm91cCBjaGFydGVy IHdoaWxlIGluZm9ybWluZyBhbGwgYXMgdG8gdGhlIHN0YXR1cyBvZiB0aGUgZG9jdW1lbnRzIGZy b20gYW4gSVBSIHBlcnNwZWN0aXZlLiAmbmJzcDtBZGRpdGlvbmFsbHkgdGhlIHNsaWRlcyB3ZXJl IGZvY3VzZWQgb24gc3BlY2lmaWNhdGlvbnMgdGhhdCBhcmUgbm90IGFscmVhZHkgSS1EcyBvciBS RkNzLiAmbmJzcDtJIHdvdWxkIGxpa2UgdG8gaW5jbHVkZSBJRi1NQVAgYXMgd2VsbCBhcyBJIGZl ZWwgaXQgaXMgYXBwcm9wcmlhdGUgdG8gdGhlIFNBQ00gZWZmb3J0cyBhbmQgZ29hbHMuPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkkgc2VlIHRoZSBV c2UgQ2FzZSBJLUQgYXMgYmVpbmcgYSBicm9hZGVyIGRvY3VtZW50IHRoYW4ganVzdCB3aGF0IFNB Q00gaXMgY29uc2lkZXJpbmcgZG9pbmcuICZuYnNwO0kgc2VlIHRoYXQgYXMgYSBtb3JlIG9mIGFu IG92ZXJhcmNoaW5nIGRvY3VtZW50IHRoYXQgcHVsbHMgbWFueSBvZiB0aGUgcmVsYXRlZCBlZmZv cnRzIGluIHdoaWxlIGFsc28gZGVzY3JpYmluZyBTQUNNIHVzZXMuPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoYW5rcyBmb3IgYWxsIHlvdXIgZ3Jl YXQgZmVlZGJhY2sgYW5kIGhlbHAgdG9kYXkhPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM2MDZBNzEiPktlbnQgTGFu ZGZpZWxkPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNjA2 QTcxIj48YnI+PGJyPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk1jQWZlZSB8IEFuIEludGVsIENvbXBhbnk8 L3NwYW4+PC9zdHJvbmc+PGJyPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj5EaXJlY3Q6 ICYjNDM7MS45NzIuOTYzLjcwOTYmbmJzcDs8L3NwYW4+PGJyPjxzcGFuIGNsYXNzPSJhcHBsZS1z dHlsZS1zcGFuIj5Nb2JpbGU6ICYjNDM7MS44MTcuNjM3LjgwMjY8L3NwYW4+PGJyPjxzdHJvbmc+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPldlYjombmJzcDs8L3NwYW4+PC9zdHJvbmc+PHNwYW4gY2xhc3M9ImFwcGxlLXN0 eWxlLXNwYW4iPjxhIGhyZWY9Imh0dHA6Ly93d3cubWNhZmVlLmNvbS8iPnd3dy5tY2FmZWUuY29t PC9hPjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+U3RlcGhlbiBIYW5uYSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnNoYW5uYUBqdW5pcGVyLm5ldCI+c2hhbm5hQGp1bmlwZXIubmV0PC9h PiZndDs8YnI+PGI+RGF0ZTogPC9iPldlZG5lc2RheSwgQXVndXN0IDEsIDIwMTIgNjozMiBQTTxi cj48Yj5UbzogPC9iPktlbnQgTGFuZGZpZWxkICZsdDs8YSBocmVmPSJtYWlsdG86S2VudF9MYW5k ZmllbGRATWNBZmVlLmNvbSI+S2VudF9MYW5kZmllbGRATWNBZmVlLmNvbTwvYT4mZ3Q7LCAmcXVv dDs8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIj5zYWNtQGlldGYub3JnPC9hPiZndDs8 YnI+PGI+Q2M6IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86c2NhcC1kZXZAbmlzdC5nb3YiPnNj YXAtZGV2QG5pc3QuZ292PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNjYXAtZGV2QG5p c3QuZ292Ij5zY2FwLWRldkBuaXN0LmdvdjwvYT4mZ3Q7PGJyPjxiPlN1YmplY3Q6IDwvYj5SRTog U0FDTSBJRVRGIDg0IFByZXNlbnRhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7 bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowaW4iIGlkPSJNQUNfT1VUTE9PS19BVFRS SUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllvdSBkaWRu4oCZdCBhc2sgZm9y IGZlZWRiYWNrIG9uIHRoZSBzbGlkZXMgYnV0IEnigJltIG9uIGEgcm9sbCBub3figKYgOy0pPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48YnI+VGhlIFVzZSBDYXNlcyBkb2N1bWVudCByZWZlcmVuY2VzIGEgYnVuY2ggb2YgZXhpc3Rp bmcgc3BlY3MuIFNvbWUgYXJlIGxpc3RlZCBpbiB0aGUgSW50ZXJuZXQgRGlzY3Vzc2lvbiBzbGlk ZXMgYnV0IHNvbWUgYXJlIG5vdC4gSSBndWVzcyB5b3UgbGVmdCBvdXQgdGhlIFJGQ3MgKFBBLVRO QywgUEItVE5DLCBSQURJVVMsIERJQU1FVEVSLCBldGMuKSBiZWNhdXNlIHRoZXnigJlyZSBhbHJl YWR5IHNldCBmcm9tIGFuIElFVEYgcGVyc3BlY3RpdmUuIEhlcmUgYXJlIHRoZSBvbmVzIHRoYXQg YXJlIG5vdCBSRkNzIGJ1dCBhcmUgbWlzc2luZyBmcm9tIHRoZSBzbGlkZXM6IFBULVRMUyAoYWxy ZWFkeSBhbiBJLUQgaW4gTkVBLCBzb29uIHRvIGJlIGFuIFJGQyksIFBULUVBUCAoYWxyZWFkeSBh biBJLUQgaW4gTkVBLCBzb29uIHRvIGJlIGFuIFJGQyksIGRyYWZ0LWlldGYtbWlsZS1zY2kgKGFs cmVhZHkgYW4gSS1EIGluIE1JTEUpLCBhbmQgSUYtTUFQIChub3QgYW4gSS1EIHlldCwgY3VycmVu dGx5IGEgVENHIFNwZWNpZmljYXRpb24gb3duZWQgYnkgVENHIGJ1dCBUQ0cgaGFzIGRvbmF0ZWQg c2V2ZXJhbCBzcGVjcyB0byBJRVRGIGJlZm9yZSBzbyB3ZSBtaWdodCBob3BlIHRoZXnigJlkIGRv IHNvIGFnYWluKS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmWxsIGxlYXZlIGl0IHRvIHlvdSB0byBkZWNp ZGUgd2hldGhlciB0byBhZGQgb25lIG9yIG1vcmUgb2YgdGhvc2Ugc3BlY3MgdG8geW91ciBzbGlk ZXMuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U3RldmU8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPjxkaXY+PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PiA8YSBocmVmPSJtYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnIj5zYWNtLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86 c2FjbS1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+T24gQmVoYWxmIE9mIDwvYj48YSBocmVmPSJt YWlsdG86S2VudF9MYW5kZmllbGRATWNBZmVlLmNvbSI+S2VudF9MYW5kZmllbGRATWNBZmVlLmNv bTwvYT48YnI+PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDAxLCAyMDEyIDg6NTYgUE08 YnI+PGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9y ZzwvYT48YnI+PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86c2NhcC1kZXZAbmlzdC5nb3YiPnNj YXAtZGV2QG5pc3QuZ292PC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gW3NhY21dIFNBQ00gSUVURiA4 NCBQcmVzZW50YXRpb248L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2PjxkaXY+ PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BbGwsPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkhlcmUgYXJlIHRo ZSBzbGlkZXMgJm5ic3A7RGF2ZSBhbmQgSSB3aWxsIGJlIHVzaW5nIHRvbW9ycm93IGR1cmluZyB0 aGUgU0FDTSBTaWRlIE1lZXRpbmcuIFdlIGxvb2sgZm9yd2FyZCB0byBzZWVpbmcgLyBoZWFyaW5n IHlvdSB0aGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+VGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Ryb25nPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNjA2QTcxIj5LZW50IExhbmRmaWVsZDwvc3Bhbj48 L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzYwNkE3MSI+PGJyPjxicj48 c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5NY0FmZWUgfCBBbiBJbnRlbCBDb21wYW55PC9zcGFuPjwvc3Ryb25n Pjxicj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+RGlyZWN0OiAmIzQzOzEuOTcyLjk2 My43MDk2Jm5ic3A7PC9zcGFuPjxicj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+TW9i aWxlOiAmIzQzOzEuODE3LjYzNy44MDI2PC9zcGFuPjxicj48c3Ryb25nPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XZWI6 Jm5ic3A7PC9zcGFuPjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48YSBo cmVmPSJodHRwOi8vd3d3Lm1jYWZlZS5jb20vIj53d3cubWNhZmVlLmNvbTwvYT48L3NwYW4+PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48 L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E5EMBCLUSTERxcha_-- From david.oliva@verizon.net Thu Aug 2 07:38: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 8FBF611E80CC for ; Thu, 2 Aug 2012 07:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.556 X-Spam-Level: * X-Spam-Status: No, score=1.556 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMtX32TgoebP for ; Thu, 2 Aug 2012 07:38:13 -0700 (PDT) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2EB11E80C5 for ; Thu, 2 Aug 2012 07:38:13 -0700 (PDT) Received: from vms170025pub.verizon.net ([unknown] [192.168.1.3]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M84007E2TYXI060@vms173019.mailsrvcs.net> for sacm@ietf.org; Thu, 02 Aug 2012 09:37:46 -0500 (CDT) Received: from 96.241.55.45 ([96.241.55.45]) by vms170025 (Verizon Webmail) with HTTP; Thu, 02 Aug 2012 09:37:45 -0500 (CDT) Date: Thu, 02 Aug 2012 09:37:45 -0500 (CDT) From: david.oliva@verizon.net To: sacm@ietf.org Message-id: <8872209.1495682.1343918265914.JavaMail.root@vms170025> MIME-version: 1.0 Content-type: multipart/mixed; boundary="----=_Part_1495680_18388667.1343918265813" X-Mailer: Verizon Webmail X-Originating-IP: [96.241.55.45] Subject: [sacm] Proposed SACM Charter Comments feedback X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 14:38:14 -0000 ------=_Part_1495680_18388667.1343918265813 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
 
 
To all:
 
Here's my two cents worth to the SACM charter.
 
 
Ruben David Oliva
------=_Part_1495680_18388667.1343918265813 Content-Type: application/octet-stream; name="Description of Working Group.docx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Description of Working Group.docx" UEsDBBQABgAIAAAAIQAJJIeCgQEAAI4FAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lE1Pg0AQhu8m/geyVwPbejDGlPag9ahNrPG8LkPZyH5kZ/v17x1KS6qhpVq9kMAy7/vMCzOD0UqX 0QI8KmtS1k96LAIjbabMLGWv08f4lkUYhMlEaQ2kbA3IRsPLi8F07QAjqjaYsiIEd8c5ygK0wMQ6 MHSSW69FoFs/407IDzEDft3r3XBpTQAT4lBpsOHgAXIxL0M0XtHjmsRDiSy6r1+svFImnCuVFIFI +cJk31zirUNClZt3sFAOrwiD8VaH6uSwwbbumaLxKoNoInx4Epow+NL6jGdWzjX1kByXaeG0ea4k NPWVmvNWAiJlrsukOdFCmR3/QQ4M6xLw7ylq3RPt31QoxnkOkj52dx4a46rppLbYq+12gxAopFNM vv6CcVfouFXuRFjC+8u/UeyJd4LkNBpT8V7CCYn/MIxGuhMi0LwD31z7Z3NsZI5Z0mRMvHVI+8P/ ou3dgqiqYxo5Bz4oaFZE24g1jrR7zu4Pqu2WQdbizTfbdPgJAAD//wMAUEsDBBQABgAIAAAAIQAe kRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3 IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJn DUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamaba WQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1 RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAI AAAAIQANa5uoTQEAAF0EAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyUwU4CMRCG7ya+w6Z3t4AKxrBwERMOXhTjuXSn uw3bdtMZXXh76yKyCKwe9tKkM+n8X/+ZdjxdmyL6AI/a2YT14x6LwEqXapsl7HXxeHXHIiRhU1E4 CwnbALLp5PJi/AyFoHAIc11iFKpYTFhOVN5zjjIHIzB2JdiQUc4bQWHrM14KuRIZ8EGvN+S+WYNN DmpG8zRhfp5es2ixKYPy37WdUlrCg5PvBiydkOAIROFmGGoKnwElbBeJAyfjpxFGXSJQsAb2+vWW 12u/jWFwhsFo6R06RbF0hm8d+Lr56NBcjrQpAN805TOlQFLTgt+pNo7+GY4Trf5HO2rlvRlbyDb5 YZfyyllaiGXRaMdPqA3itkuIPAy3L7Rd7W34nvSqqmIjhQKoe7vLP7k0vIbZmsBbcXZmb7pkrGD5 cvRyGsGdWfzgU5h8AgAA//8DAFBLAwQUAAYACAAAACEA+QArLD8SAADKnAAAEQAAAHdvcmQvZG9j dW1lbnQueG1s7F3bctvIEX1PVf5hik92IlHgRTfWilu0ZHtdidcqS1tblZetITAkEYEYZAYQTVce 8hv5vXxJTs8AJCCSInRZaw3CZVsiCAwGje6e7tOX+eHHL9OA3QqlfRmeNVpNp8FE6ErPD8dnjV+u 3+2fNJiOeejxQIbirDEXuvFj/89/+mHW86SbTEUYMwwR6t4scs8akziOegcH2p2IKdfNqe8qqeUo brpyeiBHI98VBzOpvIO203LMb5GSrtAa9zvn4S3XjXS46epoMhIh7jWSaspj3ZRqfDDl6iaJ9jF6 xGN/6Ad+PMfYzlE2jDxrJCrspRPaX0yILunZCaU/sivUylOsua+98iKlgLnjgRIB5iBDPfGj5WM8 djQ84iSb0u19D3E7DbLzZlGru3K/xSOXeQcXis/wKpYDrgy3hhievWgaWDrQ+12+1bsjtpz7HiZ9 IzTEYg5lplC8ZzaTKffDxTCPI02euJCIp/D3eyWTaDGdyH/aaB/Cm8VYJJgPmJlzZCQv/2j6QQOs iO7VhEeiwaZu78M4lIoPA8xo1uoy4shGH8piKL05/YzYrAdl430+azjOISS1O2hkhy4heisHL8SI J0G8+s1l7pAZ+VLRDx1xFxyMMfkoFjQijR/4RKN2d/Hhc0JT5EksGwd0mbJXq3cyjDVdrF0fb+ja nwrNfhYz9llOOZhp1hNcxwPt87VfTgahXn+ZCxLfHc3c2ZWBVBj3lgdQwIP2oHNsp6S/Zkfb3ezI Oc3NnGmPHaQzx88ofQKcYAhcoObLPuLQPOjwXD/fA896cf9CaFf5EelcJkfsV6lu6M0bOfsBFIn7 9D+4gqhjWCSjTY51skMFcmUHa+Yjofm+me9Z5IuY6Uq4iSIG80NrghDfwTJi8UQwPdexmGr8zmMY TFKJPZYugnv2JMVDPfVje0Z+iAnXbChgjwjGmTvhQSDCMd0n5vqG4VYMlg4P/a/WuiBWxzlM+1+F tmPPBBv5ZiJ0czPNeI7bczf2STpg3jEN48ljU6ljGgBT9hWLod0YHgKaLeFBNl+hC8IDQ08EEAjf S3UplOZEQrFe8FsfqzS+5zEpV6fV3ndO9p3WtXPSO+z2HOcfRvWTclvVSOnBCwGt5zitU+f0fGBP /741sSHXtfhizGKzGoE2kRJaqFvR6DNYiWKMN0nvF0YyiyX4SYxGAu/qVoQwhYn6IDmNkVNgOEIq zA9pBaB30SLSP/pdVI3om8g9m/juhChNAiA8w/vCnYRYdMdzUD5W0ktAekiBH5rzyKUQMd5T6JHc 5F5OsyAXeEt4GWZhXcvgL7vkPpfWI29slYubzCpDaBkyoeCrGAKS+hPsRsyJqwvEyjNuuzzjHq8q kcoxbp8U/q3P4wLBlty1lPhOScKd9rqHGwjntN+edqqhZuO+2EqxbkmKYb3aBVZbL8ywOrYS8rA8 IU82sF6FVvi4r/1x6APN4uF2sQUWVXah3mEm3MqCx+XJuAssuF6Ww2Q6FHAYRttFGsBuKbbEanK0 QaSrtJpsoKcM94cJ0GnY5ZtIOpTyhozGq5irGDQl4/yUiBvyKWz/397LN9y9sU50du5b+GLZmQYU Wa7yLYNRlTPsd4HR+6MkNAZ60S1dGkhL97RV1ic67TmdVZ5eBwGl/mn35NgZnFfDcMp8S6BnPLJ+ qK+ZSsxKln1J6lgZ9xNHdtXJuZ6AMAgtGFhxTPA9m/mAXkRICPcSacn5QDZWpjxyHJlOokhCJ0Ad 5wGfHEJjYl9AmAlGsngNgmFsNhFKZJ95sIeBjBO7Gd2BIQIMCX9jYN4siREI+wpvd+bHE+vWAu0p okh0x8Kam8d5WmV9NAhSa9cFaf3KAUyOXgqRuJapBfw1FYBWCCSYAiFl3LvloQs+DQHN6BSXvMuV uZXxAQ5we5UrCTk4OXQunNNq6PENkBcwLaFCg8gA0y2I+HLNVLA+VjHZakBW/YV+BaY+TUKkBLBX ojluFpXwhBOYv8dcRPz8MJGJBlPiZGkPg2URdmR8PFYGr02xfh7yYK59/brJrsHGPi7wQeYRMgFS Bk6XDIafsSyQPw+CISyKV1DOyqu9woUxsgOIa597HphPw8qAIEfK11CUWKyvPv30iSX44HIttGW/ NbYJdye+uBVQsmDA4ZzYWydTMvNokJTZ6eMrMg5wAAkdymiL10YxL4QnZ9TQbRBzUoJ7CCsJReEv aG2MfgshIsm5Y1vAVMLNSM/j0sBbAc7raOyupgI8V1yin9e+hj9tGFWEbKQSPx4lMJuJ44kJEfpx DVpHYQoNwxp4O7g2ADMnw8DXEzAzhz1iGZwiruJLhHAtBTXwl4Yorqqw8seiyT6NWASf33eTgCt7 ikB8FcEPI31F6aQbmMlk8dmcgN2ZYOo3GKHVWsRYpCY8HCOkDPkd+ePECqx9wNskQICX29w3CuVi apSWZ6YHaZbI3VMm1AWnYuvscKkywed1euDONG3CGwUyJYPKQSbg8u55bVNcWmtlUEgn2uW8oOdS Bus9sDdzhlVIqJgb/30hknsMvpmCYADC/0oyCbcagkn+CP5NYfX5Ebx7F1kNYxiD8MfhvyOXAy4/ EjzSKPE68fAQCPXDHvMEsjFIeKFFaCU3Soe0Sk5Z2HNJnl0RIePsld+EQikK2GvIuxF1DFU8H7Mg oMHFLCWihxYeo6nR+k6CqEQktbFlMX079mKd1xiXNKNBMWiaRreZr1MlEk+wgI9t2NyDZAcyMom+ dBVZIAbPgHEy4oRWWLvCWNqgWaphZSwxNZgpH2KyhJGDQjrR6gpDHzJqcgQyeS55VUZ0tyPnNB7z Kclmjw0TjGoG/hd0PQ0l6Q2SIqJXEOMfDW/Naz/GrGARRRLf0NyVGOFtE/WSCOo9TRGQmC57RbfE UIBL8KBKvzZOPBQdAt34JgN0SI+n6htLh/hi1TONnX8Ee01BZYPWZDwZMjVXnLPaLKrNoickgVKS 2vUGyBL6C9laMIVkAHSQrCBjpSAtaZOiSyXBCBRpRmSpgb+to0vKbKFPSaotOEr60zNJmUOyqDTO DgI5072CGwxnrmb0mtGfyOitJkN2LgJze0zAkYXyhzuK3HPSrVD2Cx1fYL0CAlM2p+G011qDcROa eHjYPkzz27/z/HFSHXtsLKVXoNcSMMyhsGXzGUC3DShstei2v51kZXMXdoXVFiH1LOYFeSWwFjmX xjTaQNFKo9Ywyj1pihn2AKcxFysuLdQ4jECjsVuXsUXjs6QxP9ipnrGeySiNEgXD31joHMiBqavD CBmIjZXa2tQolzOp7LDuUZJHFX4x2dtjGM6ACOC3wKfAsKg0SZBkXngdBR1aPomktSbgXjkdut4R XbHzdwDFXk8JYj5yTYGZgRUNtEbcamMtxrfmhM5ZBxHJ2goywSbSJWAJINcjPCbYCN+ifIyqLxBR 88cTVKrtdw8dm+6TWgW5xdMkBlm/9N4KCqwENuxjsoPqsjSKlv0hK+9gOa3n9XZJA/VJeh9OHEE+ Nn4JkCKNYBotbwWNpCwtTvrff/5rNb3FMjIcOi1TYoUiFAKTjCzuF4Rx/4HCaA3kLNicF8bCN89b y1lWGNtlM+1Oe21ryVZEGJf6qF0+Yy7VRyZHoCKJAh0SUYiMjhFQEVhoZuxqcP6xYO6sc4Ha5dOj 2htcx7dd56R7WOlElDto9naqlk/vqR4vrl9DDPo8BE5NNn4aeTAQP8oLAcbNRLCdqmUTTRZKrpDt SSZ6pXi1X4Jk5ZGhnRDv/naEo/0AUMjatRVaRzbILoLtSBO22QXF9IHtQvsAwChXA1CNZXk9OccS XYpCE/PcTr4HwBKV48Y+gLQo8A2lphK5x5vqJnJWYHmvtO0sE2urzG57m0CbJdU65d2H1o4IqalT QNzvw9Un1j5GW4cSVCzvgXQ32NKVSuruE0Z2Lof+9VY113mAG7IjYstenQMOUTJgn4b/tC01KAqt 2Idl3oVBP64XTSBeb6dzecckxQkqbkKvpPBBKZpasdW4fuo7ZAjQuhK7zzlYqHj6t4SFvn+INbcy Pc7nq8Z63u+uR3XuwBF3XesstUuOtuuD8v5hJ7fwZzKwI3VILJAu3+5sd8p7jp2crb5rxNzOlOVd xvwiVQ2ZX+8yotGWr21P1hJ2aHmfcSeEuo9UWCRUmRyEEiZSeQ+ylmKSZVtbb+ymfEKFbVBaKj5c PSnuI2VFuuiEBbDbFKchMhnb5HZCu1EKd0thGnKQJoIH8WTfVKAYaHyRVZ0Wy8MJpXyYS7rGnbOB awDz1ulx11xP3/1kxoBnsFW3dsv7qJ0NvVKq5aNqlCVQ/vwlMjmyyiN6LQPXReXf4hBR/dVPHy4H g+0apFvemd1lDZIGgX5B3TH4/srkbT3AHXtgx+WUa1Njq3bHHtILd+mOdcvjB91c29RqmGb9ww3q Fcg0+IqaJXXLu6t5+uRdgBJ8fWE7zVZJEWeNRTpE4uzD0rrAkRUg6j5CVYThmuyccmcprTC3IQP1 xpkJlAeLL7626YdZ4TsaPyyqZtPNLqiBD1W12kY/aMuMmIoSE4GaYBQX3PpoCA+LZE0R4B5DM0+U 45oa2sWtTIEyLZA+QjOmOtfY1XpFc68CaPe9sEwCcgBa8fTn1djfeY0DZOQP3CP/uWph76sAQ6dj W4Nu67KQg1tXZj1bMXbrZLVPvj1G7h41Nf/uGXD7I1Id0V/YIMzHW9AeZ7FVkC1DpORvlOdSRP8e VWoctWV2a5bbShdDNfuhGyQoaORQ81k5rwl33zU3apX62FrD7a97Nzh6PboINif/i7prwFi4xmYL N0s+t4X8c+LVISrNJ9QflDK1l807wLawKDSK9Y0psAJQ1mxbs+3GEtntkoktj7BP0WcU1KHVgXeJ njBvYBTfmAT2+1U01YIR344T1IvTvkmaHYBZ0WhBGcvVxtNzDI693lzTYSNAj5oEd1pJOKp5uebl J/EycewmXWu2tkF7J6Ns8/WMaJpUM+as9/tsSbZdA9W2wXbbAEawyQxWkrYEArKwwrK1XVA7aKF1 LEsgBNulMnXQNmrTNEvGKNMI8BnF1RAFpgaSe4DJYnSXNM4b2rtEyDJ20+hP7XTlt4h8Sk+37a9w NxQrwQiluJT6HKAVmAdPatHj0UAHy0LzXNOtmlFrRn1edfo0dMAs/xv66FHTQdtGzxYAUh7zmpDD PThZze01t784t6cd4chuoLQbbKisCSQwbBsiKEfNpZecTkzuIUKnfDR5pGuusj4Fg+VOg5TkT20u a/6u+ft5+ft+syPHyqS4x9SHGSy6SSn/nHL329CzzUcHpieT6aWKvXes7YxGpzUb12z8Qmy8VLyU nuDxmFO5FBy9FOYl5Uvdb7XdLoN5c3IGXezYYhU3ocXUHd1ehH5ljKOhRk4k0t4zNYs/F4s/JAft j9gwb2hiEMNzbX6WADXaawLr9hg84TQnJe6/lxz9m4mJP/oBSu/RcbrWq8+GnX3vTPdsbPaz2akK +QfoypK2Rhf1/ibsBRiNYDDKWMSefHYrK9NNsu043QE1i1vd3So7WGfLnTVqeUY+FmHh+/ZPbZ58 e/OkFmB91nhsYsDvKsADhT3tynbcXJxMUQ/7wVp4m+28I+docNyyHo/+Cr2MPsNnje2Rj429Nv+2 AgZhXVBSjt4qMoHjeYSNmJGyEgTIIlCxvfODjePFk5ZpRLo4+ZuQpf93WL4jXwTF/u2bqABA4iVp ULDGHs8MQwUWIx+gUOVQaDFxT0nD4gU95W1W50mG31BcP7qDkRDs30X8dg2zAmCbVlViB2HB6Njw 9C8sqd+SK5AzHqMm7BylNig9v0Ocl1HWzyneGxevCyRWunGP/bXVPD1uN0+POs1j5/TornBUggL9 j+hsFQjzsCet4+ZR57h54rSPKve2X3ZZ+pZi+6sY9u7y6gQGl0Lu8A1TpsJTffBMz5x4HL+DSocx 9tsQ2cI3DRhn2LAKey7PYf81/iDruIM/7941zIJYxjyd9ZLMhtUIBwWCLiUGoKIfcjJns1lz6nKs eU0UEhZ4HactiGUrhOiSAqbR7hy/eXNBpDKYRg6+SL+xE4UOuVzoCMJC0m/NeOMrMrNnIHK7bXtM TPD74Ql+N1dH44/YwRRzlRGOd+0p6XYG2cehjGM5XX4diBE2O8i+RUcGpJqfNY5tV/WRROuG5cdx EpuP6e2gVzXupiNsIGgvMbNAmdB75dNOCpR3fukj2+ys0TkyF4FQCLPhEQ2VhtKbm1+yyqL+/wUA AAD//wMAUEsDBBQABgAIAAAAIQAw3UMpqAYAAKQbAAAVAAAAd29yZC90aGVtZS90aGVtZTEueG1s 7FlPb9s2FL8P2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQokDSSX0b2uOAAcO6YYcV2G2HYVuB Ftil+zTZOmwd0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+pq9fuxwwdEiEpT9pe/XLNQyTxeUCTsO3d HvYvrXlIKpwEmPGEtL0pkd61jfffu4rXVURigmB9Itdx24uUSteXlqQPw1he5ilJYG7MRYwVvIpw KRD4COjGbGm5VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9Bq+JknrAZ2KgSRNnhcEGB3WNkFPZZQId Ytb2gE/Aj4bkvvIQw1LBRNurmZ+3tHF1Ca9ni5hasLa0rm9+2bpsQXCwbHiKcFQwrfcbrStbBX0D YGoe1+v1ur16Qc8AsO+DplaWMs1Gf63eyWmWQPZxnna31qw1XHyJ/sqczK1Op9NsZbJYogZkHxtz +LXaamNz2cEbkMU35/CNzma3u+rgDcjiV+fw/Sut1YaLN6CI0eRgDq0d2u9n1AvImLPtSvgawNdq GXyGgmgookuzGPNELYq1GN/jog8ADWRY0QSpaUrG2Ico7uJ4JCjWDPA6waUZO+TLuSHNC0lf0FS1 vQ9TDBkxo/fq+fevnj9Fxw+eHT/46fjhw+MHP1pCzqptnITlVS+//ezPxx+jP55+8/LRF9V4Wcb/ +sMnv/z8eTUQ0mcmzosvn/z27MmLrz79/btHFfBNgUdl+JDGRKKb5Ajt8xgUM1ZxJScjcb4VwwjT 8orNJJQ4wZpLBf2eihz0zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJiaIVnHei2AHucs46XFRaYUfz Kpl5OEnCauZiUsbtY3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcYThQOSUIU0nP8gJAK7e5S6th1l/qC Sz5W6C5FHUwrTTKkIyeaZou2aQx+mVbpDP52bLN7B3U4q9J6ixy6SMgKzCqEHxLmmPE6nigcV5Ec 4piVDX4Dq6hKyMFU+GVcTyrwdEgYR72ASFm15pYAfUtO38FQsSrdvsumsYsUih5U0byBOS8jt/hB N8JxWoUd0CQqYz+QBxCiGO1xVQXf5W6G6HfwA04WuvsOJY67T68Gt2noiDQLED0zERW+vE64E7+D KRtjYkoNFHWnVsc0+bvCzShUbsvh4go3lMoXXz+ukPttLdmbsHtV5cz2iUK9CHeyPHe5COjbX523 8CTZI5AQ81vUu+L8rjh7//nivCifL74kz6owFGjdi9hG27Td8cKue0wZG6gpIzekabwl7D1BHwb1 OnPiJMUpLI3gUWcyMHBwocBmDRJcfURVNIhwCk173dNEQpmRDiVKuYTDohmupK3x0Pgre9Rs6kOI rRwSq10e2OEVPZyfNQoyRqrQHGhzRiuawFmZrVzJiIJur8OsroU6M7e6Ec0URYdbobI2sTmUg8kL 1WCwsCY0NQhaIbDyKpz5NWs47GBGAm1366PcLcYLF+kiGeGAZD7Ses/7qG6clMfKnCJaDxsM+uB4 itVK3Fqa7BtwO4uTyuwaC9jl3nsTL+URPPMSUDuZjiwpJydL0FHbazWXmx7ycdr2xnBOhsc4Ba9L 3UdiFsJlk6+EDftTk9lk+cybrVwxNwnqcPVh7T6nsFMHUiHVFpaRDQ0zlYUASzQnK/9yE8x6UQpU VKOzSbGyBsHwr0kBdnRdS8Zj4quys0sj2nb2NSulfKKIGETBERqxidjH4H4dqqBPQCVcd5iKoF/g bk5b20y5xTlLuvKNmMHZcczSCGflVqdonskWbgpSIYN5K4kHulXKbpQ7vyom5S9IlXIY/89U0fsJ 3D6sBNoDPlwNC4x0prQ9LlTEoQqlEfX7AhoHUzsgWuB+F6YhqOCC2vwX5FD/tzlnaZi0hkOk2qch EhT2IxUJQvagLJnoO4VYPdu7LEmWETIRVRJXplbsETkkbKhr4Kre2z0UQaibapKVAYM7GX/ue5ZB o1A3OeV8cypZsffaHPinOx+bzKCUW4dNQ5PbvxCxaA9mu6pdb5bne29ZET0xa7MaeVYAs9JW0MrS /jVFOOdWayvWnMbLzVw48OK8xjBYNEQp3CEh/Qf2Pyp8Zr926A11yPehtiL4eKGJQdhAVF+yjQfS BdIOjqBxsoM2mDQpa9qsddJWyzfrC+50C74njK0lO4u/z2nsojlz2Tm5eJHGzizs2NqOLTQ1ePZk isLQOD/IGMeYz2TlL1l8dA8cvQXfDCZMSRNM8J1KYOihByYPIPktR7N04y8AAAD//wMAUEsDBBQA BgAIAAAAIQCMfx0AsgMAAFUJAAARAAAAd29yZC9zZXR0aW5ncy54bWy0Vttu2zgQfV+g/2DoeR3J jp04QpQicepui7gtqvQDKGlsE+ENJGXF/foOSTFqNm5QbLFPIud+OTPU5dtHzkZ70IZKUSSTkywZ gahlQ8W2SL7dr8aLZGQsEQ1hUkCRHMAkb6/e/HXZ5QasRTEzQhPC5Lwukp21Kk9TU++AE3MiFQhk bqTmxOJVb1NO9EOrxrXkilhaUUbtIZ1m2VnSm5FF0mqR9ybGnNZaGrmxTiWXmw2tof9EDf07foPm raxbDsJ6j6kGhjFIYXZUmWiN/1drmOIuGtm/lsSesyjXTbLXJPt0O6mbJ43fCc8pKC1rMAYbxFlI lxMqnsxMZi8MPZX6BEudBt+pM4Xqk8yfhsgNe6F/pNuhi3e00kSHNiMAXBS8zj9shdSkYgiqbjJL rhBR36Xkoy7fEzRegbErahO8K9A1Nq1IFlmSOjnMTW5KSywg1yhgzMO1ZkDQdpdvNeEItCIJFK9j NakfvsKeOqQbT2pgQ1pm70lVWqmi4/Np76XeEdSxoEtFanSwlMJqyaJcIz9Ju0QcayxziCug2kUY TmWYENQQhGOegdqjfi0bcMG2mr4o5S9b4RR8ebBiPofjjiROtKYNYGoMSntgsMLgS/odrkXzsTWW 4hx57P9BBK8FAMJ5/ozzf39QsAJiWyzT/+TMd2LFqFpTraX+IBpEy586S2MTXTtxPTYmHr5KaWMb smyOy2t2HWrhxAbOJJu+uzg9yrnILpZHdaan5zc3t8d0Zovz7Hp5jPPrCObz6TwC5Xlsi3l2m10c s/Zuli1mc8fBCvR589wtty/66jKcHJhGPABxSXilKRmt3fpDLZ5X+uGGisivANc//Mwp2yoyx+PA MJwwtsJpiww/gjxvqFG3sPFm2Zro7WC3l9BHqTjZH59sud0B+r2WrQreOk1UAEl0N5nNentU2DvK I920VRm1BK6wn1itaD7vtTOYDuXpcosvnx+2OyK2EQsgxt9KJ4qYYrp0ryOsiVK4VFCk2k6KhNHt zk7cgFi8NfhK+ku1nfa8qefhzfH8hdQuM5TuD04gHFGqPwy000g7HWj4BgS52UCbR9p8oJ1FGr7S Xb7Dida4cR9wbcWjo28kY7KD5p9ILJIXpFAEsyMKsK9u++JYydwT+nVsRvscHnHbQ+PWv1G04eQR /02y6ZlT76UZOcjWPpN1PCesnlFHDbEE1X2rnil7iP8rli5voKYIx/LAq2HZn4TAGTW2BIXvgpUa U/ar+G9vefgfuvoBAAD//wMAUEsDBBQABgAIAAAAIQBufgutngIAAKcfAAAUAAAAd29yZC93ZWJT ZXR0aW5ncy54bWzsWVFv2yAQfp+0/xD5vTUYG3DUpFLWdZo0TdPW/QDHJgkaGAtovPbX72wnXbtm UvOQWqpQHoyBuxzfXY7LdxeXv7WabIV10tSzCJ+jaCLq0lSyXs+inzfXZzyaOF/UVaFMLWbRnXDR 5fz9u4t22orlD+E97HQT0FK7qS5n0cb7ZhrHrtwIXbhz04gaFlfG6sLDq13HurC/bpuz0uim8HIp lfR3cYIQjXZq7Eu0mNVKluLKlLda1L6Xj61QoNHUbiMbt9fWvkRba2zVWFMK5+A8Wg36dCHrBzU4 faZIy9IaZ1b+HA4TDxbFnSoQx6gfaRVNdDn9vK6NLZYKEGxxGs0Bvkpu3e45aaeyAvQZRTjhLEn6 DUtT3V3JLSxuCwWrUdxtB/S+iJXfz6KH2e9yvTkwfWOa53sXxnuj/5kHgxaV7b7D/5WpwesRbHT3 swhiAwZNUcIp+nFplAFnFbfeDGaoR5YdJ7l8YtFxsvbxyY8RjXsv7A7d+ePDRqrqqVNYynKaZIT1 PgnoP/P5SdHHWZYzxhAhAf7DP7nTwk9pgjOSp3mAfwT4aUYAfkZwQH8E9DNCKOeUhNj/z21/0tST YAQXL+OUhuAfIfgxwpznNE3DxTtG9OM0QWlKEQrwjwI/SwmAj/jwTyxU/a9b9Wc04wzQD5l/hMzP MoJwSsYp+Tv2RT0QDsAIHSQcPuLu82YpB4wohtIzTwPnMEbyzzu2J89oyP2joE9yzijhofAZA/0E 5ZwQTMfJ/sdwt+30DZLNOMmyhED8h9xzwugfaP+nND+mPME451lA/oTID12vA10WyPmY4YQGru2E 6O/jfnjum11hdmj6vRIOXdoxjZda3otrYxfWtE7YvrVbKGXab18/wQsY86i9Pv8DAAD//wMAUEsD BBQABgAIAAAAIQChT7cukQkAAEhJAAAaAAAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWy8XNty 2zYQfe9M/4HDd0cXO1bjqdJxlLrxTNKmkT19hijIYk0SLEHZcb++iwtBiNeFSPfJJgjs2RvOQjZW P//yPY68J5rxkCVLf/Zm6ns0Cdg2TB6W/v3dzdlPvsdzkmxJxBK69F8o9395/+MPPz9f8fwlotwD AQm/ek6Dpb/P8/RqMuHBnsaEv4nDIGOc7fI3AYsnbLcLAzp5Ztl2Mp/OpvK3NGMB5RzQViR5ItzX 4uK6NJbSBLB2LItJzt+w7GESk+zxkJ6B9JTk4SaMwvwFZE8vCzFs6R+y5EordGYUEkuulEL6R7Ei q1nRgKtWfmTBIaZJLhEnGY1AB5bwfZiWZpwqDUzcFyo9dRnxFEfFvOd0dlHDMyZjYvAxI88QilJg TVyDM7ZqURwpP4j4llGtSpxNu4zREREijA4YFY4xC01iEiZGzGmusZ0L+2FIfv+WsUNq1EnDYdJu k0cjS2xLB82ml3Ln2aZxJwG1rbvek5T6Xhxc3T4kLCObCDR6nl14IiP990AVWxZ8pDtyiHIuHrOv mX7UT/LHDUty7j1fER6E4R1QCEiJQxD46TrhoQ9vKOH5NQ9J48u9mNX4JuC5Je1DuA39iUDk/4LM JxIt/fm8GFkJDY7GIpI8FGM0Obtf25osfTO0AblLn2Rn62shbCLNLH5a5qZHxsOTVCUlAew8wCG7 nAIJAYsJnCgU0Z0vgNHUw7eDcC455EyDSAEAZouFx4rHgZuAqdaKseEt3X1mwSPdrnN4sfQlFgze 337NQpYBjS79d+8EJgyuaRx+CrdbKgqEHrtP9uGW/rWnyT2n23L8zxtJz1piwA5JDupfLmQWRHz7 6/eApoImQXRCRIR/FwuAwyAcFo5U6BCW2qiBCqoc/KeAnKkYNqLsKRElzZP6dwJJqw+DgebCItsA KddJ1/PhIi6Gi3g7XIRM3mG+WAzXAg4yQyOicsPKSnxQcxao5LP9cP6uI2XFiloW9a6oJU3vilqO 9K6opUTviloG9K6oBbx3RS2+vStq4excERBJXNUsOpfeQG3suzCPoE72MN1sINXpUuN9JRl5yEi6 90RhrardRZbrwybHqSrp9HSyXOcZE8fNHo9AdRZb92RO/jVO94SHcCrvAxro+jtx9PF+y0I4vvZA vVXJV7NJHkwaS9jXiAR0z6Itzbw7+l1F1GH978xbq1NGr3IDw/o5fNjnHpwKRcntBbtscXq7J5T8 zyGXPuis5pctpvQJR8XwsiUv24V/odvwEBeuQZxGLhWfO4S5AiFV7HbRhQhRfXf1WiECgDFBlQt3 E6R8hP6quLjLFzHG6K9K0YnyEfqrwnWifJkf3fF1ZpqP8GcVD7W9Fs57d8Uilu0OUbEHeulh4byD DQTOBOdNbOSjSGLhvIOP6NO7DgL45IbJU+dYlDzqgOIcDoUiNxveFuegVGhv5mCRc4AqWHMHrGFc 6wDkTLrf6FMo/gjsWgwkS5uzZu92Pm/xAJQg1Bn6zwPL+8/Q8xbOw6LcJvDnEk49HNp5y87Doul8 UvXOIcbDCp8D0LAK6AA0rBQ6ALXkR/uZx9REPMjw4uiA5UzLporJtEMz88KZmQ2QWwkYqW4izl8t u7c9F+p1E4HiHKB63USgOEenUstM3URgjVY3EVgtVaM9RjanuhjlXDdtIHMSQFg0DnkjgMYhbwTQ OOSNABpO3v0g45E3AsuZGwyn2uSNAJJTXD7qGyCbvBFAztyg2E7/zaioe1JK94fbEcgbgeIcoDp5 I1Cco9NG3ggsOcUlEypYhuoQWOOQNwJoHPJGAI1D3gigccgbATQOeSOAhpN3P8h45I3AcuYGw6k2 eSOAnOnBANnkjQCSU1y4oZG85a5/dfJGoDgHqE7eCBTn6FQI1RxSEVjOAapgGfJGYMkpLsmgsWRy uxg1DnkjLBqHvBFA45A3Amgc8kYADSfvfpDxyBuB5cwNhlNt8kYAOdODAbLJGwHkzA2N5C0346uT NwLFOUB18kagOEenQqiG5xBYzgGqYBnyRmDJfBlM3gggOeVUIBeLxiFvhEXjkDcCaBzyRgANJ+9+ kPHIG4HlzA2GU23yRgA504MBsskbAeTMDY3kLffIq5M3AsU5QHXyRqA4R6dCqIa8EVjOAapgGapD YI1D3gggmZiDyRsBJKecACR3kUuYxiFvhEXjkDcCaDh594OMR94ILGduMJxqkzcCyJkeDJBN3ggg Z24Q92zhvij6euqsJQmw9wyKWw1owHlLkLCA2sBvdEcz6Cqk/bdDBgIWFjogtqQH1sQPjD16uIvd 5y0JgoYKN1HI5JXuF3lLx2pEOF90dBLc/bHyPqkGmNo6mVLHN2+ge8huF5LtSaJxCPTMX1Jo2UmL m+VCGjQIib4u3QIke0JvoSFIt/WIxaLPBybKpio9LP9vq1Hhd0CUC+tQwR6wAuiI6oDSF97NHSR5 3b0K3HIrXipStmQUaurb8eUZSs07uqPZqXcuboJ36Cxvinf6yJNTVFTrCkJzllSpT0MI2SZSLWbw y22yBQufdXeWCub2O1Gi4P2KRtEXIhvScpa2T43oLldvZ1NZASuiNizPWdy+PpMXxKUmTQIgHWxl 1KMwoj1PkkO8oZm+bt6akqJyyE6045RUd11bUgHr6XbdjnLYbJBPsJUyaO97rClUvpEqbQh02P0h GubkDmrM9oG6Q6sih7vQGmE6fQvdhxfXKi2gV1PspUDc2y1nTKc3Nzo3i0HRxA05D6qAK+QqpEuC A4dskb2JVRYhaRrRM+mzM56SpOar2gQ3l7WZjdTcBFM3slRJRw+76VTf7EV3akmYiIBtFOqKuwfE mLVisWhwL6tp1UCSJAw6SEU/Z2aK/FBzsTuu6oSLnxbT69VR1pYdvrNL9YL/W3b4qrH+bD2qd1Xn yFacDr/kolWnySV2KRQ8UOwj7XQhdwXVT62tJ8UYXqo1H+t24wt5q0I8NLcb6/0NVbvsoJ7W/TuX Y/3+PSLIDjaoeqbqdf1edkd5pe/QBNoSBccIHHNKZ1IqBwk3lkmJdVpnUsLB+28a1GudtV+5ntKU mpajlfEJJGNDfqqXDW7T+GUMXid/dW3aKBtOobr+bLNNaUs4Pac95yyHlj5p99vYGWc7aKxN25x/ H0gUMZY0kqJ+p5oXm9KujREtoaX3Xiejaoyov47BECJ8mwGaHbOjb7RY+ndkz2IiPhXI76qwBwL4 Cg79WnqmJNYhhSuwPz11pHrVwdU8tyPXnuTtJ1M70y2ssdP8f/d3cUzk7/8DAAD//wMAUEsDBBQA BgAIAAAAIQCF3sqMSgEAAHcCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACMklFPwyAUhd9N/A8N7y20U7OQliW67MklJs5ofCNwtxELJYCr +/fSdqtd9MHHyzl899wL5eJL18kBnFeNqVCeEZSAEY1UZlehl80qnaPEB24krxsDFTqCRwt2fVUK S0Xj4Mk1FlxQ4JNIMp4KW6F9CJZi7MUeNPdZdJgobhuneYil22HLxQffAS4IucMaApc8cNwBUzsS 0QkpxYi0n67uAVJgqEGDCR7nWY5/vAGc9n9e6JWJU6twtHGmU9wpW4pBHN1fXo3Gtm2zdtbHiPlz /LZ+fO5HTZXpdiUAsVIKKhzw0Di25AclSzw56bZXcx/WcdFbBfL+eDb9Fjqvg4PqXogVJZ6WsUs/ 1NAKZBJj0mGos/I6e1huVogVJC9SMk9JvskLeksoIe9dpov7XezhQJ+S/ZM4ozfzS+IZwPrEl1+F fQMAAP//AwBQSwMEFAAGAAgAAAAhAPlfm3cOCQAAV0YAAA8AAAB3b3JkL3N0eWxlcy54bWy8XNty 2zgSfd+q/QcW3x1d7FgT1yhTjjPeuCqTyUR27TNEQRY3JKElqTier99GgwIhXrtNep9sXtAH3X1w GrLR+vW3n3Hk/ZBpFqpk6c/eTH1PJoHahMnj0n+4vz37xfeyXCQbEalELv1nmfm/vf/nP359usry 50hmHhhIsqs4WPq7PN9fTSZZsJOxyN6ovUzg4ValscjhMn2cxCL9ftifBSreizxch1GYP0/m0+ml X5hJKVbUdhsG8qMKDrFMchw/SWUEFlWS7cJ9drT2RLH2pNLNPlWBzDJwOo6MvViEiTUzu6gZisMg VZna5m/AmYmZ0USbguGzKf4WR74XB1d3j4lKxTqC4D3NLvz3ELmNCj7KrThEeaYv069pcVlc4Y9b leSZ93QlsiAM7yGkYCAOwdan6yQLfXgiRZZfZ6FofLjTbzU+CbLcsfYh3IT+RCNmf4PNHyJa+vP5 8c6NnsHJvUgkj8d7Mjl7WLkzWfr21hrsLn2Rnq2utbEJunn86bi7P3EernAqexFAMgBHbHMJpACO aJwo1BycL4Av5uLbQcdVHHJVgKABAHPNwmUl4sAVYM7KEBieyu1nFXyXm1UOD5Y+YsHNh7uvaahS IOnSf/dOY8LNlYzDT+FmI/V6Ke49JLtwI/+9k8lDJjfl/b9ukfyFxUAdkhymf7lAFkTZ5vefgdxr 2oLpROgMf9EDgDiQDgcHJ3QIy9mYGxVUvPnfI+TM5LARZSeFXuEezr8TCL0+DAaaa49cB9Aua67n w01cDDfxdrgJJO+wWCyGzwJ0fWhGDDccVtKTmqvAkM+Nw/m7DsrqETUW9Y6okaZ3RI0jvSNqlOgd UWNA74hawntH1PLbO6KWzs4RgUDhqrLoHKNBWtj3YR5JPb5TgGYDpa4oNd5XkYrHVOx3ni6s1Wl3 ieXqsM5pU0U5fblYrvJUJY+9EYHqrJfuizX593i/E1kIu6Se0M8Hhv5e73q8f6XhphfqrSFfzSfc mDSWsK+RCORORRuZevfyp8koY/wX5a3MLqN3cgPT+jl83OXeaocltxfssiXo7ZEw9j+HGcagczFd trjSZ5yUw8sWXrYb/0NuwkN8DA1hN3Jp9JyR5goETrE7RBc6RfXV1euFTgDFBVMu+C6gfcL8TXHh 29c5pszflKIX2ifM3xSuF9pHfnTnl600H+FDq0daXgv22r1RkUq3h+i4BnrlYcFewRaC5gJ7EVv7 JJFYsFfwiXx610EAn9woPGXnotRRBgo7HQYFFxvdF3ZSKrI3Y3jETlAFa87AGqa1DCC26H6TP0L9 NzFuMUCVtnvN3uV83hIBKEGkPfRfB5X376HnLZpHRblL4M8lmfRoaOctK4+KVvDJ1DtGjocVPgbQ sArIABpWChlALfxo3/PYmkgHGV4cGVhsWbZVDGlHVuYFW5ktEK8EjFQ3CfuvltXbzoV63SSgsBNU r5sEFHZ2KrXM1k0C1mh1k4DVUjXac+RqKscpdt10gexOgODROOJNABpHvAlA44g3AWi4ePeDjCfe BCy2NlhNdcWbAISvcD7qWyBXvAlAbG0walf8zehY99BK94fbEcSbgMJOUF28CSjs7LSJNwELX+Ew oYJlpY6ANY54E4DGEW8C0DjiTQAaR7wJQOOINwFouHj3g4wn3gQstjZYTXXFmwDElgcL5Io3AQhf 4WhDo3jjqn918SagsBNUF28CCjs7FUG1m1QCFjtBFSwr3gQsfIVDhgILyc1xahzxJng0jngTgMYR bwLQOOJNABou3v0g44k3AYutDVZTXfEmALHlwQK54k0AYmtDo3jjYnx18SagsBNUF28CCjs7FUG1 OkfAYieogmXFm4CFfBks3gQgfOWlQByPxhFvgkfjiDcBaBzxJgANF+9+kPHEm4DF1garqa54E4DY 8mCBXPEmALG1oVG8cY28ungTUNgJqos3AYWdnYqgWvEmYLETVMGyUkfAGke8CUBIzMHiTQDCV14A hKuIk6ZxxJvg0TjiTQAaLt79IOOJNwGLrQ1WU13xJgCx5cECueJNAGJrgz5nC+dFycdTZy0koJ4z OJ5qIAPOW5JEBSwc/Ca3MoUmK9l/OmQg4NFDBmILPaguflDqu0c72H3eQhAyVLiOQoVHup/xlI7T iHC+6OgkuP/zxvtkGmBq45BSpydvoHvIbRfC9iTdOATzzJ/30LKzP54s19agQUj3dRUtQNgidwcN QUVbjx6s+3zgRWyqKm7j/20LVPgdEHFgHSrYAVYAHVEdUMWBd3sGCY+7V4FbTsXjRMqWjOM0i9Px 5R7KvHdyRrNz3rk+Cd4xZzwp3hkjD18xWa1PEJqzcEp9M4SUrSPTYga/3CUb8BCaBPG/ZiaZm5/C mILnNzKK/hDYkJarffurkdzm5ulsihWwYmqt8lzF7eNTPCCOM2kyAHRwJ2MutRPtPEkO8Vqm0OHV EfMvSlcO7EQ7paQ569pCBWqk2+d2wmG7QD7BUkqhve97bULlE5zSWkCH3Z+6YQ5XUCPbB84dWhUz OAtdIEynb6H78OLa0AJ6NfVaCvS53fKN6fT2tuDm8aZuJgXOw1QgFDiKGJLgkAFbsDexqiJiv4/k GcbsLNuLpBar2gu8kLW5TZy5TWbRyFIVneI2b071xX7sTi0Fk5CwtUG9yfgJsW7dqFg3HJfVtOqg SBIFHaS6nzO1RX6ou9QVVw3CxS+L6fXNCWvLDt/ZpXmQ/V12+Jp7/Ww9qXfV4GArTkdcct2q0xQS txRqHTiuoyLo2u4NVD8ztk6KMaJUaz4u2o0vsD7oi+Z242J9Q9UuO6in9fhCOxWffB1qUI1MNerF c+yO8srYkQW0JQvMDJxqSicpTYB0GEtSUoPWSUrYeP9HBvVa56zXrHiliZpOoI3zCZCxgZ/mYUPY CvwyB6/D36I2rY0PL5G6fra5rrQRrninnXNOQMuYtMdtbMa5ARpr0Tbz74OIIqWSRlEsnpnmxSba tSmiY7SM3uswqqaIxdcxWEGEbzMgq2N68o0WS/9e7FQs9A4Vv6vCvRFk9gojUwrrkMIVuJ+eOqhe DXCV527m2knevjN1me5gjU3z/3u8j9vE7P3/AAAA//8DAFBLAwQUAAYACAAAACEAk1byZAUCAACz BgAAEgAAAHdvcmQvZm9udFRhYmxlLnhtbLyU3Y7aMBCF7yv1HSLfL7FDoLvRhhVLF6k3vai2D2CM Q6z6J7INKW/fiR2yEoguadUmUgRn7KOZTzPz+PRTyeTArRNGl4hMMEq4ZmYr9K5E31/Xd/cocZ7q LZVG8xIduUNPi48fHtuiMtq7BO5rVyhWotr7pkhTx2quqJuYhmsIVsYq6uGv3aWK2h/75o4Z1VAv NkIKf0wzjOeot7G3uJiqEox/NmyvuPbhfmq5BEejXS0ad3Jrb3Frjd021jDuHNSsZPRTVOjBhuQX Rkowa5yp/ASKSWNGaWcF1wkOv5REiWLFl502lm4ksGtJjhY9uKQtNFUgrqgUGytCoKHaOE4gdqCy RDjDazyDb/fmeNp9Udo5sJpax/1wEEe5okrI40l1rXAuBhrhWX3SD9SKLqEYcmIHgb3b4BK9EIxx tl6jqJAS5SAsV4OSQVLxeejPTAcFOgcSCz7hCHkIPqCAT38r5JnG1rkg8SoUd8lX3ibfjKL6CpEM z4HEDHh0ZKajiNjgGwjeSgQSz5ZD/VDJCpRP9znp6x9FJPqMIEJryPgKiGcA0TVFhyL/L62RvZyD mOPZ8zmI7L3WIJiMBbGEjpW/5RCHJAzKvx2Raw0xPeeA3+OAx3NYUQW74lpHdCMR+6EbkXHL4s9G 43JZ4HzokbfRCKsBVszfLIt+a7jFLwAAAP//AwBQSwMEFAAGAAgAAAAhAMdNa/HiAQAA2wMAABAA CAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFPL btswELwX6D8Iuse0XaV1jBWDwkGRQ9sYsJKcWWolE6VIgmSMuF/flRTLdNtTdZp9aHY0u4Lb105n B/RBWVPmi9k8z9BIWyvTlvlj9eVqlWchClMLbQ2W+RFDfsvfv4Ottw59VBgyojChzPcxujVjQe6x E2FGZUOVxvpORAp9y2zTKIl3Vr50aCJbzucfGb5GNDXWV24izEfG9SH+L2ltZa8vPFVHR4I5VNg5 LSLy770cDWxKQGWj0JXqkF+vKD9FsBUtBr4ENgJ4tr4O/FNxDWyEsNkLL2Qk93ixLG6AJQn47JxW UkQyln9T0ttgm5g9DBZkPQGwtAXIlh3KF6/ikc+BpSF8VYakfKDJIyJtXrReuH3gNDaJYCeFxg19 PG+EDgjsnIB7FP1it0KRYjjE9QFltD4L6hetdplnP0TA3rIyPwivhIlkXd82BgPWLkTPKxU1cVNt jAeYtqVYFXwxNBC4bOwJRg1UuFQ3TAgPDX1b/IfYRSp20DBKTeQkcJrxB+vGdk6YIw2fEBn8Mzy6 yt715/Lm4WUy2fuzivudE5K2U9ysaD/nC0hKsKNDwZpWeiI8J+Ce/Pa6n0rvmhbrU8/fhf6mnsZ/ lS+K2Zye4YhOObqE6SfivwEAAP//AwBQSwECLQAUAAYACAAAACEACSSHgoEBAACOBQAAEwAAAAAA AAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAekRq38wAAAE4C AAALAAAAAAAAAAAAAAAAALoDAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQANa5uoTQEAAF0E AAAcAAAAAAAAAAAAAAAAAN4GAAB3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhAPkAKyw/EgAAypwAABEAAAAAAAAAAAAAAAAAbQkAAHdvcmQvZG9jdW1lbnQueG1sUEsB Ai0AFAAGAAgAAAAhADDdQymoBgAApBsAABUAAAAAAAAAAAAAAAAA2xsAAHdvcmQvdGhlbWUvdGhl bWUxLnhtbFBLAQItABQABgAIAAAAIQCMfx0AsgMAAFUJAAARAAAAAAAAAAAAAAAAALYiAAB3b3Jk L3NldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQBufgutngIAAKcfAAAUAAAAAAAAAAAAAAAAAJcm AAB3b3JkL3dlYlNldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQChT7cukQkAAEhJAAAaAAAAAAAA AAAAAAAAAGcpAAB3b3JkL3N0eWxlc1dpdGhFZmZlY3RzLnhtbFBLAQItABQABgAIAAAAIQCF3sqM SgEAAHcCAAARAAAAAAAAAAAAAAAAADAzAABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAA IQD5X5t3DgkAAFdGAAAPAAAAAAAAAAAAAAAAALE1AAB3b3JkL3N0eWxlcy54bWxQSwECLQAUAAYA CAAAACEAk1byZAUCAACzBgAAEgAAAAAAAAAAAAAAAADsPgAAd29yZC9mb250VGFibGUueG1sUEsB Ai0AFAAGAAgAAAAhAMdNa/HiAQAA2wMAABAAAAAAAAAAAAAAAAAAIUEAAGRvY1Byb3BzL2FwcC54 bWxQSwUGAAAAAAwADAAJAwAAOUQAAAAA ------=_Part_1495680_18388667.1343918265813-- From amontville@tripwire.com Thu Aug 2 07:55: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 7A81411E80D3 for ; Thu, 2 Aug 2012 07:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.985 X-Spam-Level: X-Spam-Status: No, score=-3.985 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bxrsha2mZ-q7 for ; Thu, 2 Aug 2012 07:55:39 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 2C22711E80C5 for ; Thu, 2 Aug 2012 07:55:39 -0700 (PDT) Received: from mail65-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 2 Aug 2012 14:55:38 +0000 Received: from mail65-am1 (localhost [127.0.0.1]) by mail65-am1-R.bigfish.com (Postfix) with ESMTP id 133B2240583; Thu, 2 Aug 2012 14:55:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371I1447Izz1202hzz8275ch1033IL8275dhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail65-am1 (localhost.localdomain [127.0.0.1]) by mail65-am1 (MessageSwitch) id 1343919335680224_4091; Thu, 2 Aug 2012 14:55:35 +0000 (UTC) Received: from AM1EHSMHS019.bigfish.com (unknown [10.3.201.239]) by mail65-am1.bigfish.com (Postfix) with ESMTP id 9B92D340083; Thu, 2 Aug 2012 14:55:35 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by AM1EHSMHS019.bigfish.com (10.3.207.157) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 2 Aug 2012 14:55:32 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 Aug 2012 07:56:37 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Thu, 2 Aug 2012 07:55:29 -0700 From: Adam Montville To: "david.oliva@verizon.net" , "sacm@ietf.org" Thread-Topic: [sacm] Proposed SACM Charter Comments feedback Thread-Index: AQHNcLx37rinHg9fFkiTeoA/VoQW25dGnDwA Date: Thu, 2 Aug 2012 14:55:28 +0000 Message-ID: In-Reply-To: <8872209.1495682.1343918265914.JavaMail.root@vms170025> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] Proposed SACM Charter Comments feedback X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 14:55:40 -0000 David, Thanks for the feedback on this. Aside from the preferential language chan= ges, there are two important additions to the list of goals. Stated briefl= y they are: 1) demonstrate support for control frameworks, and 2) demonstra= te support for legislation (which I take to include regulation). I view these as important because we should seek to ensure we are meeting h= igher-level use cases. I would suggest that a few informational documents = be created along the way to demonstrate such support, or that a generic set= of business processes or controls be enumerated, such that the derived nee= ds of those business processes can be enumerated and addressed as appropria= te by either sacm, mile, or a combination of some other SDO efforts (wether= IETF or otherwise, to be frank). Regards, Adam From: "david.oliva@verizon.net" > Date: Thursday, August 2, 2012 7:37 AM To: "sacm@ietf.org" > Subject: [sacm] Proposed SACM Charter Comments feedback To all: Here's my two cents worth to the SACM charter. Ruben David Oliva From amontville@tripwire.com Thu Aug 2 08:40: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 0331A21F86A2 for ; Thu, 2 Aug 2012 08:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.636 X-Spam-Level: X-Spam-Status: No, score=-3.636 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eazhOXNZfwU7 for ; Thu, 2 Aug 2012 08:40:32 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1598521F8433 for ; Thu, 2 Aug 2012 08:40:30 -0700 (PDT) Received: from mail127-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 2 Aug 2012 15:40:16 +0000 Received: from mail127-va3 (localhost [127.0.0.1]) by mail127-va3-R.bigfish.com (Postfix) with ESMTP id 86954160059; Thu, 2 Aug 2012 15:40:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -40 X-BigFish: VPS-40(zz9371I1503M9f17R148cI1418I4015I14ffIzz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h946he5bhf0ah107ah) Received: from mail127-va3 (localhost.localdomain [127.0.0.1]) by mail127-va3 (MessageSwitch) id 1343922013840786_7748; Thu, 2 Aug 2012 15:40:13 +0000 (UTC) Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.248]) by mail127-va3.bigfish.com (Postfix) with ESMTP id C9593E0090; Thu, 2 Aug 2012 15:40:13 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 2 Aug 2012 15:40:12 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 Aug 2012 08:41:17 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Thu, 2 Aug 2012 08:40:10 -0700 From: Adam Montville To: Stephen Hanna , "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Thread-Topic: [sacm] Proposed SACM Charter Thread-Index: Ac1vaWiOyVMyhOX0SPq1pV9F173E/AA2J3hgACDEuwA= Date: Thu, 2 Aug 2012 15:40:09 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.16.97.136] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Subject: Re: [sacm] Proposed SACM Charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 15:40:35 -0000 From: Stephen Hanna > Date: Wednesday, August 1, 2012 5:57 PM To: kent_landfield >, "sacm@ietf.org" > Subject: Re: [sacm] Proposed SACM Charter Kent, Thanks for drafting the charter and sending it out for comments. We=92ve go= t a good start here but I have a few ideas for refinement: 1. Add =93remediation and response=94 to the first e.g. list. In the = SACM Use Cases document, use cases UC1-UC4 all include response and for goo= d reason. Automated attacks proceed quite rapidly. Automated defense must b= e able to do so also, with appropriate safeguards to ensure that remediatio= n and response don=92t cause more problems than they solve. 2. For =93i.e. specifications=94, I would say =93i.e. data formats=94= . We=92ll be creating specifications for many things, including data format= s and network protocols. I believe in this instance, you=92re talking about= data formats. Right? 3. I don=92t really understand the parenthetical comment =93i.e. oper= ations=94. I think the preceding phrase (=93curating domain concept instanc= e collections in content repositories=94) means =93storing security automat= ion content into databases=94. I don=92t mind using fancy words for that bu= t I don=92t see what =93i.e. operations=94 has to do with that. Maybe you m= ean that the security operations teams will be using that content. But I th= ink that applies to everything we=92re doing here. I'd like to point out that "curation" and "storing" are really two differen= t things. I believe curation would include storing (strictly speaking). I= believe the intent is to manage the content more than simply provide a pla= ce for store/retrieve operations. To me, the distinction is important, and= I'd like to see this effort work toward the more pragmatic case of content= management than simply store/retrieve. 4. When you say =93maintain an authoritative point of reference=94, t= hat starts to sound like IETF or IANA would be maintaining an authoritative= list of vulnerabilities and proper configurations. Of course, that isn=92t= what you mean. I think we want to enable organizations to maintain their o= wn content repositories. I suggest that you rewrite that sentence to fix th= is confusion and also change from passive voice (=93It is one thing =85=94)= to active voice. Replace that sentence with =93Defining a standards repres= entation for security content is not enough. To enable interoperable securi= ty automation, we must define standard protocols for storing, retrieving, a= nd exchanging that content.=94 5. In the numbered list of areas of focus for the WG, why do you say = =93device states=94 in item 1 and =93systems=92 state=94 in item 2? Those s= eem to be two phrases for the same thing. Also, doesn=92t 2 include 1? And = =93response=94 (including remediation and mitigation) seems to be missing f= rom this list. Do we just want to monitor our system vulnerabilities and wa= tch them get hacked? No, I think we want to be able to use standards to fix= vulnerabilities, install countermeasures and mitigations, and intervene wh= en attacks are detected. As an aside, I think we would benefit from a common glossary. This has bee= n an issue for me for a while, and I've been meaning to create some sort of= dynamic glossary the community can use, but haven't gotten around to it. = When semantics make the difference, glossaries can be of great service. Do= es anyone else in the community see a need to start and maintain a glossary= for our purpose here? Such a glossary can be based on several glossaries = that already exist RFC4949, CNSSI 4009, a variety of NIST publications, com= mon control frameworks, and so on. 6. UC2, UC4, and UC5 from the use cases document do not seem to be ad= dressed in this charter, except perhaps for the last document on =93securel= y sharing dynamic network state information=94. Maybe this omission is deli= berate. I have been saying for a while that we have too many work items on = our plate. If we added UC2, UC4, and UC5 to this charter, we=92d probably h= ave 3-4 times as many work items. So I=92m actually OK with deciding that U= C2, UC4, and UC5 aren=92t in scope for this WG. But we should make that dec= ision explicitly. Something I was going to ask about at the side meeting this evening, but wi= ll pose here instead, is whether we really mean "forensics" in the traditio= nal way (this gets back to my call for a glossary above). When I hear the = term "forensics" used in the context of information security, I think about= investigative techniques which are admissible in court. What we might mea= n here, at least initially, is "investigation." Yes, we would someday want= to get to the point where we can deal with "forensics" but that seems like= a lot of work to abstract enough for multiple jurisdictions across many le= gal systems. If we really mean "investigation," I'd opt for using that wor= d instead or "digital investigation" or something similar =96 just not some= thing that can be quite easily misconstrued as evidence gathering. Otherwise, I agree that some use cases may not be appropriate for this part= icular working group, but would be something that is done in a different IE= TF group, or perhaps another SDO entirely. I would enjoy seeing this Use C= ase document turn into something more along the lines of an overall securit= y and compliance architecture document, thus providing a framework from whi= ch other working groups within the IETF (across areas) and other SDOs can d= raw information and context. 7. One of the deliverables is =93A Standards Track document specifyin= g interfaces and communication protocols used for security automation and c= ontinuous monitoring=94. That sounds like several documents. Why have one d= ocument that specifies multiple protocols and interfaces? And which protoco= ls are these, exactly? I could imagine 20 different ones that could all fit= in this broad category. I agree with this, Steve. It does seem like multiple documents. I'm guess= ing that the intent here was to first address the specific case of continuo= usly monitoring configuration state across an enterprise, which could be a = single document, but may be better off expressed as a series of related doc= uments. I'm out of my realm of expertise as to which approach is better. As I said above, this is a good first draft. Thanks for preparing it and fo= r welcoming comments on it. We=92ve started down the path of finding the pr= oper scope for this WG. That=92s essential. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Tuesday, July 31, 2012 6:12 PM To: sacm@ietf.org Subject: [sacm] Proposed SACM Charter Hi all, Here is an initial cut at the proposed SACM Working Group charter. The int= ent of this is to be a starting point for the conversation. Comments are ex= pected, encouraged and welcomed. -------- Security Automation Continuous Monitoring (SACM) Proposed Working Group Charter Chairs: TBD TBD Security Area Directors: Stephen Farrell > Sean Turner > Security Area Advisor: Sean Turner > Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm Description of Working Group Securing information and the systems that store, process, and transmit that= information has become a challenging task for organizations of all sizes, = and we find that security practitioners spend most of their time on manual = processes relegating them to ineffectiveness. Security automation is the ke= y to escaping this rut. This working group will enable security automation = standards in support of information security processes and practices where = practical, such that security practitioners can be better utilized within t= heir organizations and we can meet the more advanced needs of the security = community (e.g. information sharing, continuous monitoring, result aggregat= ion and analysis). The initial focus of this work is toaddress enterprise a= nd SOHO use cases. The working group will achieve this by consuming and con= tinuing (with cooperation) the security automation work already performed b= y various organizations around the world. The initial work has been fruitful, and the specifications previously publi= shed are ready for expansion on the international stage. Of particular inte= rest to this working group are the security automation specifications suppo= rting asset, change, configuration, and vulnerability management. Of second= ary interest to this working group are the emerging security automation spe= cifications relating to event management and continuous monitoring. By undertaking this work, we recognize that there are multiple categories o= f problems in the security automation domain: defining expressions for part= icular domain concepts (i.e. specifications), curating domain concept insta= nce collections in content repositories (i.e. operations), and enabling int= eroperability through the development and use of interfaces and communicati= ons protocols. It is one thing to define an expression for vulnerabilities = and configuration items, but it is quite another to maintain an authoritati= ve point of reference upon which tools (and their users) can rely and suppo= rt the automated exchange of vulnerability and configuration information. This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used for the purpose of assessing, aggregating and com= paring device states against expected values,and reporting on those results= in a predefined or ad hoc manner. 2. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used to continuously monitor and report on systems=92 = state and security process effectiveness in a pre-defined or ad-hoc manner. 3. Create relationships between existing operations management standards to= enable a comprehensive view of security automation, leveraging existing wo= rk and implementations. This working group will produce the following: * An Informational document providing an overview of security automation an= d continuous monitoring to include a reference model * A Standards Track document specifying benchmark configuration representat= ion * An Informational document stating guidelines / requirements for specifyin= g checking languages * Standards Track documents specifying device state checking languages * A Standards Track document specifying an interrogative checking language * A Standards Track document specifying platform naming, matching and appli= cability * A Standards Track document specifying asset identification and reporting = information * A Standards Track document specifying interfaces and communication protoc= ols used for security automation and continuous monitoring * A Standards Track document describing the messages and network protocols = for distributing Security Automation Content * A Standards Track document describing integrating security automation and= Network Endpoint Assessment capabilities * A Standards Track document describing protocols and data formats for secu= rely sharing dynamic network state information among security systems Goals and Milestones Needs to be developed. ------- Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From david.waltermire@nist.gov Thu Aug 2 10:47:39 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8119C11E81B1 for ; Thu, 2 Aug 2012 10:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.453 X-Spam-Level: X-Spam-Status: No, score=-7.453 tagged_above=-999 required=5 tests=[AWL=1.146, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KU4t1QLU8ZtN for ; Thu, 2 Aug 2012 10:47:38 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 408A911E80D3 for ; Thu, 2 Aug 2012 10:47:38 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 Aug 2012 13:47:30 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 2 Aug 2012 13:46:36 -0400 From: "Waltermire, David A." To: "sacm@ietf.org" Date: Thu, 2 Aug 2012 13:45:08 -0400 Thread-Topic: Agenda and Remote Participation Info for the SACM Side Meeting Thread-Index: AQHNcNbCoHykhK5Tw0iaSa6duN11jQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Agenda and Remote Participation Info for the SACM Side Meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:47:39 -0000 For those in Vancouver, it looks like the SACM side meeting has been moved = to Georgia A at the same scheduled time. Dave ________________________________________ From: Waltermire, David A. Sent: Tuesday, July 31, 2012 3:15 AM To: sacm@ietf.org Subject: Agenda and Remote Participation Info for the SACM Side Meeting As a reminder, the Security Automation and Continuous Monitoring (SACM) eff= ort is going to have a Side meeting at the IETF 84 meeting in Vancouver lat= er this week. A description of the meeting, the date/time, web meeting det= ails, and the agenda for the meeting follow. SACM Side Meeting IETF 84 Security Automation and Continuous Monitoring =96 SACM (pronounced as Sack-= em) Side Meeting Chairs: David Waltermire, Kent Landfield Description: A side meeting to continue the discussions around security aut= omation and continuous monitoring working group development efforts. In thi= s meeting we will be reviewing the Use Case document and then focusing on a= draft charter for the potential working group. Here are the meeting specifics: Date: Thursday, August 2, 2012 Time: 18:30 =96 20:00 PDT Room: Plaza C Thanks to Nancy Cam-Winget for organizing the webex. See conference call an= d web meeting details below. Agenda: * Agenda Bashing * Status of work since last IETF meeting * Internet Draft Discussions to: - support the charter/use cases - other potential future drafts * Discuss draft WG Charter Current Drafts: - http://www.ietf.org/id/draft-waltermire-sacm-use-cases-01.txt - draft-wa= ltermire-sacm-use-cases-01 - Analysis of Security Automation and Continuous= Monitoring (SACM) Use Cases - http://www.ietf.org/id/draft-waltermire-content-repository-00.txt - draf= t-waltermire-content-repository-00 - Automated XML Content Data Exchange an= d Management ________________________________________ From: Nancy Cam-Winget (ncamwing) [ncamwing@cisco.com] Sent: Monday, July 30, 2012 8:05 PM To: Moriarty, Kathleen Subject: FW: (Forward to attendees) Meeting invitation: SACM BOF From: Nancy Cam-Winget > Reply-To: "ncamwing@cisco.com" > Date: Monday, July 30, 2012 5:04 PM To: "ncamwing@cisco.com" > Subject: (Forward to attendees) Meeting invitation: SACM BOF **** You can forward this email invitation to attendees **** Hello , Nancy Cam-Winget invites you to attend this online meeting. Topic: SACM BOF Date: Thursday, August 2, 2012 Time: 6:30 pm, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 205 870 492 Meeting Password: sacm ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D201187757&UID=3D0&PW= =3DNZWYyNWU2YWY3&RT=3DMiM0 2. Enter your name and email address. 3. Enter the meeting password: sacm 4. Click "Join Now". To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?ED=3D201187757&UID=3D0&PW=3DNZWYyN= WU2YWY3&ORT=3DMiM0 ---------------------------------------------------------------- ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/mc 2. On the left navigation bar, click "Support". You can contact me at: ncamwing@cisco.com 1-408-853 0532 To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://cisco.webex.com/ciscosales/j.php?ED=3D201187757&UID=3D0&ICS=3DMI&LD= =3D1&RD=3D2&ST=3D1&SHA2=3DTkz-bhelFlmrhUuPkK7v2d/0gsYehkMU1WW8szSvQnM=3D&RT= =3DMiM0 The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://cisco.webex.com/ciscosales/systemdiagnosis.php. http://www.webex.com CCP:+14085256800x205870492# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation.= From kathleen.moriarty@emc.com Thu Aug 2 14:12: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 211F111E8173 for ; Thu, 2 Aug 2012 14:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zSnqpgoKU8D for ; Thu, 2 Aug 2012 14:12:27 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3259911E8143 for ; Thu, 2 Aug 2012 14:12:26 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q72LCNXh021560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2012 17:12:25 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 2 Aug 2012 17:12:04 -0400 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q72LC4cJ002882; Thu, 2 Aug 2012 17:12:04 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Thu, 2 Aug 2012 17:12:04 -0400 From: To: , Date: Thu, 2 Aug 2012 17:12:03 -0400 Thread-Topic: [sacm] Proposed SACM Charter Comments feedback Thread-Index: Ac1wvIYfdin/HTpTTR6pPC7LK1y6zQANjqpA Message-ID: References: <8872209.1495682.1343918265914.JavaMail.root@vms170025> In-Reply-To: <8872209.1495682.1343918265914.JavaMail.root@vms170025> 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] Proposed SACM Charter Comments feedback X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:12:28 -0000 Great comments, Ruben! I agree with the goals of being able to support rep= orting requirements against frameworks and regulations, but think we should= not list specific ones in the charter. I think the goal should be to enab= le the automation of tasks like maintaining the security program with the a= bility to prioritize risk and perform remediation activities. Reporting is= essential for many organizations, but I don't think we should be specific = as to which report types or formats will be supported. =20 How do people feel about having the focus within the SACM effort where we a= re providing the capabilities and then having ancillary work that provides = the desired mapping to frameworks and regulations by the communities (or ve= ndors) that need to support those regulations and frameworks? Thanks, Kathleen ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of david.oliv= a@verizon.net [david.oliva@verizon.net] Sent: Thursday, August 02, 2012 10:37 AM To: sacm@ietf.org Subject: [sacm] Proposed SACM Charter Comments feedback To all: Here's my two cents worth to the SACM charter. Ruben David Oliva From kathleen.moriarty@emc.com Thu Aug 2 14:18: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 0FA3711E8189 for ; Thu, 2 Aug 2012 14:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8L36dm0E73p for ; Thu, 2 Aug 2012 14:18:19 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id A364811E8185 for ; Thu, 2 Aug 2012 14:18:18 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q72LIH6T014167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2012 17:18:18 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 2 Aug 2012 17:18:03 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q72LI2Qs024242; Thu, 2 Aug 2012 17:18:02 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Thu, 2 Aug 2012 17:18:02 -0400 From: To: , , Date: Thu, 2 Aug 2012 17:15:54 -0400 Thread-Topic: Proposed SACM Charter Thread-Index: Ac1vaWiOyVMyhOX0SPq1pV9F173E/AA2J3hgACx+hPc= 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] Proposed SACM Charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:18:20 -0000 +1 on Steve's comments, very good suggestions! Can these comments get into= an updated version of the charter for tonight's discussion? I also agree on not including all of the use cases in the charter. I belie= ve UC 5 is assisting with the connection to MILE work. Where we think anot= her WG is addressing a use case, maybe it would be good to call that out. = I think it would make the most sense to have that int he use case document.= ANy thoughts? Thanks, Kathleen ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Stephen Ha= nna [shanna@juniper.net] Sent: Wednesday, August 01, 2012 8:57 PM To: Kent_Landfield@McAfee.com; sacm@ietf.org Subject: Re: [sacm] Proposed SACM Charter Kent, Thanks for drafting the charter and sending it out for comments. We=92ve go= t a good start here but I have a few ideas for refinement: 1. Add =93remediation and response=94 to the first e.g. list. In the = SACM Use Cases document, use cases UC1-UC4 all include response and for goo= d reason. Automated attacks proceed quite rapidly. Automated defense must b= e able to do so also, with appropriate safeguards to ensure that remediatio= n and response don=92t cause more problems than they solve. 2. For =93i.e. specifications=94, I would say =93i.e. data formats=94= . We=92ll be creating specifications for many things, including data format= s and network protocols. I believe in this instance, you=92re talking about= data formats. Right? 3. I don=92t really understand the parenthetical comment =93i.e. oper= ations=94. I think the preceding phrase (=93curating domain concept instanc= e collections in content repositories=94) means =93storing security automat= ion content into databases=94. I don=92t mind using fancy words for that bu= t I don=92t see what =93i.e. operations=94 has to do with that. Maybe you m= ean that the security operations teams will be using that content. But I th= ink that applies to everything we=92re doing here. 4. When you say =93maintain an authoritative point of reference=94, t= hat starts to sound like IETF or IANA would be maintaining an authoritative= list of vulnerabilities and proper configurations. Of course, that isn=92t= what you mean. I think we want to enable organizations to maintain their o= wn content repositories. I suggest that you rewrite that sentence to fix th= is confusion and also change from passive voice (=93It is one thing =85=94)= to active voice. Replace that sentence with =93Defining a standards repres= entation for security content is not enough. To enable interoperable securi= ty automation, we must define standard protocols for storing, retrieving, a= nd exchanging that content.=94 5. In the numbered list of areas of focus for the WG, why do you say = =93device states=94 in item 1 and =93systems=92 state=94 in item 2? Those s= eem to be two phrases for the same thing. Also, doesn=92t 2 include 1? And = =93response=94 (including remediation and mitigation) seems to be missing f= rom this list. Do we just want to monitor our system vulnerabilities and wa= tch them get hacked? No, I think we want to be able to use standards to fix= vulnerabilities, install countermeasures and mitigations, and intervene wh= en attacks are detected. 6. UC2, UC4, and UC5 from the use cases document do not seem to be ad= dressed in this charter, except perhaps for the last document on =93securel= y sharing dynamic network state information=94. Maybe this omission is deli= berate. I have been saying for a while that we have too many work items on = our plate. If we added UC2, UC4, and UC5 to this charter, we=92d probably h= ave 3-4 times as many work items. So I=92m actually OK with deciding that U= C2, UC4, and UC5 aren=92t in scope for this WG. But we should make that dec= ision explicitly. 7. One of the deliverables is =93A Standards Track document specifyin= g interfaces and communication protocols used for security automation and c= ontinuous monitoring=94. That sounds like several documents. Why have one d= ocument that specifies multiple protocols and interfaces? And which protoco= ls are these, exactly? I could imagine 20 different ones that could all fit= in this broad category. As I said above, this is a good first draft. Thanks for preparing it and fo= r welcoming comments on it. We=92ve started down the path of finding the pr= oper scope for this WG. That=92s essential. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ken= t_Landfield@McAfee.com Sent: Tuesday, July 31, 2012 6:12 PM To: sacm@ietf.org Subject: [sacm] Proposed SACM Charter Hi all, Here is an initial cut at the proposed SACM Working Group charter. The int= ent of this is to be a starting point for the conversation. Comments are ex= pected, encouraged and welcomed. -------- Security Automation Continuous Monitoring (SACM) Proposed Working Group Charter Chairs: TBD TBD Security Area Directors: Stephen Farrell > Sean Turner > Security Area Advisor: Sean Turner > Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm Description of Working Group Securing information and the systems that store, process, and transmit that= information has become a challenging task for organizations of all sizes, = and we find that security practitioners spend most of their time on manual = processes relegating them to ineffectiveness. Security automation is the ke= y to escaping this rut. This working group will enable security automation = standards in support of information security processes and practices where = practical, such that security practitioners can be better utilized within t= heir organizations and we can meet the more advanced needs of the security = community (e.g. information sharing, continuous monitoring, result aggregat= ion and analysis). The initial focus of this work is toaddress enterprise a= nd SOHO use cases. The working group will achieve this by consuming and con= tinuing (with cooperation) the security automation work already performed b= y various organizations around the world. The initial work has been fruitful, and the specifications previously publi= shed are ready for expansion on the international stage. Of particular inte= rest to this working group are the security automation specifications suppo= rting asset, change, configuration, and vulnerability management. Of second= ary interest to this working group are the emerging security automation spe= cifications relating to event management and continuous monitoring. By undertaking this work, we recognize that there are multiple categories o= f problems in the security automation domain: defining expressions for part= icular domain concepts (i.e. specifications), curating domain concept insta= nce collections in content repositories (i.e. operations), and enabling int= eroperability through the development and use of interfaces and communicati= ons protocols. It is one thing to define an expression for vulnerabilities = and configuration items, but it is quite another to maintain an authoritati= ve point of reference upon which tools (and their users) can rely and suppo= rt the automated exchange of vulnerability and configuration information. This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used for the purpose of assessing, aggregating and com= paring device states against expected values,and reporting on those results= in a predefined or ad hoc manner. 2. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used to continuously monitor and report on systems=92 = state and security process effectiveness in a pre-defined or ad-hoc manner. 3. Create relationships between existing operations management standards to= enable a comprehensive view of security automation, leveraging existing wo= rk and implementations. This working group will produce the following: * An Informational document providing an overview of security automation an= d continuous monitoring to include a reference model * A Standards Track document specifying benchmark configuration representat= ion * An Informational document stating guidelines / requirements for specifyin= g checking languages * Standards Track documents specifying device state checking languages * A Standards Track document specifying an interrogative checking language * A Standards Track document specifying platform naming, matching and appli= cability * A Standards Track document specifying asset identification and reporting = information * A Standards Track document specifying interfaces and communication protoc= ols used for security automation and continuous monitoring * A Standards Track document describing the messages and network protocols = for distributing Security Automation Content * A Standards Track document describing integrating security automation and= Network Endpoint Assessment capabilities * A Standards Track document describing protocols and data formats for secu= rely sharing dynamic network state information among security systems Goals and Milestones Needs to be developed. ------- Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From amontville@tripwire.com Thu Aug 2 14:32: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 E4CBA11E80A2 for ; Thu, 2 Aug 2012 14:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.339 X-Spam-Level: X-Spam-Status: No, score=-5.339 tagged_above=-999 required=5 tests=[AWL=1.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bweMmTWNq5JD for ; Thu, 2 Aug 2012 14:32:08 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 436CC11E808E for ; Thu, 2 Aug 2012 14:32:08 -0700 (PDT) Received: from mail74-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Thu, 2 Aug 2012 21:32:07 +0000 Received: from mail74-va3 (localhost [127.0.0.1]) by mail74-va3-R.bigfish.com (Postfix) with ESMTP id 7305A2C03B3; Thu, 2 Aug 2012 21:32:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -2 X-BigFish: VPS-2(zz98dI9371Izz1202hzz8275bhz2dh2a8h668h839h944hd25he5bhf0ah107ah) Received: from mail74-va3 (localhost.localdomain [127.0.0.1]) by mail74-va3 (MessageSwitch) id 1343943125491896_15834; Thu, 2 Aug 2012 21:32:05 +0000 (UTC) Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.251]) by mail74-va3.bigfish.com (Postfix) with ESMTP id 74AD034006D; Thu, 2 Aug 2012 21:32:05 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 2 Aug 2012 21:32:04 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 Aug 2012 14:33:10 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Thu, 2 Aug 2012 14:32:03 -0700 From: Adam Montville To: "kathleen.moriarty@emc.com" Thread-Topic: [sacm] Proposed SACM Charter Thread-Index: AQHNcPZBp4J8JKQwbka/ZdDlTAmqtQ== Date: Thu, 2 Aug 2012 21:32:02 +0000 Message-ID: <4DEB69FD-A9A2-4073-9A06-BAD5EFAB88E4@tripwire.com> References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Cc: "shanna@juniper.net" , "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Subject: Re: [sacm] Proposed SACM Charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:32:09 -0000 Sent from my iPhone On Aug 2, 2012, at 2:18 PM, "kathleen.moriarty@emc.com" wrote: > Where we think another WG is addressing a use case, maybe it would be goo= d to call that out. I think it would make the most sense to have that int = he use case document. ANy thoughts? Excellent suggestion.= From Kent_Landfield@mcafee.com Thu Aug 2 14:35:45 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC6A21E8097 for ; Thu, 2 Aug 2012 14:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.342 X-Spam-Level: X-Spam-Status: No, score=-6.342 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1OpzvU2cIWE for ; Thu, 2 Aug 2012 14:35:43 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 744F521E8088 for ; Thu, 2 Aug 2012 14:35:43 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 7d76_02ec_3710d811_5dcd_4b1d_adc8_15ba9efc8c00; Thu, 02 Aug 2012 16:35:09 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Thu, 2 Aug 2012 16:35:09 -0500 From: To: , , Date: Thu, 2 Aug 2012 16:36:08 -0500 Thread-Topic: Proposed SACM Charter Thread-Index: Ac1w9rB10q8G0VTOQ62K3KzYhiw5dw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC40409238D1Dkentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] Proposed SACM Charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:35:45 -0000 --_000_CC40409238D1Dkentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I will try to get them in but I have a question or two on them so not all m= ay make it in for the Side Meeting. I will definitely had clarifying questi= ons of Steve. ;-) Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Kathleen Moriarty > Date: Thursday, August 2, 2012 2:15 PM To: "shanna@juniper.net" >, Kent Landfield >, "sacm@ietf.org" > Subject: RE: Proposed SACM Charter +1 on Steve's comments, very good suggestions! Can these comments get into= an updated version of the charter for tonight's discussion? I also agree on not including all of the use cases in the charter. I belie= ve UC 5 is assisting with the connection to MILE work. Where we think anot= her WG is addressing a use case, maybe it would be good to call that out. = I think it would make the most sense to have that int he use case document.= ANy thoughts? Thanks, Kathleen ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@iet= f.org] On Behalf Of Stephen Hanna [shanna@jun= iper.net] Sent: Wednesday, August 01, 2012 8:57 PM To: Kent_Landfield@McAfee.com; sacm@ietf.= org Subject: Re: [sacm] Proposed SACM Charter Kent, Thanks for drafting the charter and sending it out for comments. We=92ve go= t a good start here but I have a few ideas for refinement: 1. Add =93remediation and response=94 to the first e.g. list. In the = SACM Use Cases document, use cases UC1-UC4 all include response and for goo= d reason. Automated attacks proceed quite rapidly. Automated defense must b= e able to do so also, with appropriate safeguards to ensure that remediatio= n and response don=92t cause more problems than they solve. 2. For =93i.e. specifications=94, I would say =93i.e. data formats=94= . We=92ll be creating specifications for many things, including data format= s and network protocols. I believe in this instance, you=92re talking about= data formats. Right? 3. I don=92t really understand the parenthetical comment =93i.e. oper= ations=94. I think the preceding phrase (=93curating domain concept instanc= e collections in content repositories=94) means =93storing security automat= ion content into databases=94. I don=92t mind using fancy words for that bu= t I don=92t see what =93i.e. operations=94 has to do with that. Maybe you m= ean that the security operations teams will be using that content. But I th= ink that applies to everything we=92re doing here. 4. When you say =93maintain an authoritative point of reference=94, t= hat starts to sound like IETF or IANA would be maintaining an authoritative= list of vulnerabilities and proper configurations. Of course, that isn=92t= what you mean. I think we want to enable organizations to maintain their o= wn content repositories. I suggest that you rewrite that sentence to fix th= is confusion and also change from passive voice (=93It is one thing =85=94)= to active voice. Replace that sentence with =93Defining a standards repres= entation for security content is not enough. To enable interoperable securi= ty automation, we must define standard protocols for storing, retrieving, a= nd exchanging that content.=94 5. In the numbered list of areas of focus for the WG, why do you say = =93device states=94 in item 1 and =93systems=92 state=94 in item 2? Those s= eem to be two phrases for the same thing. Also, doesn=92t 2 include 1? And = =93response=94 (including remediation and mitigation) seems to be missing f= rom this list. Do we just want to monitor our system vulnerabilities and wa= tch them get hacked? No, I think we want to be able to use standards to fix= vulnerabilities, install countermeasures and mitigations, and intervene wh= en attacks are detected. 6. UC2, UC4, and UC5 from the use cases document do not seem to be ad= dressed in this charter, except perhaps for the last document on =93securel= y sharing dynamic network state information=94. Maybe this omission is deli= berate. I have been saying for a while that we have too many work items on = our plate. If we added UC2, UC4, and UC5 to this charter, we=92d probably h= ave 3-4 times as many work items. So I=92m actually OK with deciding that U= C2, UC4, and UC5 aren=92t in scope for this WG. But we should make that dec= ision explicitly. 7. One of the deliverables is =93A Standards Track document specifyin= g interfaces and communication protocols used for security automation and c= ontinuous monitoring=94. That sounds like several documents. Why have one d= ocument that specifies multiple protocols and interfaces? And which protoco= ls are these, exactly? I could imagine 20 different ones that could all fit= in this broad category. As I said above, this is a good first draft. Thanks for preparing it and fo= r welcoming comments on it. We=92ve started down the path of finding the pr= oper scope for this WG. That=92s essential. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Tuesday, July 31, 2012 6:12 PM To: sacm@ietf.org Subject: [sacm] Proposed SACM Charter Hi all, Here is an initial cut at the proposed SACM Working Group charter. The int= ent of this is to be a starting point for the conversation. Comments are ex= pected, encouraged and welcomed. -------- Security Automation Continuous Monitoring (SACM) Proposed Working Group Charter Chairs: TBD TBD Security Area Directors: Stephen Farrell > Sean Turner > Security Area Advisor: Sean Turner > Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm Description of Working Group Securing information and the systems that store, process, and transmit that= information has become a challenging task for organizations of all sizes, = and we find that security practitioners spend most of their time on manual = processes relegating them to ineffectiveness. Security automation is the ke= y to escaping this rut. This working group will enable security automation = standards in support of information security processes and practices where = practical, such that security practitioners can be better utilized within t= heir organizations and we can meet the more advanced needs of the security = community (e.g. information sharing, continuous monitoring, result aggregat= ion and analysis). The initial focus of this work is toaddress enterprise a= nd SOHO use cases. The working group will achieve this by consuming and con= tinuing (with cooperation) the security automation work already performed b= y various organizations around the world. The initial work has been fruitful, and the specifications previously publi= shed are ready for expansion on the international stage. Of particular inte= rest to this working group are the security automation specifications suppo= rting asset, change, configuration, and vulnerability management. Of second= ary interest to this working group are the emerging security automation spe= cifications relating to event management and continuous monitoring. By undertaking this work, we recognize that there are multiple categories o= f problems in the security automation domain: defining expressions for part= icular domain concepts (i.e. specifications), curating domain concept insta= nce collections in content repositories (i.e. operations), and enabling int= eroperability through the development and use of interfaces and communicati= ons protocols. It is one thing to define an expression for vulnerabilities = and configuration items, but it is quite another to maintain an authoritati= ve point of reference upon which tools (and their users) can rely and suppo= rt the automated exchange of vulnerability and configuration information. This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used for the purpose of assessing, aggregating and com= paring device states against expected values,and reporting on those results= in a predefined or ad hoc manner. 2. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used to continuously monitor and report on systems=92 = state and security process effectiveness in a pre-defined or ad-hoc manner. 3. Create relationships between existing operations management standards to= enable a comprehensive view of security automation, leveraging existing wo= rk and implementations. This working group will produce the following: * An Informational document providing an overview of security automation an= d continuous monitoring to include a reference model * A Standards Track document specifying benchmark configuration representat= ion * An Informational document stating guidelines / requirements for specifyin= g checking languages * Standards Track documents specifying device state checking languages * A Standards Track document specifying an interrogative checking language * A Standards Track document specifying platform naming, matching and appli= cability * A Standards Track document specifying asset identification and reporting = information * A Standards Track document specifying interfaces and communication protoc= ols used for security automation and continuous monitoring * A Standards Track document describing the messages and network protocols = for distributing Security Automation Content * A Standards Track document describing integrating security automation and= Network Endpoint Assessment capabilities * A Standards Track document describing protocols and data formats for secu= rely sharing dynamic network state information among security systems Goals and Milestones Needs to be developed. ------- Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com --_000_CC40409238D1Dkentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I will try = to get them in but I have a question or two on them so not all may make it = in for the Side Meeting. I will definitely had clarifying questions of Stev= e. ;-)

Thanks.

Kent Landfield= <= br>
McAfe= e | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcaf= ee.com

From: Kathleen Moriarty <kathleen.moriarty@emc.com>
Date: Thursday, August 2, 2012 2:15 PM
To: "shanna@juniper.net" <shanna@juniper.net>, Kent Landfield <Kent_Landfield@McAfee.com>, "sacm@ietf.org" <sacm@ietf.org>
Subject:= RE: Proposed SACM Charter

+1 on Steve's comm= ents, very good suggestions!  Can these comments get into an upda= ted version of the charter for tonight's discussion?

I also agree on not including all of the use cases in the charter. =  I believe UC 5 is assisting with the connection to MILE work. &n= bsp;Where we think another WG is addressing a use case, maybe it would be g= ood to call that out.  I think it would make the most sense to ha= ve that int he use case document.  ANy thoughts?

Thanks,
Kathleen
_____________________________= ___________
Sent: Wednesday, August 01, 2012 8:5= 7 PM
To: Kent_Landfi= eld@McAfee.com; sacm@ietf.org
Subject: Re: [sacm] Proposed SACM Charter

Ke= nt,

Thanks for drafting the charter and sending it= out for comments. We=92ve got a good start here but I have a few ideas for= refinement:


1.   &n= bsp;   Add =93remediation and response=94 to the first e.g. list.= In the SACM Use Cases document, use cases UC1-UC4 all include response and= for good reason. Automated attacks proceed quite rapidly. Automated defens= e must be able to do so also, with appropriate safeguards to ensure that re= mediation and response don=92t cause more problems than they solve.


2.       For= =93i.e. specifications=94, I would say =93i.e. data formats=94. We=92ll be= creating specifications for many things, including data formats and networ= k protocols. I believe in this instance, you=92re talking about data format= s. Right?



3. &n= bsp;     I don=92t really understand the parenthetical = comment =93i.e. operations=94. I think the preceding phrase (=93curating do= main concept instance collections in content repositories=94) means =93stor= ing security automation content into databases=94. I don=92t mind using fan= cy words for that but I don=92t see what =93i.e. operations=94 has to do wi= th that. Maybe you mean that the security operations teams will be using th= at content. But I think that applies to everything we=92re doing here.


4.       = When you say =93maintain an authoritative point of reference=94, that start= s to sound like IETF or IANA would be maintaining an authoritative list of = vulnerabilities and proper configurations. Of course, that isn=92t what you= mean. I think we want to enable organizations to maintain their own conten= t repositories. I suggest that you rewrite that sentence to fix this confus= ion and also change from passive voice (=93It is one thing =85=94) to activ= e voice. Replace that sentence with =93Defining a standards representation = for security content is not enough. To enable interoperable security automa= tion, we must define standard protocols for storing, retrieving, and exchan= ging that content.=94


5.  = ;     In the numbered list of areas of focus for the WG= , why do you say =93device states=94 in item 1 and =93systems=92 state=94 i= n item 2? Those seem to be two phrases for the same thing. Also, doesn=92t = 2 include 1? And =93response=94 (including remediation and mitigation) seem= s to be missing from this list. Do we just want to monitor our system vulne= rabilities and watch them get hacked? No, I think we want to be able to use= standards to fix vulnerabilities, install countermeasures and mitigations,= and intervene when attacks are detected.



6.       UC2, UC4, and = UC5 from the use cases document do not seem to be addressed in this charter= , except perhaps for the last document on =93securely sharing dynamic netwo= rk state information=94. Maybe this omission is deliberate. I have been say= ing for a while that we have too many work items on our plate. If we added = UC2, UC4, and UC5 to this charter, we=92d probably have 3-4 times as many w= ork items. So I=92m actually OK with deciding that UC2, UC4, and UC5 aren= =92t in scope for this WG. But we should make that decision explicitly.


7.      = One of the deliverables is =93A Standards Track document specifying interf= aces and communication protocols used for security automation and continuou= s monitoring=94. That sounds like several documents. Why have one document = that specifies multiple protocols and interfaces? And which protocols are t= hese, exactly? I could imagine 20 different ones that could all fit in this= broad category.


As I said above, t= his is a good first draft. Thanks for preparing it and for welcoming commen= ts on it. We=92ve started down the path of finding the proper scope for thi= s WG. That=92s essential.

Thanks,

Steve

Sent: Tuesday= , July 31, 2012 6:12 PM
Subject: [sacm] Proposed SACM Charter
Hi all,

Here is an initial cut at the = proposed SACM Working Group charter.  The intent of this is to be= a starting point for the conversation. Comments are expected, encouraged a= nd welcomed.

--------
Security Automatio= n Continuous Monitoring (SACM)

Proposed Working Gr= oup Charter

Chairs:
TBD
TBD

Security Area Directors:

Security Area Advisor:

Mailing Lists:
&nb= sp;    General Discussion: = sacm@ietf.org<mailto:sacm@ietf.org<= /a>>
     Archive:    &= nbsp;    http://www.ietf.org/mail-archive/web/sacm

D= escription of Working Group

Securing information a= nd the systems that store, process, and transmit that information has becom= e a challenging task for organizations of all sizes, and we find that secur= ity practitioners spend most of their time on manual processes relegating t= hem to ineffectiveness. Security automation is the key to escaping this rut= . This working group will enable security automation standards in support o= f information security processes and practices where practical, such that s= ecurity practitioners can be better utilized within their organizations and= we can meet the more advanced needs of the security community (e.g. inform= ation sharing, continuous monitoring, result aggregation and analysis). The= initial focus of this work is toaddress enterprise and SOHO use cases. The= working group will achieve this by consuming and continuing (with cooperat= ion) the security automation work already performed by various organization= s around the world.

The initial work has been frui= tful, and the specifications previously published are ready for expansion o= n the international stage. Of particular interest to this working group are= the security automation specifications supporting asset, change, configura= tion, and vulnerability management. Of secondary interest to this working g= roup are the emerging security automation specifications relating to event = management and continuous monitoring.

By undertaki= ng this work, we recognize that there are multiple categories of problems i= n the security automation domain: defining expressions for particular domai= n concepts (i.e. specifications), curating domain concept instance collecti= ons in content repositories (i.e. operations), and enabling interoperabilit= y through the development and use of interfaces and communications protocol= s. It is one thing to define an expression for vulnerabilities and configur= ation items, but it is quite another to maintain an authoritative point of = reference upon which tools (and their users) can rely and support the autom= ated exchange of vulnerability and configuration information.
This working group will provide solutions to these categories o= f problems and the main areas of focus for this working group are described= as follows:

1. Define, either by normative refere= nce, adoption, or creation, a set of standards that can be used for the pur= pose of assessing, aggregating and comparing device states against expected= values,and reporting on those results in a predefined or ad hoc manner.

2. Define, either by normative reference, adoption, = or creation, a set of standards that can be used to continuously monitor an= d report on systems=92 state and security process effectiveness in a pre-de= fined or ad-hoc manner.

3. Create relationships be= tween existing operations management standards to enable a comprehensive vi= ew of security automation, leveraging existing work and implementations.

This working group will produce the following:
=

* An Informational document providing an overview of se= curity automation and continuous monitoring to include a reference model
* A Standards Track document specifying benchmark configuration rep= resentation
* An Informational document stating guidelines / requ= irements for specifying checking languages
* Standards Track docu= ments specifying device state checking languages
* A Standards Tr= ack document specifying an interrogative checking language
* A St= andards Track document specifying platform naming, matching and applicabili= ty
* A Standards Track document specifying asset identification a= nd reporting information
* A Standards Track document specifying = interfaces and communication protocols used for security automation and con= tinuous monitoring
* A Standards Track document describing the me= ssages and network protocols for distributing Security Automation Content
* A Standards Track document describing integrating security autom= ation and Network Endpoint Assessment capabilities
* A Standards = Track document describing protocols and data formats for securely sharing d= ynamic network state information among security systems

Goals and Milestones

Needs to be developed.<= /div>

-------

Kent Landfield

McAfee | An Intel Company
Direct: +1.9= 72.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee= .com<http://www.mcafee.com/>

 --_000_CC40409238D1Dkentlandfieldmcafeecom_-- From amontville@tripwire.com Thu Aug 2 14:36: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 43D3821E8095 for ; Thu, 2 Aug 2012 14:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.954 X-Spam-Level: X-Spam-Status: No, score=-3.954 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esSGyhDxnnm8 for ; Thu, 2 Aug 2012 14:36:18 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id A7ACE21E803A for ; Thu, 2 Aug 2012 14:36:18 -0700 (PDT) Received: from mail107-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 2 Aug 2012 21:36:17 +0000 Received: from mail107-va3 (localhost [127.0.0.1]) by mail107-va3-R.bigfish.com (Postfix) with ESMTP id 8C82838043A; Thu, 2 Aug 2012 21:36:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -2 X-BigFish: VPS-2(zz98dI9371Izz1202hzz8275bhz2dh2a8h668h839h944hd25he5bhf0ah107ah) Received: from mail107-va3 (localhost.localdomain [127.0.0.1]) by mail107-va3 (MessageSwitch) id 1343943375244378_10088; Thu, 2 Aug 2012 21:36:15 +0000 (UTC) Received: from VA3EHSMHS015.bigfish.com (unknown [10.7.14.253]) by mail107-va3.bigfish.com (Postfix) with ESMTP id 361AC4E0143; Thu, 2 Aug 2012 21:36:15 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by VA3EHSMHS015.bigfish.com (10.7.99.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 2 Aug 2012 21:36:14 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 Aug 2012 14:37:19 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Thu, 2 Aug 2012 14:36:12 -0700 From: Adam Montville To: "kathleen.moriarty@emc.com" Thread-Topic: [sacm] Proposed SACM Charter Comments feedback Thread-Index: AQHNcLx37rinHg9fFkiTeoA/VoQW25dHesyA//+RZ1U= Date: Thu, 2 Aug 2012 21:36:12 +0000 Message-ID: References: <8872209.1495682.1343918265914.JavaMail.root@vms170025>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Cc: "david.oliva@verizon.net" , "sacm@ietf.org" Subject: Re: [sacm] Proposed SACM Charter Comments feedback X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:36:19 -0000 On Aug 2, 2012, at 2:12 PM, "kathleen.moriarty@emc.com" wrote: > How do people feel about having the focus within the SACM effort where we= are providing the capabilities and then having ancillary work that provide= s the desired mapping to frameworks and regulations by the communities (or = vendors) that need to support those regulations and frameworks? Again, this is good guidance. Would this ancillary work be simply "out the= re" or under the guise of informational documentation in a WG?= From shanna@juniper.net Thu Aug 2 14:43:59 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 0B7C011E8087 for ; Thu, 2 Aug 2012 14:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.663 X-Spam-Level: X-Spam-Status: No, score=-106.663 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RQTpzefweQc for ; Thu, 2 Aug 2012 14:43:58 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 6312111E80EA for ; Thu, 2 Aug 2012 14:43:56 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUBr0m833cC500bOrGxQP7fY75vu99nAn@postini.com; Thu, 02 Aug 2012 14:43:58 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 2 Aug 2012 14:42:26 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 2 Aug 2012 17:42:25 -0400 From: Stephen Hanna To: Adam Montville , "kathleen.moriarty@emc.com" Date: Thu, 2 Aug 2012 17:42:24 -0400 Thread-Topic: [sacm] Proposed SACM Charter Thread-Index: AQHNcPZBp4J8JKQwbka/ZdDlTAmqtZdHDXfw Message-ID: References: , , <4DEB69FD-A9A2-4073-9A06-BAD5EFAB88E4@tripwire.com> In-Reply-To: <4DEB69FD-A9A2-4073-9A06-BAD5EFAB88E4@tripwire.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 Cc: "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Subject: Re: [sacm] Proposed SACM Charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:43:59 -0000 +1 Steve > -----Original Message----- > From: Adam Montville [mailto:amontville@tripwire.com] > Sent: Thursday, August 02, 2012 5:32 PM > To: kathleen.moriarty@emc.com > Cc: Stephen Hanna; Kent_Landfield@McAfee.com; sacm@ietf.org > Subject: Re: [sacm] Proposed SACM Charter >=20 >=20 >=20 > Sent from my iPhone >=20 > On Aug 2, 2012, at 2:18 PM, "kathleen.moriarty@emc.com" > wrote: >=20 > > Where we think another WG is addressing a use case, maybe it would be > good to call that out. I think it would make the most sense to have > that int he use case document. ANy thoughts? >=20 > Excellent suggestion. From david.waltermire@nist.gov Thu Aug 2 14:49: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 2475021E8094 for ; Thu, 2 Aug 2012 14:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHLz7ymtUGSH for ; Thu, 2 Aug 2012 14:49:02 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 474B511E8117 for ; Thu, 2 Aug 2012 14:49:01 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 Aug 2012 17:48:53 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 2 Aug 2012 17:48:59 -0400 From: "Waltermire, David A." To: Adam Montville , "kathleen.moriarty@emc.com" Date: Thu, 2 Aug 2012 17:47:57 -0400 Thread-Topic: [sacm] Proposed SACM Charter Thread-Index: AQHNcPZBp4J8JKQwbka/ZdDlTAmqtZdHCycq Message-ID: References: , , , <4DEB69FD-A9A2-4073-9A06-BAD5EFAB88E4@tripwire.com> In-Reply-To: <4DEB69FD-A9A2-4073-9A06-BAD5EFAB88E4@tripwire.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "shanna@juniper.net" , "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Subject: Re: [sacm] Proposed SACM Charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:49:03 -0000 +1. Couldn't agree more. This helps to draw together how efforts in other working groups relate in the context of SACM use cases. In my view this document is important in organizing thinking relative to potential work for SACM based on the other efforts in the IETF and other standards organizations. In the long run, I would hope that we could adopt the draft into the working group and use it to capture ongoing WG consensus relative to existing and emerging use cases. Dave ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Adam Montville [amontville@tripwire.com] Sent: Thursday, August 02, 2012 11:32 PM To: kathleen.moriarty@emc.com Cc: shanna@juniper.net; Kent_Landfield@McAfee.com; sacm@ietf.org Subject: Re: [sacm] Proposed SACM Charter Sent from my iPhone On Aug 2, 2012, at 2:18 PM, "kathleen.moriarty@emc.com" wrote: > Where we think another WG is addressing a use case, maybe it would be good to call that out. I think it would make the most sense to have that int he use case document. ANy thoughts? Excellent suggestion. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From shanna@juniper.net Thu Aug 2 14:49: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 72B0021E80A5 for ; Thu, 2 Aug 2012 14:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.357 X-Spam-Level: X-Spam-Status: No, score=-106.357 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GalLpX3L-O0P for ; Thu, 2 Aug 2012 14:48:58 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5EE11E8111 for ; Thu, 2 Aug 2012 14:48:54 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUBr1xrL3SO4qMdpmBQvrsHVUWs7hjl69@postini.com; Thu, 02 Aug 2012 14:48:57 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 2 Aug 2012 14:47:31 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 2 Aug 2012 17:47:30 -0400 From: Stephen Hanna To: "Kent_Landfield@mcafee.com" , "kathleen.moriarty@emc.com" , "sacm@ietf.org" Date: Thu, 2 Aug 2012 17:47:28 -0400 Thread-Topic: Proposed SACM Charter Thread-Index: Ac1w9rB10q8G0VTOQ62K3KzYhiw5dwAAD3xw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AC6674AB7BC78549BB231821ABF7A9AEB833C927A9EMBX01WFjnprn_" MIME-Version: 1.0 Subject: Re: [sacm] Proposed SACM Charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:49:06 -0000 --_000_AC6674AB7BC78549BB231821ABF7A9AEB833C927A9EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kent, I don't feel that my suggested changes need to get into the charter before = the meeting. In fact, I'd rather not see the charter get changed before the= meeting. We've had lots of good questions and suggestions from lots of peo= ple in the last day or so on the list. Let's keep gathering comments and di= scussing them on the list and at the meeting. When/if the charter editors j= udge that there's rough consensus on a change, then it should go in the cha= rter. If you believe that there's already rough consensus on some suggestions, I = suggest putting those on a slide at the SACM meeting and asking if people a= gree with them. If all those in the room agree, that's a good sign that the= re's consensus (to be confirmed on the list, of course). And if it sparks d= iscussion, the suggestions may be refined and improved. But I'd go for high= lighting key suggestions on slides for discussion instead of making edits t= o the charter before the meeting. Please ask your clarifying questions of me on the list or (if they'd be bet= ter asked F2F) let's get together here in Vancouver to discuss them. I can = be free at any time today or tonight (although I expect we'd both like to g= o to saag and sacm!). Thanks, Steve From: Kent_Landfield@mcafee.com [mailto:Kent_Landfield@mcafee.com] Sent: Thursday, August 02, 2012 5:36 PM To: kathleen.moriarty@emc.com; Stephen Hanna; sacm@ietf.org Subject: Re: Proposed SACM Charter I will try to get them in but I have a question or two on them so not all m= ay make it in for the Side Meeting. I will definitely had clarifying questi= ons of Steve. ;-) Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Kathleen Moriarty > Date: Thursday, August 2, 2012 2:15 PM To: "shanna@juniper.net" >, Kent Landfield >, "sacm@ietf.org" > Subject: RE: Proposed SACM Charter +1 on Steve's comments, very good suggestions! Can these comments get into= an updated version of the charter for tonight's discussion? I also agree on not including all of the use cases in the charter. I belie= ve UC 5 is assisting with the connection to MILE work. Where we think anot= her WG is addressing a use case, maybe it would be good to call that out. = I think it would make the most sense to have that int he use case document.= ANy thoughts? Thanks, Kathleen ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@iet= f.org] On Behalf Of Stephen Hanna [shanna@jun= iper.net] Sent: Wednesday, August 01, 2012 8:57 PM To: Kent_Landfield@McAfee.com; sacm@ietf.= org Subject: Re: [sacm] Proposed SACM Charter Kent, Thanks for drafting the charter and sending it out for comments. We've got = a good start here but I have a few ideas for refinement: 1. Add "remediation and response" to the first e.g. list. In the SACM= Use Cases document, use cases UC1-UC4 all include response and for good re= ason. Automated attacks proceed quite rapidly. Automated defense must be ab= le to do so also, with appropriate safeguards to ensure that remediation an= d response don't cause more problems than they solve. 2. For "i.e. specifications", I would say "i.e. data formats". We'll = be creating specifications for many things, including data formats and netw= ork protocols. I believe in this instance, you're talking about data format= s. Right? 3. I don't really understand the parenthetical comment "i.e. operatio= ns". I think the preceding phrase ("curating domain concept instance collec= tions in content repositories") means "storing security automation content = into databases". I don't mind using fancy words for that but I don't see wh= at "i.e. operations" has to do with that. Maybe you mean that the security = operations teams will be using that content. But I think that applies to ev= erything we're doing here. 4. When you say "maintain an authoritative point of reference", that = starts to sound like IETF or IANA would be maintaining an authoritative lis= t of vulnerabilities and proper configurations. Of course, that isn't what = you mean. I think we want to enable organizations to maintain their own con= tent repositories. I suggest that you rewrite that sentence to fix this con= fusion and also change from passive voice ("It is one thing ...") to active= voice. Replace that sentence with "Defining a standards representation for= security content is not enough. To enable interoperable security automatio= n, we must define standard protocols for storing, retrieving, and exchangin= g that content." 5. In the numbered list of areas of focus for the WG, why do you say = "device states" in item 1 and "systems' state" in item 2? Those seem to be = two phrases for the same thing. Also, doesn't 2 include 1? And "response" (= including remediation and mitigation) seems to be missing from this list. D= o we just want to monitor our system vulnerabilities and watch them get hac= ked? No, I think we want to be able to use standards to fix vulnerabilities= , install countermeasures and mitigations, and intervene when attacks are d= etected. 6. UC2, UC4, and UC5 from the use cases document do not seem to be ad= dressed in this charter, except perhaps for the last document on "securely = sharing dynamic network state information". Maybe this omission is delibera= te. I have been saying for a while that we have too many work items on our = plate. If we added UC2, UC4, and UC5 to this charter, we'd probably have 3-= 4 times as many work items. So I'm actually OK with deciding that UC2, UC4,= and UC5 aren't in scope for this WG. But we should make that decision expl= icitly. 7. One of the deliverables is "A Standards Track document specifying = interfaces and communication protocols used for security automation and con= tinuous monitoring". That sounds like several documents. Why have one docum= ent that specifies multiple protocols and interfaces? And which protocols a= re these, exactly? I could imagine 20 different ones that could all fit in = this broad category. As I said above, this is a good first draft. Thanks for preparing it and fo= r welcoming comments on it. We've started down the path of finding the prop= er scope for this WG. That's essential. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Tuesday, July 31, 2012 6:12 PM To: sacm@ietf.org Subject: [sacm] Proposed SACM Charter Hi all, Here is an initial cut at the proposed SACM Working Group charter. The int= ent of this is to be a starting point for the conversation. Comments are ex= pected, encouraged and welcomed. -------- Security Automation Continuous Monitoring (SACM) Proposed Working Group Charter Chairs: TBD TBD Security Area Directors: Stephen Farrell > Sean Turner > Security Area Advisor: Sean Turner > Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm Description of Working Group Securing information and the systems that store, process, and transmit that= information has become a challenging task for organizations of all sizes, = and we find that security practitioners spend most of their time on manual = processes relegating them to ineffectiveness. Security automation is the ke= y to escaping this rut. This working group will enable security automation = standards in support of information security processes and practices where = practical, such that security practitioners can be better utilized within t= heir organizations and we can meet the more advanced needs of the security = community (e.g. information sharing, continuous monitoring, result aggregat= ion and analysis). The initial focus of this work is toaddress enterprise a= nd SOHO use cases. The working group will achieve this by consuming and con= tinuing (with cooperation) the security automation work already performed b= y various organizations around the world. The initial work has been fruitful, and the specifications previously publi= shed are ready for expansion on the international stage. Of particular inte= rest to this working group are the security automation specifications suppo= rting asset, change, configuration, and vulnerability management. Of second= ary interest to this working group are the emerging security automation spe= cifications relating to event management and continuous monitoring. By undertaking this work, we recognize that there are multiple categories o= f problems in the security automation domain: defining expressions for part= icular domain concepts (i.e. specifications), curating domain concept insta= nce collections in content repositories (i.e. operations), and enabling int= eroperability through the development and use of interfaces and communicati= ons protocols. It is one thing to define an expression for vulnerabilities = and configuration items, but it is quite another to maintain an authoritati= ve point of reference upon which tools (and their users) can rely and suppo= rt the automated exchange of vulnerability and configuration information. This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used for the purpose of assessing, aggregating and com= paring device states against expected values,and reporting on those results= in a predefined or ad hoc manner. 2. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used to continuously monitor and report on systems' st= ate and security process effectiveness in a pre-defined or ad-hoc manner. 3. Create relationships between existing operations management standards to= enable a comprehensive view of security automation, leveraging existing wo= rk and implementations. This working group will produce the following: * An Informational document providing an overview of security automation an= d continuous monitoring to include a reference model * A Standards Track document specifying benchmark configuration representat= ion * An Informational document stating guidelines / requirements for specifyin= g checking languages * Standards Track documents specifying device state checking languages * A Standards Track document specifying an interrogative checking language * A Standards Track document specifying platform naming, matching and appli= cability * A Standards Track document specifying asset identification and reporting = information * A Standards Track document specifying interfaces and communication protoc= ols used for security automation and continuous monitoring * A Standards Track document describing the messages and network protocols = for distributing Security Automation Content * A Standards Track document describing integrating security automation and= Network Endpoint Assessment capabilities * A Standards Track document describing protocols and data formats for secu= rely sharing dynamic network state information among security systems Goals and Milestones Needs to be developed. ------- Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com --_000_AC6674AB7BC78549BB231821ABF7A9AEB833C927A9EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Kent,

 

<= p class=3DMsoNormal>I don’t feel that my suggested changes nee= d to get into the charter before the meeting. In fact, I’d rather not= see the charter get changed before the meeting. We’ve had lots of go= od questions and suggestions from lots of people in the last day or so on t= he list. Let’s keep gathering comments and discussing them on the lis= t and at the meeting. When/if the charter editors judge that there’s = rough consensus on a change, then it should go in the charter.

 

If you believe that there’s already rough consens= us on some suggestions, I suggest putting those on a slide at the SACM meet= ing and asking if people agree with them. If all those in the room agree, t= hat’s a good sign that there’s consensus (to be confirmed on th= e list, of course). And if it sparks discussion, the suggestions may be ref= ined and improved. But I’d go for highlighting key suggestions on sli= des for discussion instead of making edits to the charter before the meetin= g.

 

Please ask your clarifying questions of me= on the list or (if they’d be better asked F2F) let’s get toget= her here in Vancouver to discuss them. I can be free at any time today or t= onight (although I expect we’d both like to go to saag and sacm!).

 

=

Thanks,

 

Steve

 

<= div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4= .0pt'>

From: Kent_Landfield@mcafee.com [mai= lto:Kent_Landfield@mcafee.com]
Sent: Thursday, August 02, 2012 5= :36 PM
To: kathleen.moriarty@emc.com; Stephen Hanna; sacm@ietf.or= g
Subject: Re: Proposed SACM Charter

<= /div>

 

I will try to get them in but I have a = question or two on them so not all may make it in for the Side Meeting. I w= ill definitely had clarifying questions of Steve. ;-)

=

 

Th= anks.

 

Kent Landfield

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

=

 

= From: Kathleen Moriarty <kathleen.moriarty@emc.com>
Date: Thursday, A= ugust 2, 2012 2:15 PM
To: "shanna@juniper.net" <shanna@juniper.net>, Kent Landfield <Kent_Landfield@McAfee.com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: RE: Proposed SACM Charter<= /o:p>

 

+1 on Steve's comments, very go= od suggestions!  Can these comments get into an updated version o= f the charter for tonight's discussion?

 

<= /div>

I also agree on = not including all of the use cases in the charter.  I believe UC = 5 is assisting with the connection to MILE work.  Where we think = another WG is addressing a use case, maybe it would be good to call that ou= t.  I think it would make the most sense to have that int he use = case document.  ANy thoughts?

 

<= /div>

Thanks,

Ka= thleen

________________________________________

=

From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Stephen = Hanna [shanna@juniper.net]

= Sent: Wednesday, August 01, 2012 8:57 PM

Subject: Re: [sacm] Proposed SACM Charter=

 

Kent,

 

Thanks for drafting the charte= r and sending it out for comments. We’ve got a good start here but I = have a few ideas for refinement:

 

=

 

1. =       Add “remediation and response” t= o the first e.g. list. In the SACM Use Cases document, use cases UC1-UC4 al= l include response and for good reason. Automated attacks proceed quite rap= idly. Automated defense must be able to do so also, with appropriate safegu= ards to ensure that remediation and response don’t cause more problem= s than they solve.

 

 

2.   &nbs= p;   For “i.e. specifications”, I would say “i.= e. data formats”. We’ll be creating specifications for many thi= ngs, including data formats and network protocols. I believe in this instan= ce, you’re talking about data formats. Right?

 =

 

 

3.       I don’t = really understand the parenthetical comment “i.e. operations”. = I think the preceding phrase (“curating domain concept instance colle= ctions in content repositories”) means “storing security automa= tion content into databases”. I don’t mind using fancy words fo= r that but I don’t see what “i.e. operations” has to do w= ith that. Maybe you mean that the security operations teams will be using t= hat content. But I think that applies to everything we’re doing here.=

 

 

4.       Whe= n you say “maintain an authoritative point of reference”, that = starts to sound like IETF or IANA would be maintaining an authoritative lis= t of vulnerabilities and proper configurations. Of course, that isn’t= what you mean. I think we want to enable organizations to maintain their o= wn content repositories. I suggest that you rewrite that sentence to fix th= is confusion and also change from passive voice (“It is one thing = 230;”) to active voice. Replace that sentence with “Defining a = standards representation for security content is not enough. To enable inte= roperable security automation, we must define standard protocols for storin= g, retrieving, and exchanging that content.”

 <= /span>

=  

5.       In the numbered list of area= s of focus for the WG, why do you say “device states” in item 1= and “systems’ state” in item 2? Those seem to be two phr= ases for the same thing. Also, doesn’t 2 include 1? And “respon= se” (including remediation and mitigation) seems to be missing from t= his list. Do we just want to monitor our system vulnerabilities and watch t= hem get hacked? No, I think we want to be able to use standards to fix vuln= erabilities, install countermeasures and mitigations, and intervene when at= tacks are detected.

 

 

=

 

6. =       UC2, UC4, and UC5 from the use cases documen= t do not seem to be addressed in this charter, except perhaps for the last = document on “securely sharing dynamic network state information”= ;. Maybe this omission is deliberate. I have been saying for a while that w= e have too many work items on our plate. If we added UC2, UC4, and UC5 to t= his charter, we’d probably have 3-4 times as many work items. So I= 217;m actually OK with deciding that UC2, UC4, and UC5 aren’t in scop= e for this WG. But we should make that decision explicitly.

&nbs= p;

 

7.       One of the delivera= bles is “A Standards Track document specifying interfaces and communi= cation protocols used for security automation and continuous monitoringR= 21;. That sounds like several documents. Why have one document that specifi= es multiple protocols and interfaces? And which protocols are these, exactl= y? I could imagine 20 different ones that could all fit in this broad categ= ory.

 

 

As I said above, this is a good first = draft. Thanks for preparing it and for welcoming comments on it. We’v= e started down the path of finding the proper scope for this WG. That’= ;s essential.

 

Thanks,

 

=

Steve

 

= Sent: Tuesday, July 31, 2012 6:12 PM=

To: = sacm@ietf.org

Subject: [sacm] Pr= oposed SACM Charter

 

Hi all,

 

Here is= an initial cut at the proposed SACM Working Group charter.  The = intent of this is to be a starting point for the conversation. Comments are= expected, encouraged and welcomed.

 

--------<= /span>

Secur= ity Automation Continuous Monitoring (SACM)

 <= /p>

Proposed Wor= king Group Charter

 

Chairs:

TBD

TBD

 

Security Area Directors:

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

=  

Security Area Advisor:

     Sean Turner &= lt;turners@ieca.com<mailto:turners@ieca.com>>

&= nbsp;

Mailing Lists:

=      General Discussion: sacm@ietf.org<mailto:sacm@ietf.org>

     Archive:&= nbsp;        http://www.ietf.org/mail-archive/web/sacm

 

Description of Working Group

 

Securing i= nformation and the systems that store, process, and transmit that informati= on has become a challenging task for organizations of all sizes, and we fin= d that security practitioners spend most of their time on manual processes = relegating them to ineffectiveness. Security automation is the key to escap= ing this rut. This working group will enable security automation standards = in support of information security processes and practices where practical,= such that security practitioners can be better utilized within their organ= izations and we can meet the more advanced needs of the security community = (e.g. information sharing, continuous monitoring, result aggregation and an= alysis). The initial focus of this work is toaddress enterprise and SOHO us= e cases. The working group will achieve this by consuming and continuing (w= ith cooperation) the security automation work already performed by various = organizations around the world.

 

The initial work has bee= n fruitful, and the specifications previously published are ready for expan= sion on the international stage. Of particular interest to this working gro= up are the security automation specifications supporting asset, change, con= figuration, and vulnerability management. Of secondary interest to this wor= king group are the emerging security automation specifications relating to = event management and continuous monitoring.

 <= /p>

By undertaki= ng this work, we recognize that there are multiple categories of problems i= n the security automation domain: defining expressions for particular domai= n concepts (i.e. specifications), curating domain concept instance collecti= ons in content repositories (i.e. operations), and enabling interoperabilit= y through the development and use of interfaces and communications protocol= s. It is one thing to define an expression for vulnerabilities and configur= ation items, but it is quite another to maintain an authoritative point of = reference upon which tools (and their users) can rely and support the autom= ated exchange of vulnerability and configuration information.

&n= bsp;

This working group will provide solutions to these categories of prob= lems and the main areas of focus for this working group are described as fo= llows:

 

1. Define, either by normative reference, adoptio= n, or creation, a set of standards that can be used for the purpose of asse= ssing, aggregating and comparing device states against expected values,and = reporting on those results in a predefined or ad hoc manner.

&nb= sp;

2. Define, either by normative reference, adoption, or creation, a set= of standards that can be used to continuously monitor and report on system= s’ state and security process effectiveness in a pre-defined or ad-ho= c manner.

 

3. Create relationships between existing oper= ations management standards to enable a comprehensive view of security auto= mation, leveraging existing work and implementations.

=

 

Th= is working group will produce the following:

 =

* An Inform= ational document providing an overview of security automation and continuou= s monitoring to include a reference model

<= p class=3DMsoNormal>* A Standards Track documen= t specifying benchmark configuration representation

* An Informationa= l document stating guidelines / requirements for specifying checking langua= ges

* Standards Track documents specifying device state checking lang= uages

* A Standards Track document specifying an interrogative checki= ng language

* A Standards Track document specifying platform naming, = matching and applicability

* A Standards Track document specifying as= set identification and reporting information

* A Standards Track docu= ment specifying interfaces and communication protocols used for security au= tomation and continuous monitoring

* A Standards Track document descr= ibing the messages and network protocols for distributing Security Automati= on Content

* A Standards Track document describing integrating securi= ty automation and Network Endpoint Assessment capabilities

* A Standa= rds Track document describing protocols and data formats for securely shari= ng dynamic network state information among security systems

&nbs= p;

Goals and Milestones

 

Needs to be developed.

 

-------

 

Kent Landfield

<= /div>

 

McA= fee | An Intel Company

Direct: +1.972.963.7096

<= /div>

Mobile: +1.817.6= 37.8026

Web: www.mcafee.com<htt= p://www.mcafee.com/>

 

<= /div>
= --_000_AC6674AB7BC78549BB231821ABF7A9AEB833C927A9EMBX01WFjnprn_-- From Kent_Landfield@mcafee.com Thu Aug 2 14:55:45 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0681821E80B0 for ; Thu, 2 Aug 2012 14:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.308 X-Spam-Level: X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1jXj2ooQQyJ for ; Thu, 2 Aug 2012 14:55:42 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id CCCA811E80F0 for ; Thu, 2 Aug 2012 14:55:41 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 7d76_06ca_868c67d9_0433_4d71_bd25_2a302bdafbe5; Thu, 02 Aug 2012 16:55:33 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Thu, 2 Aug 2012 16:55:17 -0500 From: To: , , Date: Thu, 2 Aug 2012 16:56:15 -0500 Thread-Topic: Proposed SACM Charter Thread-Index: Ac1w+YCOIdVHpwMfQ4O41Ev34pyzmQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC40456538D28kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] Proposed SACM Charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:55:45 -0000 --_000_CC40456538D28kentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Fair enough. These will be discussed during the meeting. Thanks Steve! 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, August 2, 2012 2:47 PM To: Kent Landfield >, Kathleen Moriarty >, "sacm@ietf.org" > Subject: RE: Proposed SACM Charter Kent, I don=92t feel that my suggested changes need to get into the charter befor= e the meeting. In fact, I=92d rather not see the charter get changed before= the meeting. We=92ve had lots of good questions and suggestions from lots = of people in the last day or so on the list. Let=92s keep gathering comment= s and discussing them on the list and at the meeting. When/if the charter e= ditors judge that there=92s rough consensus on a change, then it should go = in the charter. If you believe that there=92s already rough consensus on some suggestions, = I suggest putting those on a slide at the SACM meeting and asking if people= agree with them. If all those in the room agree, that=92s a good sign that= there=92s consensus (to be confirmed on the list, of course). And if it sp= arks discussion, the suggestions may be refined and improved. But I=92d go = for highlighting key suggestions on slides for discussion instead of making= edits to the charter before the meeting. Please ask your clarifying questions of me on the list or (if they=92d be b= etter asked F2F) let=92s get together here in Vancouver to discuss them. I = can be free at any time today or tonight (although I expect we=92d both lik= e to go to saag and sacm!). Thanks, Steve From: Kent_Landfield@mcafee.com [mailto:K= ent_Landfield@mcafee.com] Sent: Thursday, August 02, 2012 5:36 PM To: kathleen.moriarty@emc.com; Stephen Ha= nna; sacm@ietf.org Subject: Re: Proposed SACM Charter I will try to get them in but I have a question or two on them so not all m= ay make it in for the Side Meeting. I will definitely had clarifying questi= ons of Steve. ;-) Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Kathleen Moriarty > Date: Thursday, August 2, 2012 2:15 PM To: "shanna@juniper.net" >, Kent Landfield >, "sacm@ietf.org" > Subject: RE: Proposed SACM Charter +1 on Steve's comments, very good suggestions! Can these comments get into= an updated version of the charter for tonight's discussion? I also agree on not including all of the use cases in the charter. I belie= ve UC 5 is assisting with the connection to MILE work. Where we think anot= her WG is addressing a use case, maybe it would be good to call that out. = I think it would make the most sense to have that int he use case document.= ANy thoughts? Thanks, Kathleen ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@iet= f.org] On Behalf Of Stephen Hanna [shanna@jun= iper.net] Sent: Wednesday, August 01, 2012 8:57 PM To: Kent_Landfield@McAfee.com; sacm@ietf.= org Subject: Re: [sacm] Proposed SACM Charter Kent, Thanks for drafting the charter and sending it out for comments. We=92ve go= t a good start here but I have a few ideas for refinement: 1. Add =93remediation and response=94 to the first e.g. list. In the = SACM Use Cases document, use cases UC1-UC4 all include response and for goo= d reason. Automated attacks proceed quite rapidly. Automated defense must b= e able to do so also, with appropriate safeguards to ensure that remediatio= n and response don=92t cause more problems than they solve. 2. For =93i.e. specifications=94, I would say =93i.e. data formats=94= . We=92ll be creating specifications for many things, including data format= s and network protocols. I believe in this instance, you=92re talking about= data formats. Right? 3. I don=92t really understand the parenthetical comment =93i.e. oper= ations=94. I think the preceding phrase (=93curating domain concept instanc= e collections in content repositories=94) means =93storing security automat= ion content into databases=94. I don=92t mind using fancy words for that bu= t I don=92t see what =93i.e. operations=94 has to do with that. Maybe you m= ean that the security operations teams will be using that content. But I th= ink that applies to everything we=92re doing here. 4. When you say =93maintain an authoritative point of reference=94, t= hat starts to sound like IETF or IANA would be maintaining an authoritative= list of vulnerabilities and proper configurations. Of course, that isn=92t= what you mean. I think we want to enable organizations to maintain their o= wn content repositories. I suggest that you rewrite that sentence to fix th= is confusion and also change from passive voice (=93It is one thing =85=94)= to active voice. Replace that sentence with =93Defining a standards repres= entation for security content is not enough. To enable interoperable securi= ty automation, we must define standard protocols for storing, retrieving, a= nd exchanging that content.=94 5. In the numbered list of areas of focus for the WG, why do you say = =93device states=94 in item 1 and =93systems=92 state=94 in item 2? Those s= eem to be two phrases for the same thing. Also, doesn=92t 2 include 1? And = =93response=94 (including remediation and mitigation) seems to be missing f= rom this list. Do we just want to monitor our system vulnerabilities and wa= tch them get hacked? No, I think we want to be able to use standards to fix= vulnerabilities, install countermeasures and mitigations, and intervene wh= en attacks are detected. 6. UC2, UC4, and UC5 from the use cases document do not seem to be ad= dressed in this charter, except perhaps for the last document on =93securel= y sharing dynamic network state information=94. Maybe this omission is deli= berate. I have been saying for a while that we have too many work items on = our plate. If we added UC2, UC4, and UC5 to this charter, we=92d probably h= ave 3-4 times as many work items. So I=92m actually OK with deciding that U= C2, UC4, and UC5 aren=92t in scope for this WG. But we should make that dec= ision explicitly. 7. One of the deliverables is =93A Standards Track document specifyin= g interfaces and communication protocols used for security automation and c= ontinuous monitoring=94. That sounds like several documents. Why have one d= ocument that specifies multiple protocols and interfaces? And which protoco= ls are these, exactly? I could imagine 20 different ones that could all fit= in this broad category. As I said above, this is a good first draft. Thanks for preparing it and fo= r welcoming comments on it. We=92ve started down the path of finding the pr= oper scope for this WG. That=92s essential. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Tuesday, July 31, 2012 6:12 PM To: sacm@ietf.org Subject: [sacm] Proposed SACM Charter Hi all, Here is an initial cut at the proposed SACM Working Group charter. The int= ent of this is to be a starting point for the conversation. Comments are ex= pected, encouraged and welcomed. -------- Security Automation Continuous Monitoring (SACM) Proposed Working Group Charter Chairs: TBD TBD Security Area Directors: Stephen Farrell > Sean Turner > Security Area Advisor: Sean Turner > Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm Description of Working Group Securing information and the systems that store, process, and transmit that= information has become a challenging task for organizations of all sizes, = and we find that security practitioners spend most of their time on manual = processes relegating them to ineffectiveness. Security automation is the ke= y to escaping this rut. This working group will enable security automation = standards in support of information security processes and practices where = practical, such that security practitioners can be better utilized within t= heir organizations and we can meet the more advanced needs of the security = community (e.g. information sharing, continuous monitoring, result aggregat= ion and analysis). The initial focus of this work is toaddress enterprise a= nd SOHO use cases. The working group will achieve this by consuming and con= tinuing (with cooperation) the security automation work already performed b= y various organizations around the world. The initial work has been fruitful, and the specifications previously publi= shed are ready for expansion on the international stage. Of particular inte= rest to this working group are the security automation specifications suppo= rting asset, change, configuration, and vulnerability management. Of second= ary interest to this working group are the emerging security automation spe= cifications relating to event management and continuous monitoring. By undertaking this work, we recognize that there are multiple categories o= f problems in the security automation domain: defining expressions for part= icular domain concepts (i.e. specifications), curating domain concept insta= nce collections in content repositories (i.e. operations), and enabling int= eroperability through the development and use of interfaces and communicati= ons protocols. It is one thing to define an expression for vulnerabilities = and configuration items, but it is quite another to maintain an authoritati= ve point of reference upon which tools (and their users) can rely and suppo= rt the automated exchange of vulnerability and configuration information. This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used for the purpose of assessing, aggregating and com= paring device states against expected values,and reporting on those results= in a predefined or ad hoc manner. 2. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used to continuously monitor and report on systems=92 = state and security process effectiveness in a pre-defined or ad-hoc manner. 3. Create relationships between existing operations management standards to= enable a comprehensive view of security automation, leveraging existing wo= rk and implementations. This working group will produce the following: * An Informational document providing an overview of security automation an= d continuous monitoring to include a reference model * A Standards Track document specifying benchmark configuration representat= ion * An Informational document stating guidelines / requirements for specifyin= g checking languages * Standards Track documents specifying device state checking languages * A Standards Track document specifying an interrogative checking language * A Standards Track document specifying platform naming, matching and appli= cability * A Standards Track document specifying asset identification and reporting = information * A Standards Track document specifying interfaces and communication protoc= ols used for security automation and continuous monitoring * A Standards Track document describing the messages and network protocols = for distributing Security Automation Content * A Standards Track document describing integrating security automation and= Network Endpoint Assessment capabilities * A Standards Track document describing protocols and data formats for secu= rely sharing dynamic network state information among security systems Goals and Milestones Needs to be developed. ------- Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com --_000_CC40456538D28kentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Fair enough= . These will be discussed during the meeting.

Than= ks Steve!

Kent Landfield

McAfee | An Intel Company<= /span>
= Direct: +1.97= 2.963.7096 
= Mobile: +1.817.637.8026
Web: www.mcafee.com

From: Stephen Hanna <shanna@juniper.ne= t>
Date: Thursday, Augus= t 2, 2012 2:47 PM
To: Kent Land= field <Kent_Landfield@McAfe= e.com>, Kathleen Moriarty <kathleen.moriarty@emc.com>, "sacm@ietf.org" <sacm@iet= f.org>
Subject: RE: Prop= osed SACM Charter

Kent,

=  

I don= =92t feel that my suggested changes need to get into the charter before the= meeting. In fact, I=92d rather not see the charter get changed before the = meeting. We=92ve had lots of good questions and suggestions from lots of people in = the last day or so on the list. Let=92s keep gathering comments and discuss= ing them on the list and at the meeting. When/if the charter editors judge = that there=92s rough consensus on a change, then it should go in the charter.

 

If you believe that there=92s already rough consensus on so= me suggestions, I suggest putting those on a slide at the SACM meeting and = asking if people agree with them. If all those in the room agree, that=92s a good sign that there=92s = consensus (to be confirmed on the list, of course). And if it sparks discus= sion, the suggestions may be refined and improved. But I=92d go for highlig= hting key suggestions on slides for discussion instead of making edits to the charter before the meeting.

 

=

Please ask your clarifying questio= ns of me on the list or (if they=92d be better asked F2F) let=92s get toget= her here in Vancouver to discuss them. I can be free at any time today or tonight (although I expect we=92d both like to go to = saag and sacm!).

 

Th= anks,

&n= bsp;

Steve

 

From: Kent_Landfield@mcafee.com [mailto:Kent_Landfield@mcafee.com]
Sent: Thursday, August 02, 2012 5:36 PM
To: kathleen.moriarty@emc.com; Stephen H= anna; sacm@ietf.org
Subject:= Re: Proposed SACM Charter

 

I will try to get them in but I have a question or two = on them so not all may make it in for the Side Meeting. I will definitely h= ad clarifying questions of Steve. ;-)

 

<= /div>

Thanks.

 

Kent Landfield

McAfee | An Intel Com= pany
Direct: +1.972= .963.7096 
Mobile: +1.8= 17.637.8026
Web: www.mcafee.com

 

From: Kathleen Moriarty <kathleen.moriarty@emc.com>
Date: Thursday, Augus= t 2, 2012 2:15 PM
To: "shanna@juniper.net" <sha= nna@juniper.net>, Kent Landfield <Kent_Landfield@McAfee.com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: = RE: Proposed SACM Charter

 

+1 on Steve's comments, very good suggestions!  Can t= hese comments get into an updated version of the charter for tonight's disc= ussion?

 

I also agree on not including all of the us= e cases in the charter.  I believe UC 5 is assisting with the con= nection to MILE work.  Where we think another WG is addressing a = use case, maybe it would be good to call that out.  I think it would make the most sense to have that int= he use case document.  ANy thoughts?

=

 

Than= ks,

Kathleen

________________________________________<= /o:p>

Sent: Wednesday, August 01, 2012= 8:57 PM

Subject: Re: [sacm] Proposed SACM Charter

&nb= sp;

Kent,

 

Thanks for drafting the charter and sen= ding it out for comments. We=92ve got a good start here but I have a few id= eas for refinement:

=  

 

1.  &nb= sp;    Add =93remediation and response=94 to the first e.g. = list. In the SACM Use Cases document, use cases UC1-UC4 all include respons= e and for good reason. Automated attacks proceed quite rapidly. Automated d= efense must be able to do so also, with appropriate safeguards to ensure that rem= ediation and response don=92t cause more problems than they solve.

=  

 

2.       For = =93i.e. specifications=94, I would say =93i.e. data formats=94. We=92ll be = creating specifications for many things, including data formats and network= protocols. I believe in this instance, you=92re talking about data formats. Right?

 

 

 

= 3.       I don=92t really understand the pare= nthetical comment =93i.e. operations=94. I think the preceding phrase (=93c= urating domain concept instance collections in content repositories=94) mea= ns =93storing security automation content into databases=94. I don=92t mind using fancy words for that but I= don=92t see what =93i.e. operations=94 has to do with that. Maybe you mean= that the security operations teams will be using that content. But I think= that applies to everything we=92re doing here.

=

 

 

4.       When you say =93maintain = an authoritative point of reference=94, that starts to sound like IETF or I= ANA would be maintaining an authoritative list of vulnerabilities and prope= r configurations. Of course, that isn=92t what you mean. I think we want to enable organizations to maintain= their own content repositories. I suggest that you rewrite that sentence t= o fix this confusion and also change from passive voice (=93It is one thing= =85=94) to active voice. Replace that sentence with =93Defining a standards representation for security content is not en= ough. To enable interoperable security automation, we must define standard = protocols for storing, retrieving, and exchanging that content.=94

=  

 

5.       In t= he numbered list of areas of focus for the WG, why do you say =93device sta= tes=94 in item 1 and =93systems=92 state=94 in item 2? Those seem to be two= phrases for the same thing. Also, doesn=92t 2 include 1? And =93response=94 (including remediation and mitigation) seems to be missing = from this list. Do we just want to monitor our system vulnerabilities and w= atch them get hacked? No, I think we want to be able to use standards to fi= x vulnerabilities, install countermeasures and mitigations, and intervene when attacks are detected.

&nb= sp;

 

 

6.      = UC2, UC4, and UC5 from the use cases document do not seem to be addressed = in this charter, except perhaps for the last document on =93securely sharin= g dynamic network state information=94. Maybe this omission is deliberate. I have been saying for a while that we have too many work i= tems on our plate. If we added UC2, UC4, and UC5 to this charter, we=92d pr= obably have 3-4 times as many work items. So I=92m actually OK with decidin= g that UC2, UC4, and UC5 aren=92t in scope for this WG. But we should make that decision explicitly.

&nb= sp;

 

7.       One of the del= iverables is =93A Standards Track document specifying interfaces and commun= ication protocols used for security automation and continuous monitoring=94= . That sounds like several documents. Why have one document that specifies multiple protocols and interfaces? And wh= ich protocols are these, exactly? I could imagine 20 different ones that co= uld all fit in this broad category.

 

 

A= s I said above, this is a good first draft. Thanks for preparing it and for= welcoming comments on it. We=92ve started down the path of finding the pro= per scope for this WG. That=92s essential.

=

 =

Thanks,

 

Steve

 

Sent: Tuesday, July 31, 2012 6:12 PM

To: sacm@ietf.org

Subject: [sacm] Proposed SACM Ch= arter

 

Hi all,

 

Here is an init= ial cut at the proposed SACM Working Group charter.  The intent o= f this is to be a starting point for the conversation. Comments are expecte= d, encouraged and welcomed.

 

=

--------

Securit= y Automation Continuous Monitoring (SACM)

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

Proposed W= orking Group Charter

 

Chairs:

TBD<= /span>

TBD=

 

Descri= ption of Working Group

 

Securing information and the = systems that store, process, and transmit that information has become a cha= llenging task for organizations of all sizes, and we find that security pra= ctitioners spend most of their time on manual processes relegating them to ineffectiveness. Security auto= mation is the key to escaping this rut. This working group will enable secu= rity automation standards in support of information security processes and = practices where practical, such that security practitioners can be better utilized within their organizati= ons and we can meet the more advanced needs of the security community (e.g.= information sharing, continuous monitoring, result aggregation and analysi= s). The initial focus of this work is toaddress enterprise and SOHO use cases. The working group will achieve= this by consuming and continuing (with cooperation) the security automatio= n work already performed by various organizations around the world.

 

The initial work has been fruitful, and the specifications= previously published are ready for expansion on the international stage. O= f particular interest to this working group are the security automation spe= cifications supporting asset, change, configuration, and vulnerability management. Of = secondary interest to this working group are the emerging security automati= on specifications relating to event management and continuous monitoring.

 

By undertaking this work, we recognize that there are= multiple categories of problems in the security automation domain: definin= g expressions for particular domain concepts (i.e. specifications), curatin= g domain concept instance collections in content repositories (i.e. operations), an= d enabling interoperability through the development and use of interfaces a= nd communications protocols. It is one thing to define an expression for vu= lnerabilities and configuration items, but it is quite another to maintain an authoritative point of refer= ence upon which tools (and their users) can rely and support the automated = exchange of vulnerability and configuration information.<= /p>

 = ;

This working group will provide solutions to these categories of probl= ems and the main areas of focus for this working group are described as fol= lows:

 

1. Define, either by normative reference, adop= tion, or creation, a set of standards that can be used for the purpose of a= ssessing, aggregating and comparing device states against expected values,a= nd reporting on those results in a predefined or ad hoc manner.

 <= /span>

2. = Define, either by normative reference, adoption, or creation, a set of stan= dards that can be used to continuously monitor and report on systems=92 sta= te and security process effectiveness in a pre-defined or ad-hoc manner.

 

3. Create relationships between existing op= erations management standards to enable a comprehensive view of security au= tomation, leveraging existing work and implementations.

 =

This working group will produce the following:

 

*= An Informational document providing an overview of security automation and= continuous monitoring to include a reference model

* A Standards T= rack document specifying benchmark configuration representation<= /span>

* A= n Informational document stating guidelines / requirements for specifying c= hecking languages

* Standards Track documents specifying device sta= te checking languages

* A Standards Track document specifying an in= terrogative checking language

* A Standards Track document specifyi= ng platform naming, matching and applicability

<= div>

* A Standards Track = document specifying asset identification and reporting information

= * A Standards Track document specifying interfaces and communication protoc= ols used for security automation and continuous monitoring

* A Stan= dards Track document describing the messages and network protocols for dist= ributing Security Automation Content

* A Standards Track document d= escribing integrating security automation and Network Endpoint Assessment c= apabilities

* A Standards Track document describing protocols and d= ata formats for securely sharing dynamic network state information among se= curity systems

 

Goals and Milestones

&nb= sp;

Needs to be developed.

 

-------

&= nbsp;

Kent Landfield

 

McAfee | An Intel Company

Direct: +1.972.963.7096

Mobile: +1.817.637.8026=

Web: www.mcafee.com<http://www.mc= afee.com/>

 

--_000_CC40456538D28kentlandfieldmcafeecom_-- From amontville@tripwire.com Thu Aug 2 18: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 34A7821F8C36 for ; Thu, 2 Aug 2012 18:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.424 X-Spam-Level: X-Spam-Status: No, score=-5.424 tagged_above=-999 required=5 tests=[AWL=1.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhqXVNo8IcmR for ; Thu, 2 Aug 2012 18:28:19 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD6621F8C33 for ; Thu, 2 Aug 2012 18:28:19 -0700 (PDT) Received: from mail61-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 Aug 2012 01:28:18 +0000 Received: from mail61-tx2 (localhost [127.0.0.1]) by mail61-tx2-R.bigfish.com (Postfix) with ESMTP id 87AF560097 for ; Fri, 3 Aug 2012 01:28:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zzc594Kzz1202hzzz2dh2a8h668h839h944hd25he5bhf0ah107ah) Received: from mail61-tx2 (localhost.localdomain [127.0.0.1]) by mail61-tx2 (MessageSwitch) id 1343957296789185_30660; Fri, 3 Aug 2012 01:28:16 +0000 (UTC) Received: from TX2EHSMHS034.bigfish.com (unknown [10.9.14.240]) by mail61-tx2.bigfish.com (Postfix) with ESMTP id B385A40048 for ; Fri, 3 Aug 2012 01:28:16 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by TX2EHSMHS034.bigfish.com (10.9.99.134) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 Aug 2012 01:28:16 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 Aug 2012 18:29:21 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Thu, 2 Aug 2012 18:28:14 -0700 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: IETF 84 Side Meeting Thread-Index: Ac1xF0A99oROiQXCTxe9tUK0O0qA0Q== Date: Fri, 3 Aug 2012 01:28:13 +0000 Message-ID: <1784F640-22C0-4DBA-9AB7-6CEE2C4CBDCB@tripwire.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: [sacm] IETF 84 Side Meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 01:28:20 -0000 We will be getting started as close to 6:30 as we can. There is a group be= fore us that goes right to 6:30. Adam Sent from my iPhone= From osantos@cisco.com Thu Aug 2 20:17:36 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2AA311E80B8 for ; Thu, 2 Aug 2012 20:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WdSu+ELoNRO for ; Thu, 2 Aug 2012 20:17:36 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC4511E80AE for ; Thu, 2 Aug 2012 20:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=osantos@cisco.com; l=626; q=dns/txt; s=iport; t=1343963856; x=1345173456; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=edpbDY9tXcLY7+qufy65tTEB8/FY8BNkDlr5Q27kNS4=; b=HpuU0O/yznU9xYm+xWAuj6oVWOBGfVUHg40dg73C9SzhB0OSXcRBv5A1 gY7wdvGFOSHPwoHj48BBkPL3JjoAG8WH+2TY+Ysv0Cn3bvKMUv375OynE THPOGT05fG5qDXI7I/wbCgtfl9CO9jCIOMIuCBVUTLmGHhOO8nPYTcPsK E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFABZCG1CtJXG+/2dsb2JhbABCA4U0s3CBB4IiAQQSASdNBAEqFCsXJgEEEwgah2ubcIEooEIEjyaCQWADo2+BZoJfgV8 X-IronPort-AV: E=Sophos;i="4.77,704,1336348800"; d="scan'208";a="107855568" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 03 Aug 2012 03:17:35 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q733HZ2N014282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 3 Aug 2012 03:17:35 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.7]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 22:17:35 -0500 From: "Omar Santos (osantos)" To: "sacm@ietf.org" Thread-Topic: Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQ== Date: Fri, 3 Aug 2012 03:17:35 +0000 Message-ID: <93ED586BE669044CA2F91C5F3BE4FD9017B0C651@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.110.37] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.004 x-tm-as-result: No--32.351000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 03:17:37 -0000 During today's IETF meeting it was suggested to narrow down the scope of th= e things to be initially addressed in the potential SACM working group. Sev= eral commented that UC 1 and UC3 may be the best use-cases to be initially = scoped. I also agree that UC 1 & UC 3 are the best choices; and wanted to t= ake discussion back to the alias. Even though UC 1 and UC 3 may be the best= choice; they also need to be scoped and defined carefully. Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC From lnunez@c3isecurity.com Fri Aug 3 05:18: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 91D1121F8DA0 for ; Fri, 3 Aug 2012 05:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.796 X-Spam-Level: X-Spam-Status: No, score=-3.796 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdtgg8EF0RYt for ; Fri, 3 Aug 2012 05:18:04 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DFBE321F8D9D for ; Fri, 3 Aug 2012 05:18:03 -0700 (PDT) Received: by ghbg16 with SMTP id g16so832392ghb.31 for ; Fri, 03 Aug 2012 05:18:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=xhF1SpMBc3qSTiyvptXy9YmbBX4cxIHKERXetsltWeg=; b=guld9oayp4Dc3p+Vn6M+spMJuWECCmD5S9ECY4vfgn/nRDd0YsH0tgtydtJf5jdhJm mFWMZ7Vw2myNElLSg01O6qZwDZFC5EX7IwKGlLygvpoO9ptv8BsQ+DiBvzoUSbTGgQog nVYn9p+bpWeQERQqa+TTtEPfeoEqqozsGD6Ht379bIf2vsNnGWGzUSprdG/e8aUJRjkr jcYAbcm2mpWlZBG2CVFRqSloQRx8OU4uLPtP3GhUMMtB7yV74EhJrPze1b+t4mD+Rjvs OvQykda0Gn/J5NwZAJyQeumWouq1TbD49t/h1x6ZZ8Aqhnrd2OqLvzu4vrqr/Gx5aPO7 RfLg== Received: by 10.236.117.168 with SMTP id j28mr1471213yhh.88.1343996283489; Fri, 03 Aug 2012 05:18:03 -0700 (PDT) Received: from [192.168.1.11] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id w1sm8066142anm.8.2012.08.03.05.18.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Aug 2012 05:18:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Luis Nunez In-Reply-To: <93ED586BE669044CA2F91C5F3BE4FD9017B0C651@xmb-rcd-x09.cisco.com> Date: Fri, 3 Aug 2012 08:17:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <93ED586BE669044CA2F91C5F3BE4FD9017B0C651@xmb-rcd-x09.cisco.com> To: Omar Santos (osantos) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmqPCuQejFMMz5Cix5g0gR/1KEqqgcr5DZKjiXk54s+9TwcbrWWKvsyCR3hqdbEgvAiLMKx Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 12:18:04 -0000 Thanks Omar. Below are the use cases. I agree we should focus on refining these use = cases to form a charter. I would like to see work that will connect = SCAP endpoint assessments to NEA transport mechanisms and enforcement. = There are synergies between the two that IETF could bind together. We maybe able to combine both UC1 and UC2 into one use case. Three = things I would like to tie together are: 1. NEA 2. SCAP=20 3. Endpoints. We need to define what an endpoint is. UC1: Assessment and Enforcement of Acceptable State =96Controlling access to networks and services based on the assessment = and analysis of host and/or network state based on machine processable = content. =95UC3: Security Control Verification and Monitoring =96Continuous assessment of the implementation and effectiveness of = security controls based on machine processable content. -ln On Aug 2, 2012, at 11:17 PM, Omar Santos (osantos) wrote: > During today's IETF meeting it was suggested to narrow down the scope = of the things to be initially addressed in the potential SACM working = group. Several commented that UC 1 and UC3 may be the best use-cases to = be initially scoped. I also agree that UC 1 & UC 3 are the best choices; = and wanted to take discussion back to the alias. Even though UC 1 and UC = 3 may be the best choice; they also need to be scoped and defined = carefully. >=20 >=20 > Regards, >=20 > Omar Santos > Incident Manager, PSIRT > Security Research and Operations > Cisco Systems, Inc. > Email: os@cisco.com > Phone: +1 919 392 8635 > PGP Key: 0x3AF27EDC >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From david.oliva@verizon.net Fri Aug 3 06:45:29 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC2D21F8CE5 for ; Fri, 3 Aug 2012 06:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.256 X-Spam-Level: X-Spam-Status: No, score=0.256 tagged_above=-999 required=5 tests=[AWL=1.300, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kAwWkuyk-G0 for ; Fri, 3 Aug 2012 06:45:29 -0700 (PDT) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by ietfa.amsl.com (Postfix) with ESMTP id D09E221F8CCF for ; Fri, 3 Aug 2012 06:45:28 -0700 (PDT) Received: from vms170025pub.verizon.net ([unknown] [192.168.1.3]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M86006IEM6YXLJ0@vms173005.mailsrvcs.net> for sacm@ietf.org; Fri, 03 Aug 2012 08:44:59 -0500 (CDT) Received: from 96.241.55.45 ([96.241.55.45]) by vms170025 (Verizon Webmail) with HTTP; Fri, 03 Aug 2012 08:44:58 -0500 (CDT) Date: Fri, 03 Aug 2012 08:44:58 -0500 (CDT) From: david.oliva@verizon.net To: sacm@ietf.org Message-id: <8083323.1569641.1344001498856.JavaMail.root@vms170025> 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.55.45] Subject: Re: [sacm] Proposed SACM Charter Comments feedback X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 13:45:30 -0000
Kat= hleen:
 
I would be interested and willing to work= in mapping SCAP to CobiT compliance requirements.
In my thinking= this effort would consist of mapping SP 800-53/53A to CobiT.
&nb= sp;
Anyone else interested?
 
David Oliv= a
 
 
On 08/02/12, Adam Montville<amontville@= tripwire.com> wrote:
 


On Aug 2, 2012, at 2:= 12 PM, "kathleen.moriarty@emc.com" <kathleen.moriarty@em= c.com> wrote:

> How do people feel about having the focus = within the SACM effort where we are providing the capabilities and then hav= ing ancillary work that provides the desired mapping to frameworks and regu= lations by the communities (or vendors) that need to support those regulati= ons and frameworks?

Again, this is good guidance. Would this ancilla= ry work be simply "out there" or under the guise of informational documenta= tion in a WG?
_______________________________________________
sacm ma= iling list
sacm@ietf.org
https://www.ietf.org/mailman/= listinfo/sacm
From lnunez@c3isecurity.com Fri Aug 3 07:04: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 4D98721F8D9F for ; Fri, 3 Aug 2012 07:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.771 X-Spam-Level: X-Spam-Status: No, score=-3.771 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpk41kpQIMXS for ; Fri, 3 Aug 2012 07:04:05 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C17B21F8D9A for ; Fri, 3 Aug 2012 07:04:05 -0700 (PDT) Received: by yhq56 with SMTP id 56so960484yhq.31 for ; Fri, 03 Aug 2012 07:04:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=S2WCuKiCN5KItv/c9VdpvkY19soF2R4PhBl1AzNVrZs=; b=KDfkalO989dXiT2Kepkb9XYakSqzxSfRS5Ue8zUmovg0kCDgH3CtMGmuXtKJWr6pc3 kIN4OF9QA8J0/kWkc/vNsUVAq9qmcgqAZrFkPEugjy95yNNi7l1asNTSBJ6aUT7wBxSe yPDjE1wp5aAbKzjFUTuY8rASu5VfOOfC3Ra/n2K3ZpnrFP9NUtlX41UNBKVXF5pAOgvv uihoQ+DETfadLuSfJvlACrfR8n+6RRQgk1qOCLePjVsBHWhSAH4iEWsL6rWwV6epIFpA HPj9mIDcQUuAKcO+c3g6eaaAkjYfGijRAonS2xWH6tkdRlcRQx+7ucQtaCnsIHA6oX5E SRJg== Received: by 10.236.200.132 with SMTP id z4mr1957346yhn.93.1344002644353; Fri, 03 Aug 2012 07:04:04 -0700 (PDT) Received: from [192.168.1.11] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id r22sm8283238anh.6.2012.08.03.07.04.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Aug 2012 07:04:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_8487AFF8-597D-464B-81B1-58F5B5E7FB8C" From: Luis Nunez In-Reply-To: <8083323.1569641.1344001498856.JavaMail.root@vms170025> Date: Fri, 3 Aug 2012 10:04:00 -0400 Message-Id: <263693DE-C76D-4DFC-8B4A-455AA6EE67D8@c3isecurity.com> References: <8083323.1569641.1344001498856.JavaMail.root@vms170025> To: david.oliva@verizon.net X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnORgBhgdjI8N3hfg69GOIWTM2vl9fz1Q4CalwJku2iBP/DkQ8qUJhnlAypOGU3hTcv4ZpS Cc: sacm@ietf.org Subject: Re: [sacm] Proposed SACM Charter Comments feedback X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 14:04:06 -0000 --Apple-Mail=_8487AFF8-597D-464B-81B1-58F5B5E7FB8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The Cloud Security Alliance has a nice mapping to various regulatory = controls. Would be nice to leverage the Cloud Controls matrix=20 = https://cloudsecurityalliance.org/wp-content/themes/csa/ccm-download-box.p= hp -ln On Aug 3, 2012, at 9:44 AM, david.oliva@verizon.net wrote: > Kathleen: > =20 > I would be interested and willing to work in mapping SCAP to CobiT = compliance requirements. > In my thinking this effort would consist of mapping SP 800-53/53A to = CobiT. > =20 > Anyone else interested? > =20 > David Oliva > =20 > =20 > On 08/02/12, Adam Montville wrote: > =20 >=20 >=20 > On Aug 2, 2012, at 2:12 PM, "kathleen.moriarty@emc.com" = wrote: >=20 > > How do people feel about having the focus within the SACM effort = where we are providing the capabilities and then having ancillary work = that provides the desired mapping to frameworks and regulations by the = communities (or vendors) that need to support those regulations and = frameworks? >=20 > Again, this is good guidance. Would this ancillary work be simply "out = there" or under the guise of informational documentation in a WG? > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --Apple-Mail=_8487AFF8-597D-464B-81B1-58F5B5E7FB8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii https://cloudsecurityalliance.org/wp-content/themes/csa/ccm-do= wnload-box.php

-ln


On Aug 3, 2012, at 9:44 AM, david.oliva@verizon.net = wrote:

Kathleen:
 
I would be = interested and willing to work in mapping SCAP to CobiT compliance = requirements.
In my thinking this effort would consist of = mapping SP 800-53/53A to CobiT.
 
Anyone else = interested?
 
David = Oliva
 
 
On 08/02/12, Adam = Montville<amontville@tripwire.com> wrote:
 


On Aug 2, 2012, at 2:12 PM, "kathleen.moriarty@emc.com" <kathleen.moriarty@emc.com> wrote:

> = How do people feel about having the focus within the SACM effort where = we are providing the capabilities and then having ancillary work that = provides the desired mapping to frameworks and regulations by the = communities (or vendors) that need to support those regulations and = frameworks?

Again, this is good guidance. Would this ancillary = work be simply "out there" or under the guise of informational = documentation in a = WG?
_______________________________________________
sacm mailing = list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm
=
_______________________________________________
sacm mailing = list
sacm@ietf.org
https://www.ietf.org/ma= ilman/listinfo/sacm

= --Apple-Mail=_8487AFF8-597D-464B-81B1-58F5B5E7FB8C-- From bakerj@mitre.org Fri Aug 3 08:27:46 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9337821F8D33; Fri, 3 Aug 2012 08:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTx0YkpQPQPa; Fri, 3 Aug 2012 08:27:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id BDDBF21F8CA7; Fri, 3 Aug 2012 08:27:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2862521B082B; Fri, 3 Aug 2012 11:27:45 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 11E8721B0034; Fri, 3 Aug 2012 11:27:45 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.146]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0309.002; Fri, 3 Aug 2012 11:27:44 -0400 From: "Baker, Jon" To: "mile@ietf.org" Thread-Topic: IPR and Transfer Considerations Thread-Index: Ac1xjIVDTlxzAl8JRGy9/mutJ1mmJA== Date: Fri, 3 Aug 2012 15:27:44 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D38651301FECBF1@IMCMBX03.MITRE.ORG> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: [sacm] IPR and Transfer Considerations X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 15:27:46 -0000 During the MILE WG session there were questions raised related to MITRE IPR= . I would like to make sure that the list is aware that MITRE has accommoda= ted all IPR related requests that have been made by this group. There are t= hree issues that have been raised: 1- Shortly before the Paris meeting (IETF 83) a concern was raised about th= e wording in the disclaimer portion of our terms of use pages not aligning = well with the wording that that IETF uses. At that time we made a small cha= nge to the disclaimer for all the relevant efforts we support. To the best = of my knowledge, this issue was addressed.=20 2- At the Paris meeting it was clear that there was confusion about the lic= ensing of CVE and several other efforts. I was asked, "How much does CVE co= st?" This too has been addressed. CVE and these other efforts are clearly f= ree to use. =20 3- Lastly, during the MILE WG session Tuesday of this week, it was made cle= ar that MITRE needs to post IPR disclosures for all of the relevant efforts= that MITRE supports. As of August 2, 2012 IPR disclosures have been submit= ted. I don't think they have been posted by the IETF yet.=20 Are there other IPR concerns that we are not aware of? There were also questions raised about MITRE's willingness to transfer IPR = to the IETF. I attended the Paris meeting (IETF 83) and during the SACM sid= e meeting was given the opportunity to discuss MITRE's perspective on this = topic. At the time I talked through what MITRE sees as the key distinctions= to be made when considering transferring a given effort to any other organ= ization. As a reminder I discussed the following: REGISTRIES VS. LANGUAGES=20 ---------------------------------- Roughly speaking, efforts can be grouped into two primary categories: regis= tries of named objects (e.g. CVE) and languages for defining structured con= tent (e.g. OVAL). As a rule, languages are good candidates to go to formal = standards bodies as they mature. In contrast, while registries may be refer= red to by the work developed in standards bodies as external dependencies; = standards bodies do not typically operate registries. EFFORTS HAVE MULTIPLE SUBCOMPONENTS ------------------------------------------------------ Registries tend to have three primary sub-components, including: i) the syntax of the namespace, ii) the registry of officially recognized objects and iii) definitions of acceptable use (which may include product testing = requirements). Languages tend to have four primary sub-components, including: i) the specification of the language, ii) repositories of content written in that language, iii) a reference implementation that can be used to verify both the la= nguage and content authored in the language and iv) definitions of acceptable use (which may include product testing r= equirements). These components need to be considered separately.=20 USG EFFORTS VS. MITRE MANAGED EFFORTS ------------------------------------------------------- In considering the transition of MITRE efforts to standards bodies and how = these decisions will be made, it is important to clearly distinguish betwee= n US Government (USG) efforts and efforts that our sponsors have directed M= ITRE to operate as a neutral 3rd party under our FFRDC charter. As you might imagine this leads to a sort of matrix that must be considered= to ultimately ensure that a successful and appropriate transition is made = for any given effort. Outside the MILE and SACM lists there are many organi= zations that depend upon the efforts that MITRE has led for many years, in = some cases it is several hundred or more. In fact, it is hard to imagine an= INFOSEC professional in the US that has not used CVE (either directly or i= ndirectly) in their career and CVE is translations are available in many o= ther languages too. MITRE has a responsibility to ensure the stability of t= hese efforts and not lose sight of the community that depends upon them tod= ay. Rest assured that MITRE and our sponsors view successful transfer of standa= rds to international bodies as the ultimate goal of much of our standards w= ork. MITRE is actively following the MILE and SACM lists, has raised awaren= ess of the relevant IETF activities in the existing standards related forum= s that we host, and is actively engaging with our sponsors on the topic of = international standards.=20 Thanks, Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org From amontville@tripwire.com Fri Aug 3 10:43: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 1AA6B21F8E0E for ; Fri, 3 Aug 2012 10:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.014 X-Spam-Level: X-Spam-Status: No, score=-4.014 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFT2taSD48j5 for ; Fri, 3 Aug 2012 10:43:34 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 584B321F8DE8 for ; Fri, 3 Aug 2012 10:43:34 -0700 (PDT) Received: from mail7-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 Aug 2012 17:43:33 +0000 Received: from mail7-ch1 (localhost [127.0.0.1]) by mail7-ch1-R.bigfish.com (Postfix) with ESMTP id 8CEE116024A for ; Fri, 3 Aug 2012 17:43:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzzz1202hzzz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail7-ch1 (localhost.localdomain [127.0.0.1]) by mail7-ch1 (MessageSwitch) id 1344015811925246_22642; Fri, 3 Aug 2012 17:43:31 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.248]) by mail7-ch1.bigfish.com (Postfix) with ESMTP id E02464C0047 for ; Fri, 3 Aug 2012 17:43:31 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 Aug 2012 17:43:30 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Aug 2012 10:45:35 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Fri, 3 Aug 2012 10:43:29 -0700 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: Next Steps Thread-Index: AQHNcZ99SdR7e+RjNUS49AhL6k9SWA== Date: Fri, 3 Aug 2012 17:43:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.16.97.137] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: [sacm] Next Steps X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 17:43:35 -0000 All: Yesterday's meeting went very well, in my opinion - thank you to all who attended and participated. We received a lot of very good advice, and we have a lot of work to do. It seems that the first order of business is really getting our use cases and charter squared off, with a goal of getting an acceptable draft charter done within the next four to six weeks. I propose that we shoot for five weeks (September 7), provided that is enough time to submit before Atlanta. With respect to the use cases, there seemed to be some agreement that we would focus on use cases 1 and 3 ("Acceptance and Enforcement of Acceptable State" and "Security Control Verification and Monitoring" respectively). I'm assuming that Dave will continue acting as the editor for the use case document and that Kent will continue acting as the editor for the charter. There has already been excellent discussion on the list regarding the above, and I hope to see this continue. Dave and Kent, can each of you provide a list of things that need to get done for each document so we can effectively track the work (I'm willing to do the tracking)? I would also like to propose that we consider two additional informational drafts. The first would provide additional background and motivation for the use cases - essentially tying them, in a very generic way, to the business processes that would leverage security automation and continuous monitoring standards to their benefit. The second would be an informational glossary sacm, and other efforts, could leverage to help us all stay on the same page. If these are things the community would find useful, I would certainly volunteer to draft them. Finally, if it makes sense, perhaps we should set up a weekly call for the next few weeks, especially with respect to the charter. I can provide dial-in details for these calls. If this is deemed a good idea by the community, we can work out an acceptable time that will accommodate our international base. Regards, Adam From david.waltermire@nist.gov Fri Aug 3 11:02: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 C166121F8D7E for ; Fri, 3 Aug 2012 11:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjGZ5Pek6TyA for ; Fri, 3 Aug 2012 11:02:58 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 90A9F21F8D7D for ; Fri, 3 Aug 2012 11:02:57 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Aug 2012 14:02:47 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 3 Aug 2012 14:02:55 -0400 From: "Waltermire, David A." To: Adam Montville , "sacm@ietf.org" Date: Fri, 3 Aug 2012 14:01:49 -0400 Thread-Topic: Next Steps Thread-Index: AQHNcZ99SdR7e+RjNUS49AhL6k9SWJdIXQED 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] Next Steps X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:02:59 -0000 Adam, Thanks for sending this out. I agree on your timeframe for the charter and would be glad to participate in the effort to complete the draft. I am also happy to continue editing the use case draft. I like your idea of providing some background information and use case motivations. I also see a glossary as useful. In these cases, there are existing sections in the use cases draft that map to these items. The "1. Introduction" and "2 Key Concepts" sections would be a good place for the background information. One possible approach for capturing motivations might be to include them in each of the use case sections. We could add a new section for a glossary maybe under key concepts or as a standalone section. I personally like this approach better than creating multiple drafts that would make the information much more disconnected and harder to follow. If this approach is acceptable, would you be interested in co-editing the use case draft with me to work in this content? As for holding weekly meetings, I think this is a great idea that will allow us to move more efficiently. Would you send 2-3 day/time options that we can use to develop some consensus on a timeslot? Thanks, Dave ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Adam Montville [amontville@tripwire.com] Sent: Friday, August 03, 2012 7:43 PM To: sacm@ietf.org Subject: [sacm] Next Steps All: Yesterday's meeting went very well, in my opinion - thank you to all who attended and participated. We received a lot of very good advice, and we have a lot of work to do. It seems that the first order of business is really getting our use cases and charter squared off, with a goal of getting an acceptable draft charter done within the next four to six weeks. I propose that we shoot for five weeks (September 7), provided that is enough time to submit before Atlanta. With respect to the use cases, there seemed to be some agreement that we would focus on use cases 1 and 3 ("Acceptance and Enforcement of Acceptable State" and "Security Control Verification and Monitoring" respectively). I'm assuming that Dave will continue acting as the editor for the use case document and that Kent will continue acting as the editor for the charter. There has already been excellent discussion on the list regarding the above, and I hope to see this continue. Dave and Kent, can each of you provide a list of things that need to get done for each document so we can effectively track the work (I'm willing to do the tracking)? I would also like to propose that we consider two additional informational drafts. The first would provide additional background and motivation for the use cases - essentially tying them, in a very generic way, to the business processes that would leverage security automation and continuous monitoring standards to their benefit. The second would be an informational glossary sacm, and other efforts, could leverage to help us all stay on the same page. If these are things the community would find useful, I would certainly volunteer to draft them. Finally, if it makes sense, perhaps we should set up a weekly call for the next few weeks, especially with respect to the charter. I can provide dial-in details for these calls. If this is deemed a good idea by the community, we can work out an acceptable time that will accommodate our international base. Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Fri Aug 3 12:32: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 7CCCD21E804C for ; Fri, 3 Aug 2012 12:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpqhJlsxeEcX for ; Fri, 3 Aug 2012 12:32:21 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id DB30511E80D7 for ; Fri, 3 Aug 2012 12:32:20 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Aug 2012 15:31:50 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 3 Aug 2012 15:31:59 -0400 From: "Waltermire, David A." To: "sacm@ietf.org" Date: Fri, 3 Aug 2012 15:30:52 -0400 Thread-Topic: Interop testing Thread-Index: AQHNca5+vj+bRlxdgE+kOgZq3aShJg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C4930B9FDB6522MBCLUSTERxcha_" MIME-Version: 1.0 Subject: [sacm] Interop testing X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 19:32:21 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B9FDB6522MBCLUSTERxcha_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Another thing we might want to address in the charter is some concept of in= terop testing as part of the I/D development process. This has been discus= sed within the Security Automation community historically, but was not ment= ioned during the side meeting. Dave --_000_D7A0423E5E193F40BE6E94126930C4930B9FDB6522MBCLUSTERxcha_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Another= thing we might want to address in the charter is some concept of=  interop testing as part of the I/D development process.  = This has been discussed within the Security Automation community historically, but was not mentioned during the side meeting.
 
Dave
--_000_D7A0423E5E193F40BE6E94126930C4930B9FDB6522MBCLUSTERxcha_-- From amontville@tripwire.com Fri Aug 3 13:03: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 8EBF621F8DBA for ; Fri, 3 Aug 2012 13:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.865 X-Spam-Level: X-Spam-Status: No, score=-4.865 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQAr4ict2tdm for ; Fri, 3 Aug 2012 13:03:01 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1A721F8DB4 for ; Fri, 3 Aug 2012 13:03:01 -0700 (PDT) Received: from mail62-tx2-R.bigfish.com (10.9.14.251) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 Aug 2012 20:03:01 +0000 Received: from mail62-tx2 (localhost [127.0.0.1]) by mail62-tx2-R.bigfish.com (Postfix) with ESMTP id 1FA1D601C4; Fri, 3 Aug 2012 20:03:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zzbb2dI98dI9371I148cI1432I4015Izz1202hzz1033IL8275dhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail62-tx2 (localhost.localdomain [127.0.0.1]) by mail62-tx2 (MessageSwitch) id 1344024178834759_26173; Fri, 3 Aug 2012 20:02:58 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.237]) by mail62-tx2.bigfish.com (Postfix) with ESMTP id BF8AC1600AE; Fri, 3 Aug 2012 20:02:58 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 Aug 2012 20:02:58 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Aug 2012 13:05:03 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Fri, 3 Aug 2012 13:02:57 -0700 From: Adam Montville To: "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: Next Steps Thread-Index: AQHNcZ99SdR7e+RjNUS49AhL6k9SWJdIXQEDgAAlsgA= Date: Fri, 3 Aug 2012 20:02:56 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.16.97.136] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] Next Steps X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 20:03:02 -0000 On 8/3/12 11:01 AM, "Waltermire, David A." wrote: >Adam, > >Thanks for sending this out. You're welcome. >I agree on your timeframe for the charter and would be glad to >participate in the effort to complete the draft. Great! > >I am also happy to continue editing the use case draft. I like your idea >of providing some background information and use case motivations. I >also see a glossary as useful. In these cases, there are existing >sections in the use cases draft that map to these items. The "1. >Introduction" and "2 Key Concepts" sections would be a good place for the >background information. One possible approach for capturing motivations >might be to include them in each of the use case sections. We could add >a new section for a glossary maybe under key concepts or as a standalone >section. I personally like this approach better than creating multiple >drafts that would make the information much more disconnected and harder >to follow. I'm not certain I agree (which is not to say that I disagree). The motivations for these use cases are, when you trace it all back to business processes, not brief. The skeletal document I've been working on already contains about five pages of overview and expands to ten when simply enumerating information security controls and required models (where the enumerated controls and models are only placeholders). Perhaps not all of that information is perceived as being required, but I think this type of information would be useful in setting the exact context in which we intend to work and from which the use cases are derived. In short, I think it would enable us to be much more focused in our efforts. That said, we could pare the overarching information down a bit to fit it in to the use case document and decide at a later time whether a more comprehensive, distinct document is required based on perceived demand from the sacm and other communities. With respect to the glossary, I'm thinking that this will be more or less a living document with published updates every so often as we address new problems. Does a referential glossary of terms belong in a use case document? If I approach this effort using software architecture communication mechanisms as a guide, the glossary would be distinct from other documents. In fact, if we take that type of approach, we would be inclined to create a couple of different "meta" documents, which to me would include a "frame of reference," "derived use cases," and a "glossary" to start. Our data models would then be the conceptual details of the use cases we decide to tackle, and the specific bindings (I.e. to XML, or whatever) would be the lower-level logical details. Using this type of approach might prove to be useful not only to us, but to the other IETF working groups with which we need to cooperate. This seems like a lot of work to get done within a short timeframe, but I'm willing to put in a little extra effort over the short term to help ensure our long term success. > >If this approach is acceptable, would you be interested in co-editing the >use case draft with me to work in this content? Yes. > >As for holding weekly meetings, I think this is a great idea that will >allow us to move more efficiently. Would you send 2-3 day/time options >that we can use to develop some consensus on a timeslot? Yes. How would these options work for everyone wishing to participate in these meetings (all times Eastern)? Monday 08:00 - 09:00 Tuesday 08:00 - 09:00 Thursday 08:00 - 09:00 > >Thanks, >Dave >________________________________________ >From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Adam >Montville [amontville@tripwire.com] >Sent: Friday, August 03, 2012 7:43 PM >To: sacm@ietf.org >Subject: [sacm] Next Steps > >All: > >Yesterday's meeting went very well, in my opinion - thank you to all who >attended and participated. We received a lot of very good advice, and we >have a lot of work to do. It seems that the first order of business is >really getting our use cases and charter squared off, with a goal of >getting an acceptable draft charter done within the next four to six >weeks. I propose that we shoot for five weeks (September 7), provided >that is enough time to submit before Atlanta. > >With respect to the use cases, there seemed to be some agreement that we >would focus on use cases 1 and 3 ("Acceptance and Enforcement of >Acceptable State" and "Security Control Verification and Monitoring" >respectively). I'm assuming that Dave will continue acting as the editor >for the use case document and that Kent will continue acting as the editor >for the charter. > >There has already been excellent discussion on the list regarding the >above, and I hope to see this continue. Dave and Kent, can each of you >provide a list of things that need to get done for each document so we can >effectively track the work (I'm willing to do the tracking)? > >I would also like to propose that we consider two additional informational >drafts. The first would provide additional background and motivation for >the use cases - essentially tying them, in a very generic way, to the >business processes that would leverage security automation and continuous >monitoring standards to their benefit. The second would be an >informational glossary sacm, and other efforts, could leverage to help us >all stay on the same page. > >If these are things the community would find useful, I would certainly >volunteer to draft them. > >Finally, if it makes sense, perhaps we should set up a weekly call for the >next few weeks, especially with respect to the charter. I can provide >dial-in details for these calls. If this is deemed a good idea by the >community, we can work out an acceptable time that will accommodate our >international base. > >Regards, > >Adam > > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm > From amontville@tripwire.com Fri Aug 3 13:05: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 2E68321F8DC3 for ; Fri, 3 Aug 2012 13:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.018 X-Spam-Level: X-Spam-Status: No, score=-4.018 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LQRHX5PNYdk for ; Fri, 3 Aug 2012 13:05:52 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id ACC3F21F8DC0 for ; Fri, 3 Aug 2012 13:05:52 -0700 (PDT) Received: from mail185-co1-R.bigfish.com (10.243.78.252) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 Aug 2012 20:05:51 +0000 Received: from mail185-co1 (localhost [127.0.0.1]) by mail185-co1-R.bigfish.com (Postfix) with ESMTP id 83F652C0341; Fri, 3 Aug 2012 20:05:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371Izz1202hzz1033IL8275dhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail185-co1 (localhost.localdomain [127.0.0.1]) by mail185-co1 (MessageSwitch) id 1344024349451111_25943; Fri, 3 Aug 2012 20:05:49 +0000 (UTC) Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.239]) by mail185-co1.bigfish.com (Postfix) with ESMTP id 6A3FC1C0044; Fri, 3 Aug 2012 20:05:49 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 Aug 2012 20:05:47 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Aug 2012 13:07:52 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Fri, 3 Aug 2012 13:05:46 -0700 From: Adam Montville To: "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: [sacm] Interop testing Thread-Index: AQHNca5+vj+bRlxdgE+kOgZq3aShJpdIg10A Date: Fri, 3 Aug 2012 20:05:45 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.16.97.136] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] Interop testing X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 20:05:53 -0000 From: , "David A." > Date: Friday, August 3, 2012 12:30 PM To: "sacm@ietf.org" > Subject: [sacm] Interop testing Another thing we might want to address in the charter is some concept of in= terop testing as part of the I/D development process. This has been discus= sed within the Security Automation community historically, but was not ment= ioned during the side meeting. This seems like a good idea. Dave From david.waltermire@nist.gov Fri Aug 3 13:09:22 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 E147121F8DD4 for ; Fri, 3 Aug 2012 13:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.902 X-Spam-Level: X-Spam-Status: No, score=-5.902 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBhCB0PvMZ39 for ; Fri, 3 Aug 2012 13:09:22 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id D093A21F8DC3 for ; Fri, 3 Aug 2012 13:09:21 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Aug 2012 16:08:45 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 3 Aug 2012 16:08:59 -0400 From: "Waltermire, David A." To: "'amontville@tripwire.com'" , "'sacm@ietf.org'" Date: Fri, 3 Aug 2012 16:07:53 -0400 Thread-Topic: Next Steps Thread-Index: AQHNcZ99SdR7e+RjNUS49AhL6k9SWJdIXQEDgAAlsgCAAAFiPg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Next Steps X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 20:09:23 -0000 Regarding the Use Case/Background/Glossary discussion, it would be interest= ing to consider what IETF WGs have done in this regard. I think it makes s= ense to follow the "IETF approach" to this kind of exercise. Does anyone have any guidance based on historic examples? Dave ----- Original Message ----- From: Adam Montville To: Waltermire, David A.; sacm@ietf.org Sent: Fri Aug 03 16:02:56 2012=0A= Subject: Re: Next Steps On 8/3/12 11:01 AM, "Waltermire, David A." wrote: >Adam, > >Thanks for sending this out. You're welcome. >I agree on your timeframe for the charter and would be glad to >participate in the effort to complete the draft. Great! > >I am also happy to continue editing the use case draft. I like your idea >of providing some background information and use case motivations. I >also see a glossary as useful. In these cases, there are existing >sections in the use cases draft that map to these items. The "1. >Introduction" and "2 Key Concepts" sections would be a good place for the >background information. One possible approach for capturing motivations >might be to include them in each of the use case sections. We could add >a new section for a glossary maybe under key concepts or as a standalone >section. I personally like this approach better than creating multiple >drafts that would make the information much more disconnected and harder >to follow. I'm not certain I agree (which is not to say that I disagree). The motivations for these use cases are, when you trace it all back to business processes, not brief. The skeletal document I've been working on already contains about five pages of overview and expands to ten when simply enumerating information security controls and required models (where the enumerated controls and models are only placeholders). Perhaps not all of that information is perceived as being required, but I think this type of information would be useful in setting the exact context in which we intend to work and from which the use cases are derived. In short, I think it would enable us to be much more focused in our efforts. That said, we could pare the overarching information down a bit to fit it in to the use case document and decide at a later time whether a more comprehensive, distinct document is required based on perceived demand from the sacm and other communities. With respect to the glossary, I'm thinking that this will be more or less a living document with published updates every so often as we address new problems. Does a referential glossary of terms belong in a use case document? If I approach this effort using software architecture communication mechanisms as a guide, the glossary would be distinct from other documents. In fact, if we take that type of approach, we would be inclined to create a couple of different "meta" documents, which to me would include a "frame of reference," "derived use cases," and a "glossary" to start. Our data models would then be the conceptual details of the use cases we decide to tackle, and the specific bindings (I.e. to XML, or whatever) would be the lower-level logical details. Using this type of approach might prove to be useful not only to us, but to the other IETF working groups with which we need to cooperate. This seems like a lot of work to get done within a short timeframe, but I'm willing to put in a little extra effort over the short term to help ensure our long term success. > >If this approach is acceptable, would you be interested in co-editing the >use case draft with me to work in this content? Yes. > >As for holding weekly meetings, I think this is a great idea that will >allow us to move more efficiently. Would you send 2-3 day/time options >that we can use to develop some consensus on a timeslot? Yes. How would these options work for everyone wishing to participate in these meetings (all times Eastern)? Monday 08:00 - 09:00 Tuesday 08:00 - 09:00 Thursday 08:00 - 09:00 > >Thanks, >Dave >________________________________________ >From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Adam >Montville [amontville@tripwire.com] >Sent: Friday, August 03, 2012 7:43 PM >To: sacm@ietf.org >Subject: [sacm] Next Steps > >All: > >Yesterday's meeting went very well, in my opinion - thank you to all who >attended and participated. We received a lot of very good advice, and we >have a lot of work to do. It seems that the first order of business is >really getting our use cases and charter squared off, with a goal of >getting an acceptable draft charter done within the next four to six >weeks. I propose that we shoot for five weeks (September 7), provided >that is enough time to submit before Atlanta. > >With respect to the use cases, there seemed to be some agreement that we >would focus on use cases 1 and 3 ("Acceptance and Enforcement of >Acceptable State" and "Security Control Verification and Monitoring" >respectively). I'm assuming that Dave will continue acting as the editor >for the use case document and that Kent will continue acting as the editor >for the charter. > >There has already been excellent discussion on the list regarding the >above, and I hope to see this continue. Dave and Kent, can each of you >provide a list of things that need to get done for each document so we can >effectively track the work (I'm willing to do the tracking)? > >I would also like to propose that we consider two additional informational >drafts. The first would provide additional background and motivation for >the use cases - essentially tying them, in a very generic way, to the >business processes that would leverage security automation and continuous >monitoring standards to their benefit. The second would be an >informational glossary sacm, and other efforts, could leverage to help us >all stay on the same page. > >If these are things the community would find useful, I would certainly >volunteer to draft them. > >Finally, if it makes sense, perhaps we should set up a weekly call for the >next few weeks, especially with respect to the charter. I can provide >dial-in details for these calls. If this is deemed a good idea by the >community, we can work out an acceptable time that will accommodate our >international base. > >Regards, > >Adam > > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm > From turners@ieca.com Fri Aug 3 14:29: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 4881D21E805D for ; Fri, 3 Aug 2012 14:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.148 X-Spam-Level: X-Spam-Status: No, score=-101.148 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIu53DB34Cgd for ; Fri, 3 Aug 2012 14:29:20 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [67.18.22.80]) by ietfa.amsl.com (Postfix) with ESMTP id 649B811E80A3 for ; Fri, 3 Aug 2012 14:29:20 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 9DB4BD3D8897A; Fri, 3 Aug 2012 16:29:20 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 8C416D3D88921 for ; Fri, 3 Aug 2012 16:29:20 -0500 (CDT) Received: from [130.129.37.148] (port=54879 helo=dhcp-2594.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SxPQt-0000tC-Io; Fri, 03 Aug 2012 16:29:19 -0500 Message-ID: <501C42AE.1010605@ieca.com> Date: Fri, 03 Aug 2012 14:29:18 -0700 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Waltermire, David A." References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-2594.meeting.ietf.org) [130.129.37.148]:54879 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "'sacm@ietf.org'" , "'amontville@tripwire.com'" Subject: Re: [sacm] Next Steps X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 21:29:21 -0000 There are drafts that address each one and then there are drafts that do all three. Regardless of which choice you make somebody will say that it would have better to have made the other choice ;) I'd not spend too much time worrying about which path to take - unless it's going to be 300 pages. spt On 8/3/12 1:07 PM, Waltermire, David A. wrote: > Regarding the Use Case/Background/Glossary discussion, it would be interesting to consider what IETF WGs have done in this regard. I think it makes sense to follow the "IETF approach" to this kind of exercise. > > Does anyone have any guidance based on historic examples? > > Dave > > ----- Original Message ----- > From: Adam Montville > To: Waltermire, David A.; sacm@ietf.org > Sent: Fri Aug 03 16:02:56 2012 > Subject: Re: Next Steps > > > > On 8/3/12 11:01 AM, "Waltermire, David A." > wrote: > >> Adam, >> >> Thanks for sending this out. > > You're welcome. > >> I agree on your timeframe for the charter and would be glad to >> participate in the effort to complete the draft. > > Great! > >> >> I am also happy to continue editing the use case draft. I like your idea >> of providing some background information and use case motivations. I >> also see a glossary as useful. In these cases, there are existing >> sections in the use cases draft that map to these items. The "1. >> Introduction" and "2 Key Concepts" sections would be a good place for the >> background information. One possible approach for capturing motivations >> might be to include them in each of the use case sections. We could add >> a new section for a glossary maybe under key concepts or as a standalone >> section. I personally like this approach better than creating multiple >> drafts that would make the information much more disconnected and harder >> to follow. > > I'm not certain I agree (which is not to say that I disagree). The > motivations for these use cases are, when you trace it all back to > business processes, not brief. The skeletal document I've been working on > already contains about five pages of overview and expands to ten when > simply enumerating information security controls and required models > (where the enumerated controls and models are only placeholders). Perhaps > not all of that information is perceived as being required, but I think > this type of information would be useful in setting the exact context in > which we intend to work and from which the use cases are derived. In > short, I think it would enable us to be much more focused in our efforts. > > That said, we could pare the overarching information down a bit to fit it > in to the use case document and decide at a later time whether a more > comprehensive, distinct document is required based on perceived demand > from the sacm and other communities. > > With respect to the glossary, I'm thinking that this will be more or less > a living document with published updates every so often as we address new > problems. Does a referential glossary of terms belong in a use case > document? If I approach this effort using software architecture > communication mechanisms as a guide, the glossary would be distinct from > other documents. > > In fact, if we take that type of approach, we would be inclined to create > a couple of different "meta" documents, which to me would include a "frame > of reference," "derived use cases," and a "glossary" to start. Our data > models would then be the conceptual details of the use cases we decide to > tackle, and the specific bindings (I.e. to XML, or whatever) would be the > lower-level logical details. Using this type of approach might prove to > be useful not only to us, but to the other IETF working groups with which > we need to cooperate. > > This seems like a lot of work to get done within a short timeframe, but > I'm willing to put in a little extra effort over the short term to help > ensure our long term success. > > >> >> If this approach is acceptable, would you be interested in co-editing the >> use case draft with me to work in this content? > > Yes. > >> >> As for holding weekly meetings, I think this is a great idea that will >> allow us to move more efficiently. Would you send 2-3 day/time options >> that we can use to develop some consensus on a timeslot? > > Yes. How would these options work for everyone wishing to participate in > these meetings (all times Eastern)? > > Monday 08:00 - 09:00 > Tuesday 08:00 - 09:00 > Thursday 08:00 - 09:00 > > > >> >> Thanks, >> Dave >> ________________________________________ >> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Adam >> Montville [amontville@tripwire.com] >> Sent: Friday, August 03, 2012 7:43 PM >> To: sacm@ietf.org >> Subject: [sacm] Next Steps >> >> All: >> >> Yesterday's meeting went very well, in my opinion - thank you to all who >> attended and participated. We received a lot of very good advice, and we >> have a lot of work to do. It seems that the first order of business is >> really getting our use cases and charter squared off, with a goal of >> getting an acceptable draft charter done within the next four to six >> weeks. I propose that we shoot for five weeks (September 7), provided >> that is enough time to submit before Atlanta. >> >> With respect to the use cases, there seemed to be some agreement that we >> would focus on use cases 1 and 3 ("Acceptance and Enforcement of >> Acceptable State" and "Security Control Verification and Monitoring" >> respectively). I'm assuming that Dave will continue acting as the editor >> for the use case document and that Kent will continue acting as the editor >> for the charter. >> >> There has already been excellent discussion on the list regarding the >> above, and I hope to see this continue. Dave and Kent, can each of you >> provide a list of things that need to get done for each document so we can >> effectively track the work (I'm willing to do the tracking)? >> >> I would also like to propose that we consider two additional informational >> drafts. The first would provide additional background and motivation for >> the use cases - essentially tying them, in a very generic way, to the >> business processes that would leverage security automation and continuous >> monitoring standards to their benefit. The second would be an >> informational glossary sacm, and other efforts, could leverage to help us >> all stay on the same page. >> >> If these are things the community would find useful, I would certainly >> volunteer to draft them. >> >> Finally, if it makes sense, perhaps we should set up a weekly call for the >> next few weeks, especially with respect to the charter. I can provide >> dial-in details for these calls. If this is deemed a good idea by the >> community, we can work out an acceptable time that will accommodate our >> international base. >> >> Regards, >> >> Adam >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From shanna@juniper.net Fri Aug 3 14:59: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 9084111E8098 for ; Fri, 3 Aug 2012 14:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.63 X-Spam-Level: X-Spam-Status: No, score=-106.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdeX5rSyGiIr for ; Fri, 3 Aug 2012 14:59:39 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 77AC711E808A for ; Fri, 3 Aug 2012 14:59:39 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUBxJyHPR1cD6rwDrmSnHDFJH8CG8mEDS@postini.com; Fri, 03 Aug 2012 14:59:39 PDT 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; Fri, 3 Aug 2012 14:59:03 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Aug 2012 14:59:03 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 3 Aug 2012 17:58:58 -0400 From: Stephen Hanna To: Adam Montville , "Waltermire, David A." , "sacm@ietf.org" Date: Fri, 3 Aug 2012 17:58:54 -0400 Thread-Topic: [sacm] Interop testing Thread-Index: AQHNca5+vj+bRlxdgE+kOgZq3aShJpdIg10AgAAdDwA= 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Interop testing X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 21:59:40 -0000 I'm a big fan of interop testing. Without it, things just don't interop. And when interop testing is combined into a certification program, customers can find products that actually work together. If they then require certifications in RFPs, vendors have an incentive to make their products interop. There are lots of complexities and pitfalls that we can talk about but... The IETF does not provide interop testing for its standards so I don't think we could/should include that in our charter. Such testing is often provided by outside labs or informal groupings (plugfests) but not by the IETF. So while it's OK to talk a bit about interop testing on IETF lists, such testing is not an IETF activity. At least, that's my understanding. As such, I don't think we should talk about it in the charter. There will be plenty of time to talk about interop testing and certificatio= n and related issues AFTER the charter has been figured out and approved. If other IETF experts want to weigh in on this, feel free. Paul Hoffman (for example) has decades of experience with interop testing for IETF specs= . Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Friday, August 03, 2012 4:06 PM > To: Waltermire, David A.; sacm@ietf.org > Subject: Re: [sacm] Interop testing >=20 >=20 >=20 > From: , "David A." > > > Date: Friday, August 3, 2012 12:30 PM > To: "sacm@ietf.org" > > > Subject: [sacm] Interop testing >=20 > Another thing we might want to address in the charter is some concept > of interop testing as part of the I/D development process. This has > been discussed within the Security Automation community historically, > but was not mentioned during the side meeting. >=20 > This seems like a good idea. >=20 >=20 > Dave >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From shanna@juniper.net Fri Aug 3 15:28: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 9B25B11E80D2 for ; Fri, 3 Aug 2012 15:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.007 X-Spam-Level: X-Spam-Status: No, score=-106.007 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHleoW17Qz-E for ; Fri, 3 Aug 2012 15:28:10 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id B185311E809C for ; Fri, 3 Aug 2012 15:28:07 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUBxQd2HkEfFBTrWpekHmalXudJKaszCl@postini.com; Fri, 03 Aug 2012 15:28:10 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 3 Aug 2012 15:26:02 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 3 Aug 2012 18:26:01 -0400 From: Stephen Hanna To: Sean Turner , "Waltermire, David A." Date: Fri, 3 Aug 2012 18:25:57 -0400 Thread-Topic: [sacm] Next Steps Thread-Index: Ac1xvw4eKc5elntuREaRX/DBu0tIfgABo/RQ Message-ID: References: <501C42AE.1010605@ieca.com> In-Reply-To: <501C42AE.1010605@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'sacm@ietf.org'" , "'amontville@tripwire.com'" Subject: Re: [sacm] Next Steps X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 22:28:11 -0000 Could we get a glimpse at the latest draft Background document before we decide whether it should be added to the use cases? I'd be glad to have more background for the use cases (either as one doc or two) but I'm a bit concerned about documenting business processes. Those vary widely from one enterprise to the next. We shouldn't tie ourselves to one set of business processes. I'm perfectly fine with having a Glossary document, if we end up using a lot of special words. If it's only a few (less than 30-40), it will be easier to just include a glossary section in each document or (maybe even better) in an Overview document with use cases and a reference model, as we did in NEA with RFC 5209. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Sean Turner > Sent: Friday, August 03, 2012 5:29 PM > To: Waltermire, David A. > Cc: 'sacm@ietf.org'; 'amontville@tripwire.com' > Subject: Re: [sacm] Next Steps >=20 > There are drafts that address each one and then there are drafts that > do > all three. Regardless of which choice you make somebody will say that > it would have better to have made the other choice ;) I'd not spend too > much time worrying about which path to take - unless it's going to be > 300 pages. >=20 > spt >=20 > On 8/3/12 1:07 PM, Waltermire, David A. wrote: > > Regarding the Use Case/Background/Glossary discussion, it would be > interesting to consider what IETF WGs have done in this regard. I > think it makes sense to follow the "IETF approach" to this kind of > exercise. > > > > Does anyone have any guidance based on historic examples? > > > > Dave > > > > ----- Original Message ----- > > From: Adam Montville > > To: Waltermire, David A.; sacm@ietf.org > > Sent: Fri Aug 03 16:02:56 2012 > > Subject: Re: Next Steps > > > > > > > > On 8/3/12 11:01 AM, "Waltermire, David A." > > > wrote: > > > >> Adam, > >> > >> Thanks for sending this out. > > > > You're welcome. > > > >> I agree on your timeframe for the charter and would be glad to > >> participate in the effort to complete the draft. > > > > Great! > > > >> > >> I am also happy to continue editing the use case draft. I like your > idea > >> of providing some background information and use case motivations. > I > >> also see a glossary as useful. In these cases, there are existing > >> sections in the use cases draft that map to these items. The "1. > >> Introduction" and "2 Key Concepts" sections would be a good place > for the > >> background information. One possible approach for capturing > motivations > >> might be to include them in each of the use case sections. We could > add > >> a new section for a glossary maybe under key concepts or as a > standalone > >> section. I personally like this approach better than creating > multiple > >> drafts that would make the information much more disconnected and > harder > >> to follow. > > > > I'm not certain I agree (which is not to say that I disagree). The > > motivations for these use cases are, when you trace it all back to > > business processes, not brief. The skeletal document I've been > working on > > already contains about five pages of overview and expands to ten when > > simply enumerating information security controls and required models > > (where the enumerated controls and models are only placeholders). > Perhaps > > not all of that information is perceived as being required, but I > think > > this type of information would be useful in setting the exact context > in > > which we intend to work and from which the use cases are derived. In > > short, I think it would enable us to be much more focused in our > efforts. > > > > That said, we could pare the overarching information down a bit to > fit it > > in to the use case document and decide at a later time whether a more > > comprehensive, distinct document is required based on perceived > demand > > from the sacm and other communities. > > > > With respect to the glossary, I'm thinking that this will be more or > less > > a living document with published updates every so often as we address > new > > problems. Does a referential glossary of terms belong in a use case > > document? If I approach this effort using software architecture > > communication mechanisms as a guide, the glossary would be distinct > from > > other documents. > > > > In fact, if we take that type of approach, we would be inclined to > create > > a couple of different "meta" documents, which to me would include a > "frame > > of reference," "derived use cases," and a "glossary" to start. Our > data > > models would then be the conceptual details of the use cases we > decide to > > tackle, and the specific bindings (I.e. to XML, or whatever) would be > the > > lower-level logical details. Using this type of approach might prove > to > > be useful not only to us, but to the other IETF working groups with > which > > we need to cooperate. > > > > This seems like a lot of work to get done within a short timeframe, > but > > I'm willing to put in a little extra effort over the short term to > help > > ensure our long term success. > > > > > >> > >> If this approach is acceptable, would you be interested in co- > editing the > >> use case draft with me to work in this content? > > > > Yes. > > > >> > >> As for holding weekly meetings, I think this is a great idea that > will > >> allow us to move more efficiently. Would you send 2-3 day/time > options > >> that we can use to develop some consensus on a timeslot? > > > > Yes. How would these options work for everyone wishing to > participate in > > these meetings (all times Eastern)? > > > > Monday 08:00 - 09:00 > > Tuesday 08:00 - 09:00 > > Thursday 08:00 - 09:00 > > > > > > > >> > >> Thanks, > >> Dave > >> ________________________________________ > >> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of > Adam > >> Montville [amontville@tripwire.com] > >> Sent: Friday, August 03, 2012 7:43 PM > >> To: sacm@ietf.org > >> Subject: [sacm] Next Steps > >> > >> All: > >> > >> Yesterday's meeting went very well, in my opinion - thank you to all > who > >> attended and participated. We received a lot of very good advice, > and we > >> have a lot of work to do. It seems that the first order of business > is > >> really getting our use cases and charter squared off, with a goal of > >> getting an acceptable draft charter done within the next four to six > >> weeks. I propose that we shoot for five weeks (September 7), > provided > >> that is enough time to submit before Atlanta. > >> > >> With respect to the use cases, there seemed to be some agreement > that we > >> would focus on use cases 1 and 3 ("Acceptance and Enforcement of > >> Acceptable State" and "Security Control Verification and Monitoring" > >> respectively). I'm assuming that Dave will continue acting as the > editor > >> for the use case document and that Kent will continue acting as the > editor > >> for the charter. > >> > >> There has already been excellent discussion on the list regarding > the > >> above, and I hope to see this continue. Dave and Kent, can each of > you > >> provide a list of things that need to get done for each document so > we can > >> effectively track the work (I'm willing to do the tracking)? > >> > >> I would also like to propose that we consider two additional > informational > >> drafts. The first would provide additional background and > motivation for > >> the use cases - essentially tying them, in a very generic way, to > the > >> business processes that would leverage security automation and > continuous > >> monitoring standards to their benefit. The second would be an > >> informational glossary sacm, and other efforts, could leverage to > help us > >> all stay on the same page. > >> > >> If these are things the community would find useful, I would > certainly > >> volunteer to draft them. > >> > >> Finally, if it makes sense, perhaps we should set up a weekly call > for the > >> next few weeks, especially with respect to the charter. I can > provide > >> dial-in details for these calls. If this is deemed a good idea by > the > >> community, we can work out an acceptable time that will accommodate > our > >> international base. > >> > >> Regards, > >> > >> Adam > >> > >> > >> _______________________________________________ > >> sacm mailing list > >> sacm@ietf.org > >> https://www.ietf.org/mailman/listinfo/sacm > >> > > > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From amontville@tripwire.com Fri Aug 3 15:38: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 6F46511E80E4 for ; Fri, 3 Aug 2012 15:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=-1.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOI45oRtKYWB for ; Fri, 3 Aug 2012 15:38:40 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 076B411E80D9 for ; Fri, 3 Aug 2012 15:38:39 -0700 (PDT) Received: from mail70-am1-R.bigfish.com (10.3.201.241) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 Aug 2012 22:38:38 +0000 Received: from mail70-am1 (localhost [127.0.0.1]) by mail70-am1-R.bigfish.com (Postfix) with ESMTP id D5BC0420375; Fri, 3 Aug 2012 22:38:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -31 X-BigFish: VPS-31(zzbb2dI98dI9371I148cI542M1432I4015Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h944hd25he5bhf0ah107ah) Received: from mail70-am1 (localhost.localdomain [127.0.0.1]) by mail70-am1 (MessageSwitch) id 1344033517785231_26986; Fri, 3 Aug 2012 22:38:37 +0000 (UTC) Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.233]) by mail70-am1.bigfish.com (Postfix) with ESMTP id BBFB73000C1; Fri, 3 Aug 2012 22:38:37 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 Aug 2012 22:38:37 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Aug 2012 15:40:40 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Fri, 3 Aug 2012 15:38:34 -0700 From: Adam Montville To: Stephen Hanna Thread-Topic: [sacm] Next Steps Thread-Index: AQHNcZ99SdR7e+RjNUS49AhL6k9SWJdIXQEDgAAlsgCAAAFiPoAAjBgAgAAP1ID//44skQ== Date: Fri, 3 Aug 2012 22:38:33 +0000 Message-ID: <715449D4-4A6A-4429-A81B-484123580E86@tripwire.com> References: <501C42AE.1010605@ieca.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Cc: Sean Turner , "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Next Steps X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 22:38:41 -0000 I'll get something out tomorrow. Just landed. Sent from my iPhone On Aug 3, 2012, at 3:28 PM, "Stephen Hanna" wrote: > Could we get a glimpse at the latest draft Background document before > we decide whether it should be added to the use cases? I'd be glad > to have more background for the use cases (either as one doc or two) > but I'm a bit concerned about documenting business processes. Those > vary widely from one enterprise to the next. We shouldn't tie > ourselves to one set of business processes. >=20 > I'm perfectly fine with having a Glossary document, if we end up > using a lot of special words. If it's only a few (less than 30-40), > it will be easier to just include a glossary section in each document > or (maybe even better) in an Overview document with use cases and a > reference model, as we did in NEA with RFC 5209. >=20 > Thanks, >=20 > Steve >=20 >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Sean Turner >> Sent: Friday, August 03, 2012 5:29 PM >> To: Waltermire, David A. >> Cc: 'sacm@ietf.org'; 'amontville@tripwire.com' >> Subject: Re: [sacm] Next Steps >>=20 >> There are drafts that address each one and then there are drafts that >> do >> all three. Regardless of which choice you make somebody will say that >> it would have better to have made the other choice ;) I'd not spend too >> much time worrying about which path to take - unless it's going to be >> 300 pages. >>=20 >> spt >>=20 >> On 8/3/12 1:07 PM, Waltermire, David A. wrote: >>> Regarding the Use Case/Background/Glossary discussion, it would be >> interesting to consider what IETF WGs have done in this regard. I >> think it makes sense to follow the "IETF approach" to this kind of >> exercise. >>>=20 >>> Does anyone have any guidance based on historic examples? >>>=20 >>> Dave >>>=20 >>> ----- Original Message ----- >>> From: Adam Montville >>> To: Waltermire, David A.; sacm@ietf.org >>> Sent: Fri Aug 03 16:02:56 2012 >>> Subject: Re: Next Steps >>>=20 >>>=20 >>>=20 >>> On 8/3/12 11:01 AM, "Waltermire, David A." >> >>> wrote: >>>=20 >>>> Adam, >>>>=20 >>>> Thanks for sending this out. >>>=20 >>> You're welcome. >>>=20 >>>> I agree on your timeframe for the charter and would be glad to >>>> participate in the effort to complete the draft. >>>=20 >>> Great! >>>=20 >>>>=20 >>>> I am also happy to continue editing the use case draft. I like your >> idea >>>> of providing some background information and use case motivations. >> I >>>> also see a glossary as useful. In these cases, there are existing >>>> sections in the use cases draft that map to these items. The "1. >>>> Introduction" and "2 Key Concepts" sections would be a good place >> for the >>>> background information. One possible approach for capturing >> motivations >>>> might be to include them in each of the use case sections. We could >> add >>>> a new section for a glossary maybe under key concepts or as a >> standalone >>>> section. I personally like this approach better than creating >> multiple >>>> drafts that would make the information much more disconnected and >> harder >>>> to follow. >>>=20 >>> I'm not certain I agree (which is not to say that I disagree). The >>> motivations for these use cases are, when you trace it all back to >>> business processes, not brief. The skeletal document I've been >> working on >>> already contains about five pages of overview and expands to ten when >>> simply enumerating information security controls and required models >>> (where the enumerated controls and models are only placeholders). >> Perhaps >>> not all of that information is perceived as being required, but I >> think >>> this type of information would be useful in setting the exact context >> in >>> which we intend to work and from which the use cases are derived. In >>> short, I think it would enable us to be much more focused in our >> efforts. >>>=20 >>> That said, we could pare the overarching information down a bit to >> fit it >>> in to the use case document and decide at a later time whether a more >>> comprehensive, distinct document is required based on perceived >> demand >>> from the sacm and other communities. >>>=20 >>> With respect to the glossary, I'm thinking that this will be more or >> less >>> a living document with published updates every so often as we address >> new >>> problems. Does a referential glossary of terms belong in a use case >>> document? If I approach this effort using software architecture >>> communication mechanisms as a guide, the glossary would be distinct >> from >>> other documents. >>>=20 >>> In fact, if we take that type of approach, we would be inclined to >> create >>> a couple of different "meta" documents, which to me would include a >> "frame >>> of reference," "derived use cases," and a "glossary" to start. Our >> data >>> models would then be the conceptual details of the use cases we >> decide to >>> tackle, and the specific bindings (I.e. to XML, or whatever) would be >> the >>> lower-level logical details. Using this type of approach might prove >> to >>> be useful not only to us, but to the other IETF working groups with >> which >>> we need to cooperate. >>>=20 >>> This seems like a lot of work to get done within a short timeframe, >> but >>> I'm willing to put in a little extra effort over the short term to >> help >>> ensure our long term success. >>>=20 >>>=20 >>>>=20 >>>> If this approach is acceptable, would you be interested in co- >> editing the >>>> use case draft with me to work in this content? >>>=20 >>> Yes. >>>=20 >>>>=20 >>>> As for holding weekly meetings, I think this is a great idea that >> will >>>> allow us to move more efficiently. Would you send 2-3 day/time >> options >>>> that we can use to develop some consensus on a timeslot? >>>=20 >>> Yes. How would these options work for everyone wishing to >> participate in >>> these meetings (all times Eastern)? >>>=20 >>> Monday 08:00 - 09:00 >>> Tuesday 08:00 - 09:00 >>> Thursday 08:00 - 09:00 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Thanks, >>>> Dave >>>> ________________________________________ >>>> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of >> Adam >>>> Montville [amontville@tripwire.com] >>>> Sent: Friday, August 03, 2012 7:43 PM >>>> To: sacm@ietf.org >>>> Subject: [sacm] Next Steps >>>>=20 >>>> All: >>>>=20 >>>> Yesterday's meeting went very well, in my opinion - thank you to all >> who >>>> attended and participated. We received a lot of very good advice, >> and we >>>> have a lot of work to do. It seems that the first order of business >> is >>>> really getting our use cases and charter squared off, with a goal of >>>> getting an acceptable draft charter done within the next four to six >>>> weeks. I propose that we shoot for five weeks (September 7), >> provided >>>> that is enough time to submit before Atlanta. >>>>=20 >>>> With respect to the use cases, there seemed to be some agreement >> that we >>>> would focus on use cases 1 and 3 ("Acceptance and Enforcement of >>>> Acceptable State" and "Security Control Verification and Monitoring" >>>> respectively). I'm assuming that Dave will continue acting as the >> editor >>>> for the use case document and that Kent will continue acting as the >> editor >>>> for the charter. >>>>=20 >>>> There has already been excellent discussion on the list regarding >> the >>>> above, and I hope to see this continue. Dave and Kent, can each of >> you >>>> provide a list of things that need to get done for each document so >> we can >>>> effectively track the work (I'm willing to do the tracking)? >>>>=20 >>>> I would also like to propose that we consider two additional >> informational >>>> drafts. The first would provide additional background and >> motivation for >>>> the use cases - essentially tying them, in a very generic way, to >> the >>>> business processes that would leverage security automation and >> continuous >>>> monitoring standards to their benefit. The second would be an >>>> informational glossary sacm, and other efforts, could leverage to >> help us >>>> all stay on the same page. >>>>=20 >>>> If these are things the community would find useful, I would >> certainly >>>> volunteer to draft them. >>>>=20 >>>> Finally, if it makes sense, perhaps we should set up a weekly call >> for the >>>> next few weeks, especially with respect to the charter. I can >> provide >>>> dial-in details for these calls. If this is deemed a good idea by >> the >>>> community, we can work out an acceptable time that will accommodate >> our >>>> international base. >>>>=20 >>>> Regards, >>>>=20 >>>> Adam >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >>>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >=20 From michael.hammer@yaanatech.com Fri Aug 3 15:48: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 51C1711E809C for ; Fri, 3 Aug 2012 15:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foRTlfBIzH-k for ; Fri, 3 Aug 2012 15:48:57 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 12A2021F8D22 for ; Fri, 3 Aug 2012 15:48:57 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Fri, 3 Aug 2012 15:48:56 -0700 From: Michael Hammer To: "david.waltermire@nist.gov" , "amontville@tripwire.com" , "sacm@ietf.org" Thread-Topic: Next Steps Thread-Index: AQHNcZ99SdR7e+RjNUS49AhL6k9SWJdIXQEDgAAlsgCAAAFiPoAALKPQ Date: Fri, 3 Aug 2012 22:48:55 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB308D18F15@ex2k10mb2.corp.yaanatech.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.14] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_04ED_01CD71A8.A1E81B80" MIME-Version: 1.0 Subject: Re: [sacm] Next Steps X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 22:48:58 -0000 ------=_NextPart_000_04ED_01CD71A8.A1E81B80 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I think there is lots of flexibility as long as it is an ID. You can always merge IDs later, if that makes sense. Or split as well. After all, they expire in 6 months anyway. :) Mike -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Friday, August 03, 2012 4:08 PM To: 'amontville@tripwire.com'; 'sacm@ietf.org' Subject: Re: [sacm] Next Steps Regarding the Use Case/Background/Glossary discussion, it would be interesting to consider what IETF WGs have done in this regard. I think it makes sense to follow the "IETF approach" to this kind of exercise. Does anyone have any guidance based on historic examples? Dave ----- Original Message ----- From: Adam Montville To: Waltermire, David A.; sacm@ietf.org Sent: Fri Aug 03 16:02:56 2012 Subject: Re: Next Steps On 8/3/12 11:01 AM, "Waltermire, David A." wrote: >Adam, > >Thanks for sending this out. You're welcome. >I agree on your timeframe for the charter and would be glad to >participate in the effort to complete the draft. Great! > >I am also happy to continue editing the use case draft. I like your >idea of providing some background information and use case motivations. >I also see a glossary as useful. In these cases, there are existing >sections in the use cases draft that map to these items. The "1. >Introduction" and "2 Key Concepts" sections would be a good place for >the background information. One possible approach for capturing >motivations might be to include them in each of the use case sections. >We could add a new section for a glossary maybe under key concepts or >as a standalone section. I personally like this approach better than >creating multiple drafts that would make the information much more >disconnected and harder to follow. I'm not certain I agree (which is not to say that I disagree). The motivations for these use cases are, when you trace it all back to business processes, not brief. The skeletal document I've been working on already contains about five pages of overview and expands to ten when simply enumerating information security controls and required models (where the enumerated controls and models are only placeholders). Perhaps not all of that information is perceived as being required, but I think this type of information would be useful in setting the exact context in which we intend to work and from which the use cases are derived. In short, I think it would enable us to be much more focused in our efforts. That said, we could pare the overarching information down a bit to fit it in to the use case document and decide at a later time whether a more comprehensive, distinct document is required based on perceived demand from the sacm and other communities. With respect to the glossary, I'm thinking that this will be more or less a living document with published updates every so often as we address new problems. Does a referential glossary of terms belong in a use case document? If I approach this effort using software architecture communication mechanisms as a guide, the glossary would be distinct from other documents. In fact, if we take that type of approach, we would be inclined to create a couple of different "meta" documents, which to me would include a "frame of reference," "derived use cases," and a "glossary" to start. Our data models would then be the conceptual details of the use cases we decide to tackle, and the specific bindings (I.e. to XML, or whatever) would be the lower-level logical details. Using this type of approach might prove to be useful not only to us, but to the other IETF working groups with which we need to cooperate. This seems like a lot of work to get done within a short timeframe, but I'm willing to put in a little extra effort over the short term to help ensure our long term success. > >If this approach is acceptable, would you be interested in co-editing >the use case draft with me to work in this content? Yes. > >As for holding weekly meetings, I think this is a great idea that will >allow us to move more efficiently. Would you send 2-3 day/time options >that we can use to develop some consensus on a timeslot? Yes. How would these options work for everyone wishing to participate in these meetings (all times Eastern)? Monday 08:00 - 09:00 Tuesday 08:00 - 09:00 Thursday 08:00 - 09:00 > >Thanks, >Dave >________________________________________ >From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Adam >Montville [amontville@tripwire.com] >Sent: Friday, August 03, 2012 7:43 PM >To: sacm@ietf.org >Subject: [sacm] Next Steps > >All: > >Yesterday's meeting went very well, in my opinion - thank you to all >who attended and participated. We received a lot of very good advice, >and we have a lot of work to do. It seems that the first order of >business is really getting our use cases and charter squared off, with >a goal of getting an acceptable draft charter done within the next four >to six weeks. I propose that we shoot for five weeks (September 7), >provided that is enough time to submit before Atlanta. > >With respect to the use cases, there seemed to be some agreement that >we would focus on use cases 1 and 3 ("Acceptance and Enforcement of >Acceptable State" and "Security Control Verification and Monitoring" >respectively). I'm assuming that Dave will continue acting as the >editor for the use case document and that Kent will continue acting as >the editor for the charter. > >There has already been excellent discussion on the list regarding the >above, and I hope to see this continue. Dave and Kent, can each of you >provide a list of things that need to get done for each document so we >can effectively track the work (I'm willing to do the tracking)? > >I would also like to propose that we consider two additional >informational drafts. The first would provide additional background >and motivation for the use cases - essentially tying them, in a very >generic way, to the business processes that would leverage security >automation and continuous monitoring standards to their benefit. The >second would be an informational glossary sacm, and other efforts, >could leverage to help us all stay on the same page. > >If these are things the community would find useful, I would certainly >volunteer to draft them. > >Finally, if it makes sense, perhaps we should set up a weekly call for >the next few weeks, especially with respect to the charter. I can >provide dial-in details for these calls. If this is deemed a good idea >by the community, we can work out an acceptable time that will >accommodate our international base. > >Regards, > >Adam > > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_000_04ED_01CD71A8.A1E81B80 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgw MzIyNDg1NFowIwYJKoZIhvcNAQkEMRYEFOpS+bddr6kUuXft8SUySXlKXzQlMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAiIG1v0myG0tnUrOq8ECYfdy3vIqpfZGbA31j8Zyijh4k Pr/NGHquUzLQBwhbbHEEBI+cOV5CyCoLJbF05pJfcbrEB1KUA0DlniPSBUyAvq+G/0DjhgKCmnBD mLY7nD9TvYesYKsR8btWc0+RrceCvAh9H8hXhACSAVa7SpFYm+MAAAAAAAA= ------=_NextPart_000_04ED_01CD71A8.A1E81B80-- From shanna@juniper.net Fri Aug 3 15:54: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 EEBD621F8D4C for ; Fri, 3 Aug 2012 15:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.584 X-Spam-Level: X-Spam-Status: No, score=-106.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVc6CoJInC2H for ; Fri, 3 Aug 2012 15:54:03 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 4988B21F8D22 for ; Fri, 3 Aug 2012 15:54:01 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUBxWiOG3SOJFuZ5O/396voJN3CYFsqmk@postini.com; Fri, 03 Aug 2012 15:54:03 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 3 Aug 2012 15:51:22 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 3 Aug 2012 18:51:15 -0400 From: Stephen Hanna To: Luis Nunez , Omar Santos Date: Fri, 3 Aug 2012 18:51:11 -0400 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xcgp86Yysxfw7TFu1yMDi4SRArgAKR+Vg Message-ID: References: <93ED586BE669044CA2F91C5F3BE4FD9017B0C651@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 22:54:04 -0000 I certainly agree that connecting NEA and SCAP together is a good first step. TCG has been working on that for several years. Several vendors have demonstrated such capabilities and one shipped this in a product. We should be able to supply an Internet-Draft on the topic with a proposal, if there's interest. As for defining the term "Endpoint", RFC 5209 (the NEA Overview) has the following definition: Endpoint - Any computing device that can be connected to a network. Such devices normally are associated with a particular link layer address before joining the network and potentially an IP address once on the network. This includes: laptops, desktops, servers, cell phones, or any device that may have an IP address. Does that definition look acceptable? I hope so, since it would be confusing to have multiple incompatible definitions of a term in related specs! ;-) I would point out that there's probably more to UC1 and UC3 than just carrying SCAP content over the NEA protocols. For one thing, we'd want to have open, referencable standards for the relevant SCAP specs (or something equivalent, if we can't get acceptable IP rights for the SCAP specs). We might also want to include some standards for response (remediation or mitigation) when problems are detected. Or we could leave that for later. The NEA protocols already include a standard message for remediation instructions. See section 4.2.10 of RFC 5792. This message is very extensible so it can include contents that support automated remediation, in addition to the manual remediation supported by the values defined in that spec for Remediation Parameters Type: URI and String (human-readable instructions). And I also agree on the importance of scoping UC1 and UC3 carefully. We should prioritize which parts of the problem are most urgent and focus on those first. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Luis Nunez > Sent: Friday, August 03, 2012 8:18 AM > To: Omar Santos > Cc: sacm@ietf.org > Subject: Re: [sacm] Proposed use cases to move forward >=20 > Thanks Omar. >=20 > Below are the use cases. I agree we should focus on refining these use > cases to form a charter. I would like to see work that will connect > SCAP endpoint assessments to NEA transport mechanisms and enforcement. > There are synergies between the two that IETF could bind together. > We maybe able to combine both UC1 and UC2 into one use case. Three > things I would like to tie together are: > 1. NEA > 2. SCAP > 3. Endpoints. We need to define what an endpoint is. >=20 > UC1: Assessment and Enforcement of Acceptable State > -Controlling access to networks and services based on the assessment > and analysis of host and/or network state based on machine processable > content. >=20 >=20 > *UC3: Security Control Verification and Monitoring > -Continuous assessment of the implementation and effectiveness of > security controls based on machine processable content. >=20 > -ln >=20 > On Aug 2, 2012, at 11:17 PM, Omar Santos (osantos) wrote: >=20 > > During today's IETF meeting it was suggested to narrow down the scope > of the things to be initially addressed in the potential SACM working > group. Several commented that UC 1 and UC3 may be the best use-cases to > be initially scoped. I also agree that UC 1 & UC 3 are the best > choices; and wanted to take discussion back to the alias. Even though > UC 1 and UC 3 may be the best choice; they also need to be scoped and > defined carefully. > > > > > > Regards, > > > > Omar Santos > > Incident Manager, PSIRT > > Security Research and Operations > > Cisco Systems, Inc. > > Email: os@cisco.com > > Phone: +1 919 392 8635 > > PGP Key: 0x3AF27EDC > > > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From mrex@sap.com Fri Aug 3 19:14:49 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFB321F8DA0 for ; Fri, 3 Aug 2012 19:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.176 X-Spam-Level: X-Spam-Status: No, score=-10.176 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac1LqJqdzd5i for ; Fri, 3 Aug 2012 19:14:48 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5A94221F8D9F for ; Fri, 3 Aug 2012 19:14:48 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q742El6Z028467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 4 Aug 2012 04:14:47 +0200 (MEST) To: sacm@ietf.org Date: Sat, 4 Aug 2012 04:14:47 +0200 (CEST) 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: <20120804021447.174991A119@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Subject: [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: Sat, 04 Aug 2012 02:14:49 -0000 A message on the DANE WG mailing list mentioned this WG and the document http://www.ietf.org/id/draft-waltermire-sacm-use-cases-01.txt I have made a first read of the document and I'm wondering whether people on this list are aware of the legal issues such an idea creates. In Germany, an employer monitoring a company-owned PC that an employee uses for communication (EMail, VoiP, IM) would be unconditionally illegal. -Martin From tony@yaanatech.com Sat Aug 4 07:11: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 C1C7821F8795 for ; Sat, 4 Aug 2012 07:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2QSjVr1WfMl for ; Sat, 4 Aug 2012 07:11:58 -0700 (PDT) Received: from extmail1.prd.yaanatech.com (extmail1.prd.yaanatech.com [205.140.198.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4A55321F8762 for ; Sat, 4 Aug 2012 07:11:58 -0700 (PDT) Received: from [192.168.0.4] (pool-173-72-150-118.clppva.fios.verizon.net [173.72.150.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extmail1.prd.yaanatech.com (Postfix) with ESMTP id 9B17058081; Sat, 4 Aug 2012 14:11:57 +0000 (UTC) Message-ID: <501D2DAC.7000908@yaanatech.com> Date: Sat, 04 Aug 2012 10:11:56 -0400 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: mrex@sap.com References: <20120804021447.174991A119@ld9781.wdf.sap.corp> In-Reply-To: <20120804021447.174991A119@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: 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: Sat, 04 Aug 2012 14:11:58 -0000 Hi Martin, Really? That is not consistent with comments I've seen concerning German law. To be *unconditionally* illegal, would preclude almost any rationally required maintenance or threat mitigation. It is fair to observe that recent German Constitutional Court decisions impose constraints, but they certainly are not "unconditional." --tony On 8/3/2012 10:14 PM, Martin Rex wrote: > In Germany, an employer monitoring a company-owned PC that an employee uses > for communication (EMail, VoiP, IM) would be unconditionally illegal. From amontville@tripwire.com Sat Aug 4 13:26: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 CA20521F87D4 for ; Sat, 4 Aug 2012 13:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.312 X-Spam-Level: X-Spam-Status: No, score=-3.312 tagged_above=-999 required=5 tests=[AWL=-0.953, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sk-QSZvgUp9N for ; Sat, 4 Aug 2012 13:26:10 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id E85AE21F87BD for ; Sat, 4 Aug 2012 13:26:09 -0700 (PDT) Received: from mail26-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Sat, 4 Aug 2012 20:26:08 +0000 Received: from mail26-ch1 (localhost [127.0.0.1]) by mail26-ch1-R.bigfish.com (Postfix) with ESMTP id B68CEC0135; Sat, 4 Aug 2012 20:26:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zzbb2dI98dI9371Ic85eh148cI542M1432I4015Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839he5bhf0ah107ahbe3k34h) Received: from mail26-ch1 (localhost.localdomain [127.0.0.1]) by mail26-ch1 (MessageSwitch) id 1344111966419620_10972; Sat, 4 Aug 2012 20:26:06 +0000 (UTC) Received: from CH1EHSMHS019.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail26-ch1.bigfish.com (Postfix) with ESMTP id 6441B4A0047; Sat, 4 Aug 2012 20:26:06 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 4 Aug 2012 20:26:06 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 4 Aug 2012 13:28:09 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Sat, 4 Aug 2012 13:26:04 -0700 From: Adam Montville To: Stephen Hanna , Sean Turner , "Waltermire, David A." Thread-Topic: [sacm] Next Steps Thread-Index: AQHNcZ99SdR7e+RjNUS49AhL6k9SWJdIXQEDgAAlsgCAAAFiPoAAjBgAgAAP1ICAAPt8gA== Date: Sat, 4 Aug 2012 20:26:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/mixed; boundary="_002_CC42D1C5EB8Bamontvilletripwirecom_" MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Cc: "'sacm@ietf.org'" Subject: Re: [sacm] Next Steps X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 20:26:11 -0000 --_002_CC42D1C5EB8Bamontvilletripwirecom_ Content-Type: text/plain; charset="Windows-1252" Content-ID: <3693A539F340F048BFEBBF9B0F43AE65@tripwire.com> Content-Transfer-Encoding: quoted-printable Hi Steve, Here's what I have. Please note a few things. First, it's still in very rough form and will likely need a few more passes before it would be concise enough (that's my guess anyway). Second, the format may not be correct - I'm experimenting with the nroff editor and formatting can be updated easily enough so it's more important to focus on the message. Third, some stakes are put in the ground with respect to common security controls and derived information models, but they're intended to spark a conversation - not a flame=8A All that said, have a look, and if it makes sense we can continue working on it. Otherwise, we'll let it be and turn immediately to the use cases and charter. Regards, Adam On 8/3/12 3:25 PM, "Stephen Hanna" wrote: >Could we get a glimpse at the latest draft Background document before >we decide whether it should be added to the use cases? I'd be glad >to have more background for the use cases (either as one doc or two) >but I'm a bit concerned about documenting business processes. Those >vary widely from one enterprise to the next. We shouldn't tie >ourselves to one set of business processes. > >I'm perfectly fine with having a Glossary document, if we end up >using a lot of special words. If it's only a few (less than 30-40), >it will be easier to just include a glossary section in each document >or (maybe even better) in an Overview document with use cases and a >reference model, as we did in NEA with RFC 5209. > >Thanks, > >Steve > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Sean Turner >> Sent: Friday, August 03, 2012 5:29 PM >> To: Waltermire, David A. >> Cc: 'sacm@ietf.org'; 'amontville@tripwire.com' >> Subject: Re: [sacm] Next Steps >>=20 >> There are drafts that address each one and then there are drafts that >> do >> all three. Regardless of which choice you make somebody will say that >> it would have better to have made the other choice ;) I'd not spend too >> much time worrying about which path to take - unless it's going to be >> 300 pages. >>=20 >> spt >>=20 >> On 8/3/12 1:07 PM, Waltermire, David A. wrote: >> > Regarding the Use Case/Background/Glossary discussion, it would be >> interesting to consider what IETF WGs have done in this regard. I >> think it makes sense to follow the "IETF approach" to this kind of >> exercise. >> > >> > Does anyone have any guidance based on historic examples? >> > >> > Dave >> > >> > ----- Original Message ----- >> > From: Adam Montville >> > To: Waltermire, David A.; sacm@ietf.org >> > Sent: Fri Aug 03 16:02:56 2012 >> > Subject: Re: Next Steps >> > >> > >> > >> > On 8/3/12 11:01 AM, "Waltermire, David A." >> >> > wrote: >> > >> >> Adam, >> >> >> >> Thanks for sending this out. >> > >> > You're welcome. >> > >> >> I agree on your timeframe for the charter and would be glad to >> >> participate in the effort to complete the draft. >> > >> > Great! >> > >> >> >> >> I am also happy to continue editing the use case draft. I like your >> idea >> >> of providing some background information and use case motivations. >> I >> >> also see a glossary as useful. In these cases, there are existing >> >> sections in the use cases draft that map to these items. The "1. >> >> Introduction" and "2 Key Concepts" sections would be a good place >> for the >> >> background information. One possible approach for capturing >> motivations >> >> might be to include them in each of the use case sections. We could >> add >> >> a new section for a glossary maybe under key concepts or as a >> standalone >> >> section. I personally like this approach better than creating >> multiple >> >> drafts that would make the information much more disconnected and >> harder >> >> to follow. >> > >> > I'm not certain I agree (which is not to say that I disagree). The >> > motivations for these use cases are, when you trace it all back to >> > business processes, not brief. The skeletal document I've been >> working on >> > already contains about five pages of overview and expands to ten when >> > simply enumerating information security controls and required models >> > (where the enumerated controls and models are only placeholders). >> Perhaps >> > not all of that information is perceived as being required, but I >> think >> > this type of information would be useful in setting the exact context >> in >> > which we intend to work and from which the use cases are derived. In >> > short, I think it would enable us to be much more focused in our >> efforts. >> > >> > That said, we could pare the overarching information down a bit to >> fit it >> > in to the use case document and decide at a later time whether a more >> > comprehensive, distinct document is required based on perceived >> demand >> > from the sacm and other communities. >> > >> > With respect to the glossary, I'm thinking that this will be more or >> less >> > a living document with published updates every so often as we address >> new >> > problems. Does a referential glossary of terms belong in a use case >> > document? If I approach this effort using software architecture >> > communication mechanisms as a guide, the glossary would be distinct >> from >> > other documents. >> > >> > In fact, if we take that type of approach, we would be inclined to >> create >> > a couple of different "meta" documents, which to me would include a >> "frame >> > of reference," "derived use cases," and a "glossary" to start. Our >> data >> > models would then be the conceptual details of the use cases we >> decide to >> > tackle, and the specific bindings (I.e. to XML, or whatever) would be >> the >> > lower-level logical details. Using this type of approach might prove >> to >> > be useful not only to us, but to the other IETF working groups with >> which >> > we need to cooperate. >> > >> > This seems like a lot of work to get done within a short timeframe, >> but >> > I'm willing to put in a little extra effort over the short term to >> help >> > ensure our long term success. >> > >> > >> >> >> >> If this approach is acceptable, would you be interested in co- >> editing the >> >> use case draft with me to work in this content? >> > >> > Yes. >> > >> >> >> >> As for holding weekly meetings, I think this is a great idea that >> will >> >> allow us to move more efficiently. Would you send 2-3 day/time >> options >> >> that we can use to develop some consensus on a timeslot? >> > >> > Yes. How would these options work for everyone wishing to >> participate in >> > these meetings (all times Eastern)? >> > >> > Monday 08:00 - 09:00 >> > Tuesday 08:00 - 09:00 >> > Thursday 08:00 - 09:00 >> > >> > >> > >> >> >> >> Thanks, >> >> Dave >> >> ________________________________________ >> >> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of >> Adam >> >> Montville [amontville@tripwire.com] >> >> Sent: Friday, August 03, 2012 7:43 PM >> >> To: sacm@ietf.org >> >> Subject: [sacm] Next Steps >> >> >> >> All: >> >> >> >> Yesterday's meeting went very well, in my opinion - thank you to all >> who >> >> attended and participated. We received a lot of very good advice, >> and we >> >> have a lot of work to do. It seems that the first order of business >> is >> >> really getting our use cases and charter squared off, with a goal of >> >> getting an acceptable draft charter done within the next four to six >> >> weeks. I propose that we shoot for five weeks (September 7), >> provided >> >> that is enough time to submit before Atlanta. >> >> >> >> With respect to the use cases, there seemed to be some agreement >> that we >> >> would focus on use cases 1 and 3 ("Acceptance and Enforcement of >> >> Acceptable State" and "Security Control Verification and Monitoring" >> >> respectively). I'm assuming that Dave will continue acting as the >> editor >> >> for the use case document and that Kent will continue acting as the >> editor >> >> for the charter. >> >> >> >> There has already been excellent discussion on the list regarding >> the >> >> above, and I hope to see this continue. Dave and Kent, can each of >> you >> >> provide a list of things that need to get done for each document so >> we can >> >> effectively track the work (I'm willing to do the tracking)? >> >> >> >> I would also like to propose that we consider two additional >> informational >> >> drafts. The first would provide additional background and >> motivation for >> >> the use cases - essentially tying them, in a very generic way, to >> the >> >> business processes that would leverage security automation and >> continuous >> >> monitoring standards to their benefit. The second would be an >> >> informational glossary sacm, and other efforts, could leverage to >> help us >> >> all stay on the same page. >> >> >> >> If these are things the community would find useful, I would >> certainly >> >> volunteer to draft them. >> >> >> >> Finally, if it makes sense, perhaps we should set up a weekly call >> for the >> >> next few weeks, especially with respect to the charter. I can >> provide >> >> dial-in details for these calls. If this is deemed a good idea by >> the >> >> community, we can work out an acceptable time that will accommodate >> our >> >> international base. >> >> >> >> Regards, >> >> >> >> Adam >> >> >> >> >> >> _______________________________________________ >> >> sacm mailing list >> >> sacm@ietf.org >> >> https://www.ietf.org/mailman/listinfo/sacm >> >> >> > >> > >> > _______________________________________________ >> > sacm mailing list >> > sacm@ietf.org >> > https://www.ietf.org/mailman/listinfo/sacm >> > >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > --_002_CC42D1C5EB8Bamontvilletripwirecom_ Content-Type: text/plain; name="draft-ietf-sacm-frame-of-reference-00.txt" Content-Description: draft-ietf-sacm-frame-of-reference-00.txt Content-Disposition: attachment; filename="draft-ietf-sacm-frame-of-reference-00.txt"; size=15901; creation-date="Sat, 04 Aug 2012 20:26:03 GMT"; modification-date="Sat, 04 Aug 2012 20:26:03 GMT" Content-ID: <783EBA8BD415B74CBA98721DF6B2F3C3@tripwire.com> Content-Transfer-Encoding: base64 IA0KDQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEEuVy4gTW9udHZpbGxlDQpJbnRlbmRlZCBTdGF0dXM6IEluZm9ybWF0aW9uYWwg ICAgICAgICAgICAgICAgICAgICAgICAgIChUcmlwd2lyZSwgSW5jLikNCkV4cGlyZXM6IFRCRCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRC RA0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8U3RhbmRhcmQgTmFtZT4gDQogICAg ICAgICAgICAgICAgICBkcmFmdC1pZXRmLWdyb3VwT3JTdWJtaXR0ZXItbmFtZS0wMA0KDQoNCkFi c3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBjb250ZXh0dWFsIG92ZXJ2aWV3 IG9mIHRoZSBwcm9ibGVtIGRvbWFpbg0KICAgZm9yIHdoaWNoIHRoZSBwcm9wb3NlZCBTZWN1cml0 eSBBdXRvbWF0aW9uIGFuZCBDb250aW51b3VzIE1vbml0b3JpbmcNCiAgIHdvcmtpbmcgZ3JvdXAg d2lsbCBwcm92aWRlIHNvbHV0aW9ucy4NCg0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIFRo aXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIHRvIElFVEYgaW4gZnVsbCBjb25mb3JtYW5j ZSB3aXRoIHRoZQ0KICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5l ZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBn cm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdv cmtpbmcgZG9jdW1lbnRzIGFzDQogICBJbnRlcm5ldC1EcmFmdHMuDQoNCiAgIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo cw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVy IGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJ bnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0g b3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJl bnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRm Lm9yZy8xaWQtYWJzdHJhY3RzLmh0bWwNCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQg U2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9zaGFkb3cuaHRtbA0KDQoNCkNvcHlyaWdodCBhbmQgTGljZW5zZSBOb3RpY2UNCg0KICAg Q29weXJpZ2h0IChjKSAyMDEyIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQg YXMgdGhlDQogICBkb2N1bWVudCBhdXRob3JzLiBBbGwgcmlnaHRzIHJlc2VydmVkLg0KDQogICBU aGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExl Z2FsDQogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzDQogICAoaHR0cDov L3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YN CiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9j dW1lbnRzDQogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJl c3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QNCiANCg0KDQo8QXV0aG9yPiAgICAgICAgICAgICAgICAg RXhwaXJlcyA8RXhwaXJ5IERhdGU+ICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCklOVEVS TkVUIERSQUZUICAgICAgICAgICAgICA8U3RhbmRhcmQgTmFtZT4gICAgICAgICAgICAgICAgIDxJ c3N1ZSBEYXRlPg0KDQoNCiAgIHRvIHRoaXMgZG9jdW1lbnQuIENvZGUgQ29tcG9uZW50cyBleHRy YWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QNCiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0Qg TGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZg0KICAgdGhlIFRydXN0 IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzDQog ICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuDQoNCg0KDQpUYWJsZSBv ZiBDb250ZW50cw0KDQogICAxICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgICAgMS4xICBUZXJtaW5vbG9neSAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAgMiBXaHkg RG8gV2UgRmFsbCBCZWhpbmQ/IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA0DQogICAzIFNlY3VyaXR5IEF1dG9tYXRpb24gT3Bwb3J0dW5pdHkgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgICAgMy4xIEluZm9ybWF0aW9uIFNlY3VyaXR5IENv bnRyb2xzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgICAzLjIgTW9kZWwg UmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3 DQogICA1IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDkNCiAgIDYgQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgNyBJQU5BIENvbnNpZGVyYXRp b25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICA4 ICBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDkNCiAgICAgOC4xICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgICA4LjIgIEluZm9ybWF0aXZlIFJlZmVy ZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICBBdXRob3Jz JyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDkNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQogDQoNCg0KPEF1dGhvcj4gICAgICAgICAgICAgICAgIEV4cGlyZXMgPEV4cGlyeSBEYXRlPiAg ICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgICAgICAgICAg PFN0YW5kYXJkIE5hbWU+ICAgICAgICAgICAgICAgICA8SXNzdWUgRGF0ZT4NCg0KDQoxICBJbnRy b2R1Y3Rpb24NCg0KICAgVGhlIG5lZWQgZm9yIFNlY3VyaXR5IEF1dG9tYXRpb24gaXMgbm90IGJv cm4gZnJvbSB0aGF0IHdoaWNoIGhhcyBub3QNCiAgIGNoYW5nZWQsIGJ1dCBmcm9tIHRoYXQgd2hp Y2ggaGFzLiAgVGhlcmUgYXJlIHNldmVyYWwgcmVhbGl0aWVzIHdlDQogICBmYWNlIHRvZGF5IHRo YXQgcHVzaCBmb3IgYSBzZWN1cml0eSBhdXRvbWF0aW9uIHNvbHV0aW9uLCB3aGljaA0KICAgaW5j bHVkZSBhIGRpc3RpbmN0IGNoYW5nZSBpbiB0aGUgbmF0dXJlIG9mIG91ciBhZHZlcnNhcmllcywN CiAgIGluY3JlYXNpbmcgdGVjaG5vbG9naWNhbCBjb21wbGV4aXR5LCBkeW5hbWljIHNpdHVhdGlv bmFsIHNlY3VyaXR5LA0KICAgYW5kIGFuIGV4dHJlbWUgc2NhcmNpdHkgb2YgcmVzb3VyY2VzLg0K DQogICBBcyB0aGUgSW50ZXJuZXQgaGFzIG1hdHVyZWQsIHNvIGhhdmUgdGhlIGNyaW1pbmFsIGVs ZW1lbnRzIHNlZWtpbmcgdG8NCiAgIHBlbmV0cmF0ZSB0aGUgY29tbWVyY2lhbCBlbnRlcnByaXNl LiAgVGhlc2UgY3JpbWluYWwgZWxlbWVudHMgYXJlIG91cg0KICAgY29tbW9uIGVuZW15IG9uIGEg Z2xvYmFsIHNjYWxlLiAgUG9saXRpY2FsICJoYWNrdGl2aXN0IiBncm91cHMgYW5kDQogICBvcmdh bml6ZWQgY3JpbWUgcG9zZSBzZXJpb3VzLCBjb21tb24gdGhyZWF0cyB0byBhbGwgZW50ZXJwcmlz ZXMgaW4NCiAgIHRoZSBzYW1lIHdheS4gIFRoZSBvdXRsb29rIGlzIGV4Y2VlZGluZ2x5IGJsZWFr LCBhcyBzb21lIG5hdGlvbnMNCiAgIGVpdGhlciBsb29rIHRoZSBvdGhlciB3YXkgb3Igc2ltcGx5 IGFsbG93IGNyaW1pbmFsIGVsZW1lbnRzIHRvIGV4aXN0DQogICB3aXRoaW4gdGhlaXIgYm9yZGVy cyAtIGp1cmlzZGljdGlvbmFsIGJvdW5kYXJpZXMgd2lsbCBjb21wbGljYXRlIGFueQ0KICAgcmVt ZWR5IHRvIHRoZSBjcmltaW5hbCBwcm9ibGVtLCB3aGljaCBtYWtlcyB0aGlzIHJlYWxpdHkgb25l IHRoYXQgaXMNCiAgIGxpa2VseSB0byBwZXJzaXN0Lg0KDQogICBDb25zaWRlciBhbHNvIHRoYXQg bW9zdCBvZiB1cyBjYXJyeSBhcm91bmQgYSBzdXBlciBjb21wdXRlciBpbiBvdXINCiAgIHBvY2tl dCByZWxhdGl2ZSB0byB0aGUgZmlyc3QgcGVyc29uYWwgY29tcHV0ZXJzLiAgVGhlIGFkdmVudCBv ZiBjbG91ZA0KICAgY29tcHV0aW5nLCBhIGNvbXBsaWNhdGVkIGFycmF5IG9mIGluZnJhc3RydWN0 dXJlLCBwbGF0Zm9ybSwgYW5kDQogICBzb2Z0d2FyZSwgaW50cm9kdWNlcyBzb21lIGNvbXBsaWNh dGVkIHRydXN0IGFuZCBhc3N1cmFuY2UgaXNzdWVzDQogICBnaXZlbiBpdHMgImJsYWNrIGJveCIg bmF0dXJlLiAgVGVjaG5vbG9neSBrZWVwcyBtb3ZpbmcgYXQgYSBicmVha25lY2sNCiAgIHBhY2Us IHJlZHVjaW5nIG91ciB2aXNpYmlsaXR5IGFuZCB0aGVyZWZvcmUgb3VyIGFiaWxpdHkgdG8gcHJl cGFyZQ0KICAgc2VjdXJpdHkgYXJjaGl0ZWN0dXJlcyBpbnRlbGxpZ2VudGx5LiAgVGhlIHJlYWxp dHkgb2YgaW5jcmVhc2luZw0KICAgc3lzdGVtcyBjb21wbGV4aXR5IHdpbGwgY29udGludWUgdG8g cGVyc2lzdCBmb3IgdGhlIGluZGVmaW5pdGUgZnV0dXJlDQogICAtIGZvciBhcyBsb25nIGFzIG91 ciBhcHBldGl0ZSBmb3IgdGVjaG5vbG9naWNhbCBhZHZhbmNlbWVudCByZW1haW5zDQogICBzdHJv bmcuDQoNCiAgIFBlcmhhcHMgY29uc2VxdWVudCB0byBpbmNyZWFzaW5nIHRlY2hub2xvZ2ljYWwg Y29tcGxleGl0eSwgdGhlIHJhdGUNCiAgIG9mIGNoYW5nZSBpbiBvdXIgdGVjaG5vbG9neSBpcyBh c3RvdW5kaW5nIHdoZW4geW91IHRoaW5rIGFib3V0IGl0LiANCiAgIENoYW5nZSBpbiB0aGlzIGNv bnRleHQgcmVmZXJzIHRvIHRoZSBjcmVhdGl2aXR5IG9mIG91ciBhZHZlcnNhcmllcy4gDQogICBB cyBvbmUgZXhhbXBsZSwganVzdCBhIGZldyB5ZWFycyBhZ28sIHBhc3N3b3JkIGNyYWNraW5nIHdh cyBub3QNCiAgIG5lYXJseSBhcyBmYXN0IGFzIGl0IGlzIHRvZGF5LiAgTm93IGFkdmVyc2FyaWVz IGNhbiB0YWtlIGFkdmFudGFnZSBvZg0KICAgYWRkaXRpb25hbCByZXNvdXJjZXMgYXZhaWxhYmxl IG9uIGEgaG9zdCB0byBzcGVlZCB1cCB0aGUgcGFzc3dvcmQNCiAgIGNyYWNraW5nIHByb2Nlc3Mg LSBtb3N0IHJlY2VudGx5LCBHcmFwaGljcyBQcm9jZXNzaW5nIFVuaXRzIGhhdmUgYmVlbg0KICAg ZW1wbG95ZWQgYW5kIGRlbW9uc3RyYXRlZCB0byBiZSBwYXJ0aWN1bGFybHkgZWZmZWN0aXZlLiAg UGVyaGFwcyB0aGUNCiAgIGJlc3Qgd2F5IHRvIHN1bW1hcml6ZSB0aGlzIHJlYWxpdHkgaXMgdG8g c2ltcGx5IHN0YXRlOiBPdXINCiAgIHNpdHVhdGlvbmFsIHNlY3VyaXR5IGlzIHN1YmplY3QgdG8g cmFwaWQgY2hhbmdlLiAgV2Ugc2ltcGx5IGNhbm5vdA0KICAga2VlcCB1cC4gIEF0dGFja2VycyBj aGFuZ2UgdGFjdGljcyBxdWlja2x5LCBhbmQgeWVzdGVyZGF5J3MgZGVmZW5zZQ0KICAgaXMgdG9t b3Jyb3cncyBNYWdpbm90IExpbmUuICBUaGlzIGlzIGFub3RoZXIgcmVhbGl0eSwgYW5kIGl0IHdp bGwNCiAgIHBlcnNpc3QgaW5kZWZpbml0ZWx5LiAgDQoNCiAgIFRoZSBmaW5hbCByZWFsaXR5IGlz IHRoYXQgd2UgYXJlIGV4cGVyaWVuY2luZyBhIGRyb3VnaHQgb2Ygc2VjdXJpdHkNCiAgIHByb2Zl c3Npb25hbHMgYXQgYWxsIGxldmVscy4gIFRoaXMgY2xhaW0gY2FuIGJlIHN1YnN0YW50aWF0ZWQg aW4NCiAgIHNldmVyYWwgd2F5cywgYnV0IHRoZSBpbmNyZWFzZSBpbiBhdmFpbGFibGUgc2VjdXJp dHkgY2VydGlmaWNhdGlvbnMsDQogICBpbmR1c3RyeSBwdWJsaWNhdGlvbnMsIGNvbmZlcmVuY2Vz LCBhbmQgbnVtZXJvdXMgYXJ0aWNsZXMgaGF2aW5nIGJlZW4NCiANCg0KDQo8QXV0aG9yPiAgICAg ICAgICAgICAgICAgRXhwaXJlcyA8RXhwaXJ5IERhdGU+ICAgICAgICAgICAgICAgICAgW1BhZ2Ug M10NCgwNCklOVEVSTkVUIERSQUZUICAgICAgICAgICAgICA8U3RhbmRhcmQgTmFtZT4gICAgICAg ICAgICAgICAgIDxJc3N1ZSBEYXRlPg0KDQoNCiAgIHdyaXR0ZW4gb24gdGhpcyBzdWJqZWN0IHNl ZW0gdG8gbWFrZSBjbGVhciB0aGF0IG91ciBzZWN1cml0eQ0KICAgcmVzb3VyY2VzIGNhbiBiZSBj b25zaWRlcmVkIHNrZWxldG9uIGNyZXdzLg0KDQogICBUaHVzLCBpbmNyZWFzaW5nbHkgc29waGlz dGljYXRlZCB0aHJlYXQgYWdlbnRzLCBpbmNyZWFzaW5nbHkgY29tcGxleA0KICAgc3lzdGVtcywg cmFwaWQgcmF0ZXMgb2YgY2hhbmdlLCBhbmQgYSBzY2FyY2l0eSBvZiBxdWFsaWZpZWQgc2VjdXJp dHkNCiAgIHJlc291cmNlcyBtYWtlcyBpdCBjbGVhciB0aGF0IHRoZSBjb21tb24gZW50ZXJwcmlz ZSBpcyBmYWxsaW5nIGJlaGluZA0KICAgaW4gdGhlIGJhdHRsZSBhZ2FpbnN0IG91ciBkaWdpdGFs IGFkdmVyc2FyaWVzLg0KDQoxLjEgIFRlcm1pbm9sb2d5DQoNCiAgIFRoZSBrZXkgd29yZHMgIk1V U1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJT SE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFM IiBpbiB0aGlzDQogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVk IGluIFJGQyAyMTE5IFtSRkMyMTE5XS4NCg0KDQoyIFdoeSBEbyBXZSBGYWxsIEJlaGluZD8NCg0K ICAgVGhlIGltcG9ydGFudCBxdWVzdGlvbiB0byBhbnN3ZXIgaXMsIHdoeT8gV2h5IGFyZSB3ZSBy ZWFsbHkgZmFsbGluZw0KICAgYmVoaW5kPyAgVGhlcmUgYXJlIGF0IGxlYXN0IHRocmVlIHJlYXNv bnMuDQoNCiAgIEZpcnN0LCB3ZSBoYXZlIHRvbyBtYW55IHBvaW50cyBvZiBodW1hbiBpbnRlcmFj dGlvbiB3aXRoIG91cg0KICAgaW5mb3JtYXRpb24gc2VjdXJpdHkgcHJvY2Vzc2VzLiAgQ29uc2lk ZXIgYSBnb3Zlcm5tZW50LXdpZGUNCiAgIGluZm9ybWF0aW9uIHNlY3VyaXR5IGRhdGEgY2FsbCwg b3Igb25lIGZvciBhIGxhcmdlIG11bHRpLW5hdGlvbmFsDQogICBvcmdhbml6YXRpb24uICBBdCBw cmVzZW50LCBhc3Nlc3NtZW50cyBhbmQgcmVwb3J0cyBhcmVuJ3QNCiAgIGF1dG9tYXRpY2FsbHkg cm9sbGVkIHVwIGFuZCBzY29yZWQuICBJbnN0ZWFkLCBhc3Nlc3NtZW50cyBhcmUgcnVuLA0KICAg c2VsZWN0IHJlbWVkaWF0aW9ucyBhcmUgbWFkZSwgYXNzZXNzbWVudHMgYXJlIHJlLXJ1biwgdGhl biByZXBvcnRzDQogICBhcmUgZ2VuZXJhdGVkLCB0cmFuc2xhdGVkLCBhbmQgZmluYWxseSBhZ2dy ZWdhdGVkLiAgVGhpcyBpcyBhbg0KICAgaW50ZW5zZSBhbmQgZXhwZW5zaXZlIHByb2Nlc3MuDQoN CiAgIFRoZSBzZWNvbmQgcGFpbiBwb2ludCB3ZSBoYXZlIGluIHRoZSBzZWN1cml0eSBpbmR1c3Ry eSBpcyBub3QNCiAgIHVucmVsYXRlZCB0byB0aGUgZmlyc3Q6IFdlIGhhdmUgdG9vIG1hbnkgcGVv cGxlIHdvcmtpbmcgb24gdGhlIHNhbWUNCiAgIG11bmRhbmUgcHJvYmxlbXMuICBNYW5hZ2luZyBz ZWN1cml0eSBjb250ZW50LCBhcyBvbmUgZXhhbXBsZSwgaXMgYQ0KICAgcHJvYmxlbSB3aXRoIHdo aWNoIHNlY3VyaXR5IHByb2Zlc3Npb25hbHMgc2hvdWxkIG5vdCBzcGVuZCBtb3N0IG9mDQogICB0 aGVpciB0aW1lLiAgVG9kYXksIG1hbnkgc2VjdXJpdHkgcHJvZmVzc2lvbmFscyBhcmUgc3BlbmRp bmcgYQ0KICAgZGlzcHJvcG9ydGlvbmF0ZSBhbW91bnQgb2YgdGhlaXIgdGltZSBvbiB0aGVzZSBh ZG1pbmlzdHJhdGl2ZSBpc3N1ZXMNCiAgIHJhdGhlciB0aGFuIG9uIHdoYXQgbWF0dGVycyAtIGFm ZmVjdGluZyByZWFsIHNlY3VyaXR5IHdpdGhpbiB0aGVpcg0KICAgb3JnYW5pemF0aW9uLg0KDQog ICBUaGlyZCwgd2UgaGF2ZSB0b28gbXVjaCBpbmZvcm1hdGlvbiAtIGluIGZhY3QsIHNvIG11Y2gg aW5mb3JtYXRpb24NCiAgIHRoYXQgd2UgY2Fubm90IGtlZXAgdXAgd2l0aCBpdCBhbGwuICBUaGVy ZSBpcyBzbyBtdWNoIGluZm9ybWF0aW9uLCB3ZQ0KICAgb2Z0ZW4gaGF2ZSBubyBpZGVhIHdoYXQg aXQgbWVhbnMsIG9yIHdlIG1pc3MgcmVsZXZhbnQgaW5mb3JtYXRpb24NCiAgIGVudGlyZWx5LiAg VGhpcyBpcyBwYXJ0aWN1bGFybHkgdHJvdWJsaW5nLCBiZWNhdXNlIG9yZ2FuaXphdGlvbnMNCiAg IHJlcXVpcmUgdGhlaXIgc2VjdXJpdHkgcHJvY2Vzc2VzIHRvIGJlaGF2ZSBtb3JlIGxpa2UgYSBk ZWNpc2lvbg0KICAgc3VwcG9ydCB0b29sIC0gb25lIHRoYXQgaXMgYWJsZSB0byBzZWUgdGhlIHNp Z25hbCB0aHJvdWdoIHRoZSBub2lzZSAtDQogICBhbmQgd2hlbiB0aGUgc2lnbmFsIGlzIHNvIHdl YWsgYXMgdG8gYmUgbm9uZXhpc3RlbnQsIHRoZSBwcm9jZXNzJw0KICAgdmFsdWUgaXMgZGltaW5p c2hlZC4gIA0KDQozIFNlY3VyaXR5IEF1dG9tYXRpb24gT3Bwb3J0dW5pdHkNCiANCg0KDQo8QXV0 aG9yPiAgICAgICAgICAgICAgICAgRXhwaXJlcyA8RXhwaXJ5IERhdGU+ICAgICAgICAgICAgICAg ICAgW1BhZ2UgNF0NCgwNCklOVEVSTkVUIERSQUZUICAgICAgICAgICAgICA8U3RhbmRhcmQgTmFt ZT4gICAgICAgICAgICAgICAgIDxJc3N1ZSBEYXRlPg0KDQoNCiAgIFRoZSBvcGVyYXRpb25hbCBt ZXRob2RzIHdlIHVzZSB3aXRoaW4gdGhlIGJvdW5kcyBvZiBvdXIgcHJlc2VudA0KICAgcmVhbGl0 aWVzIGFyZSBmYWlsaW5nIHVzIC0gd2UgYXJlIGZhbGxpbmcgYmVoaW5kLiAgV2UgaGF2ZSBiZWd1 biB0bw0KICAgcmVjb2duaXplIHRoYXQgdGhlIGV2b2x1dGlvbiBvZiB0aHJlYXQgYWdlbnRzLCBp bmNyZWFzaW5nIHN5c3RlbQ0KICAgY29tcGxleGl0eSwgcmFwaWQgc2l0dWF0aW9uYWwgc2VjdXJp dHkgY2hhbmdlLCBhbmQgc2NhcmNlIHJlc291cmNlcw0KICAgYXJlIGRldHJpbWVudGFsIHRvIG91 ciBzdWNjZXNzLiAgVGhlcmUgaGF2ZSBiZWVuIGVmZm9ydHMgdG8gcmVtZWR5DQogICBvdXIgY2ly Y3Vtc3RhbmNlLCBhbmQgdGhlc2UgZWZmb3J0cyBhcmUgZ2VuZXJhbGx5IGtub3duIGFzICJTZWN1 cml0eQ0KICAgQXV0b21hdGlvbi4iDQoNCiAgIFNlY3VyaXR5IEF1dG9tYXRpb24gaXMgYSBnZW5l cmFsIHRlcm0gdXNlZCB0byByZWZlcmVuY2Ugc3RhbmRhcmRzIGFuZA0KICAgc3BlY2lmaWNhdGlv bnMgb3JpZ2luYWxseSBjcmVhdGVkIGJ5IHRoZSBOYXRpb25hbCBJbnN0aXR1dGUgb2YNCiAgIFN0 YW5kYXJkcyBhbmQgVGVjaG5vbG9neSAoTklTVCkgYW5kL29yIHRoZSBNSVRSRSBDb3Jwb3JhdGlv bi4gDQogICBTZWN1cml0eSBBdXRvbWF0aW9uIGdlbmVyYWxseSBpbmNsdWRlcyBsYW5ndWFnZXMs IHByb3RvY29scw0KICAgKHByZXNjcmliZWQgd2F5cyBieSB3aGljaCBzcGVjaWZpY2F0aW9uIGNv bGxlY3Rpb25zIGFyZSB1c2VkKSwNCiAgIGVudW1lcmF0aW9ucywgYW5kIG1ldHJpY3MuDQoNCiAg IFRoZXNlIHNwZWNpZmljYXRpb25zIGhhdmUgcHJvdmlkZWQgYW4gb3Bwb3J0dW5pdHkgZm9yIHRv b2wgdmVuZG9ycw0KICAgYW5kIGVudGVycHJpc2VzIGJ1aWxkaW5nIGN1c3RvbWl6ZWQgc29sdXRp b25zIHRvIHRha2UgdGhlIGFwcHJvcHJpYXRlDQogICBzdGVwcyB0b3dhcmQgZW5hYmxpbmcgU2Vj dXJpdHkgQXV0b21hdGlvbiBieSBkZWZpbmluZyBjb21tb24NCiAgIGluZm9ybWF0aW9uIGV4cHJl c3Npb25zLiAgSW4gZWZmZWN0LCBjb21tb24gZXhwcmVzc2lvbiBvZiBpbmZvcm1hdGlvbg0KICAg ZW5hYmxlcyBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gdG9vbHMgKHdoZXRoZXIgY3VzdG9taXpl ZCwNCiAgIGNvbW1lcmNpYWwsIG9yIGZyZWVseSBhdmFpbGFibGUpLiAgQW5vdGhlciBpbXBvcnRh bnQgY2FwYWJpbGl0eQ0KICAgY29tbW9uIGV4cHJlc3Npb24gcHJvdmlkZXMgaXMgdGhlIGFiaWxp dHkgdG8gYXV0b21hdGUgcG9ydGlvbnMgb2YNCiAgIHNlY3VyaXR5IHByb2Nlc3NlcyB0byBnYWlu IGVmZmljaWVuY3ksIHJlYWN0IHRvIG5ldyB0aHJlYXRzIGluIGENCiAgIHRpbWVseSBtYW5uZXIs IGFuZCBmcmVlIHVwIHNlY3VyaXR5IHBlcnNvbm5lbCB0byB3b3JrIG9uIG1vcmUNCiAgIGFkdmFu Y2VkIHByb2JsZW1zIHdpdGhpbiB0aGUgcHJvY2Vzc2VzIGluIHdoaWNoIHRoZXkgcGFydGljaXBh dGUuDQoNCiAgIFRoZSBmb2xsb3dpbmcgc3Vic2VjdGlvbnMgKDMuMSBJbmZvcm1hdGlvbiBTZWN1 cml0eSBDb250cm9scyBhbmQgMy4yDQogICBNb2RlbCBSZXF1aXJlbWVudHMpIGF0dGVtcHQgdG8g Y2FsbCBvdXQgc29tZSBvZiB0aGUgbW9yZSBjb21tb24NCiAgIGNvbnRyb2xzIGFuZCByZXF1aXJl ZCBtb2RlbHMgZm9yIGEgZG9tYWluIG11Y2ggbGFyZ2VyIHRoYW4gc2VjdXJpdHkNCiAgIGF1dG9t YXRpb24gYW5kIGNvbnRpbnVvdXMgbW9uaXRvcmluZyBhbG9uZS4gIFJhdGhlciB0aGFuIHBpY2sg YW5kDQogICBjaG9vc2UgcmVsZXZhbnQgY29udHJvbHMgYW5kIG1vZGVscyB0byBzdWl0IHRoZSBw dXJwb3NlcyBvZiB0aGUNCiAgIHByb3Bvc2VkIHdvcmtpbmcgZ3JvdXAsIGl0IHNlZW1lZCBwcnVk ZW50IHRvIGVudW1lcmF0ZSBhcyBtdWNoIG9mIHRoZQ0KICAgcHJvYmxlbSBkb21haW4gYXMgcG9z c2libGUsIHNvIHRoYXQgb3RoZXIgZWZmb3J0cyBjYW4gYmUgaW5mb3JtZWQNCiAgIGFuZC9vciBz dGFydGVkIGluIHBhcmFsbGVsIHRvIHRoZSBTZWN1cml0eSBBdXRvbWF0aW9uIGFuZCBDb250aW51 b3VzDQogICBNb25pdG9yaW5nIGVmZm9ydC4NCg0KICAgTm90ZTogQXQgdGhpcyBwb2ludCwgYSBt YXBwaW5nIGJldHdlZW4gY29udHJvbHMgYW5kIG1vZGVscyBpcyBub3QNCiAgIHByb3ZpZGVkLiAg Tm90IGFsbCByZWxhdGlvbnNoaXBzIGJldHdlZW4gY29udHJvbHMgYW5kIG1vZGVscyB3aWxsIGJl DQogICBzZWxmLWV2aWRlbnQuDQoNCjMuMSBJbmZvcm1hdGlvbiBTZWN1cml0eSBDb250cm9scw0K DQogICBUaGUgaW5mb3JtYXRpb24gc2VjdXJpdHkgaW5kdXN0cnkgaGFzIGdlbmVyYWxseSBjb2Fs ZXNjZWQgYXJvdW5kIHNvbWUNCiAgIGZvdW5kYXRpb25hbCBzZWN1cml0eSBjb250cm9scyB3aGlj aCBhcmUgdHlwaWNhbGx5IHVzZWQgdG8gZnVsZmlsbA0KICAgb3JnYW5pemF0aW9uYWwgc2VjdXJp dHkgcG9saWN5IG5lZWRzLiAgVGhpcyBzZWN0aW9uIGFuZCB0aGUNCiAgIHN1YnNlY3Rpb25zIGl0 IGNvbnRhaW5zIGRlc2NyaWJlIHRoZXNlIGZvdW5kYXRpb25hbCBzZWN1cml0eQ0KICAgY29udHJv bHMuICBUaGUgbmV4dCBzZWN0aW9uIHByb3ZpZGVzIHNvbWUgbm90aW9uIG9mIHdoYXQgbW9kZWxz LCBpLmUuDQogICBzcGVjaWZpY2F0aW9ucywgbWlnaHQgYmUgcmVxdWlyZWQgdG8gc3VwcG9ydCB3 aWRlc3ByZWFkDQogDQoNCg0KPEF1dGhvcj4gICAgICAgICAgICAgICAgIEV4cGlyZXMgPEV4cGly eSBEYXRlPiAgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAg ICAgICAgICAgPFN0YW5kYXJkIE5hbWU+ICAgICAgICAgICAgICAgICA8SXNzdWUgRGF0ZT4NCg0K DQogICBpbnRlcm9wZXJhYmlsaXR5IGFuZCBjb21tb24gZm91bmRhdGlvbmFsIGZ1bmN0aW9uYWxp dHkgYmV0d2VlbiB0b29scw0KICAgY2hvb3NpbmcgdG8gYWRoZXJlIHRvIHRob3NlIHNwZWNpZmlj YXRpb25zLg0KDQogICAgICAgICBvICBBc3NldCBEaXNjb3ZlcnkNCg0KICAgICAgICAgbyAgQXNz ZXQgSW5mb3JtYXRpb24vQ2hhcmFjdGVyaXphdGlvbg0KDQogICAgICAgICBvICBWdWxuZXJhYmls aXR5IEFzc2Vzc21lbnQNCg0KICAgICAgICAgbyAgQW50aS12aXJ1cw0KDQogICAgICAgICBvICBE YXRhIExvc3MgUHJldmVudGlvbg0KDQogICAgICAgICBvICBIb3N0LWJhc2VkIEludHJ1c2lvbiBE ZXRlY3Rpb24NCg0KICAgICAgICAgbyAgTmV0d29yay1iYXNlZCBJbnRydXNpb24gRGV0ZWN0aW9u DQoNCiAgICAgICAgIG8gIExvZyBNb25pdG9yaW5nDQoNCiAgICAgICAgIG8gIFNlY3VyaXR5IElu Y2lkZW50IEV2ZW50IE1hbmFnZW1lbnQNCg0KICAgICAgICAgbyAgRmlsZSBBY3Rpdml0eSBNb25p dG9yaW5nDQoNCiAgICAgICAgIG8gIERhdGFiYXNlIEFjdGl2aXR5IChBY2Nlc3MpIE1vbml0b3Jp bmcNCg0KICAgICAgICAgbyAgTmV0d29yayBBY2Nlc3MgQ29udHJvbA0KDQogICAgICAgICBvICBD b25maWd1cmF0aW9uIE1hbmFnZW1lbnQNCg0KICAgICAgICAgbyAgU2VjdXJpdHkgQ29uZmlndXJh dGlvbiBNYW5hZ2VtZW50DQoNCiAgICAgICAgICAgICAgICAgIG8gIENvbmZpZ3VyYXRpb24gQXNz ZXNzbWVudCANCg0KICAgICAgICAgICAgICAgICAgbyAgQ29uZmlndXJhdGlvbiBSZW1lZGlhdGlv bg0KDQogICAgICAgICAgICAgICAgICBvICBQYXRjaCBBc3Nlc3NtZW50DQoNCiAgICAgICAgICAg ICAgICAgIG8gIFBhdGNoIFJlbWVkaWF0aW9uDQoNCiAgICAgICAgICAgICAgICAgIG8gIEZpbGUg SW50ZWdyaXR5IE1vbml0b3JpbmcNCg0KICAgICAgICAgbyAgU3VwcG9ydGluZyBDb25jZXB0cw0K DQogICAgICAgICAgICAgICAgICBvICBEYXRhIEFnZ3JlZ2F0aW9uDQoNCiAgICAgICAgICAgICAg ICAgIG8gIFRhc2tpbmcvV29ya2Zsb3cNCg0KICAgICAgICAgICAgICAgICAgbyAgUHJlc2VudGF0 aW9uDQogDQoNCg0KPEF1dGhvcj4gICAgICAgICAgICAgICAgIEV4cGlyZXMgPEV4cGlyeSBEYXRl PiAgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgICAgICAg ICAgPFN0YW5kYXJkIE5hbWU+ICAgICAgICAgICAgICAgICA8SXNzdWUgRGF0ZT4NCg0KDQogICAg ICAgICAgICAgICAgICBvICBBbmFseXNpcw0KDQogICAgICAgICAgICAgICAgICBvICBSZXBvcnRp bmcNCg0KMy4yIE1vZGVsIFJlcXVpcmVtZW50cw0KDQoNCiAgIFRoZSBmb3VuZGF0aW9uYWwgY29u dHJvbHMgZGVzY3JpYmVkIGluIHRoZSBwcmV2aW91cyBzZWN0aW9uIHJlcXVpcmUgYQ0KICAgdmFy aWV0eSBvZiBpbmZvcm1hdGlvbiBtb2RlbHMgdG8gYmUgc3BlY2lmaWVkIGFuZC9vciBzdGFuZGFy ZGl6ZWQuIA0KICAgUG90ZW50aWFsIG1vZGVscyBhcmUgbGlzdGVkIGFzIGZvbGxvd3M6DQoNCiAg ICAgICAgIG8gIEFjY2VzcyBtb2RlbA0KDQogICAgICAgICBvICBBbGVydCBtb2RlbA0KDQogICAg ICAgICBvICBBc3Nlc3NtZW50IG1vZGVsDQoNCiAgICAgICAgIG8gIEFzc2Vzc21lbnQgcXVlcnkg bW9kZWwNCg0KICAgICAgICAgbyAgQXNzZXNzbWVudCByZXBvcnQgbW9kZWwNCg0KICAgICAgICAg byAgQXNzZXQgZGlzY292ZXJ5IG1vZGVsDQoNCiAgICAgICAgIG8gIEFzc2V0IG1vZGVsDQoNCiAg ICAgICAgIG8gIEFzc2V0IHJlcG9ydCBtb2RlbA0KDQogICAgICAgICBvICBBdHRhY2sgbW9kZWwN Cg0KICAgICAgICAgbyAgQXV0aGVudGljYXRpb24gbW9kZWwNCg0KICAgICAgICAgbyAgQXV0aG9y aXphdGlvbiBtb2RlbA0KDQogICAgICAgICBvICBCZW5jaG1hcmsgbW9kZWwNCg0KICAgICAgICAg byAgQ2xhc3NpZmljYXRpb24gbW9kZWwNCg0KICAgICAgICAgbyAgQ29tbXVuaWNhdGlvbiBtb2Rl bA0KDQogICAgICAgICBvICBDb25maWd1cmF0aW9uIGFzc2Vzc21lbnQgbW9kZWwNCg0KICAgICAg ICAgbyAgQ29uZmlndXJhdGlvbiBtYW5hZ2VtZW50IG1vZGVsDQoNCiAgICAgICAgIG8gIENvbmZp Z3VyYXRpb24gbW9kZWwNCg0KICAgICAgICAgbyAgQ29uZmlndXJhdGlvbiBzY29yaW5nIG1vZGVs DQoNCiAgICAgICAgIG8gIENyZWRlbnRpYWwgbW9kZWwNCiANCg0KDQo8QXV0aG9yPiAgICAgICAg ICAgICAgICAgRXhwaXJlcyA8RXhwaXJ5IERhdGU+ICAgICAgICAgICAgICAgICAgW1BhZ2UgN10N CgwNCklOVEVSTkVUIERSQUZUICAgICAgICAgICAgICA8U3RhbmRhcmQgTmFtZT4gICAgICAgICAg ICAgICAgIDxJc3N1ZSBEYXRlPg0KDQoNCiAgICAgICAgIG8gIERhdGEgdHJhbnNwb3J0IG1vZGVs DQoNCiAgICAgICAgIG8gIERpc2NvdmVyeSBtb2RlbA0KDQogICAgICAgICBvICBFdmVudCBtYW5h Z2VtZW50IG1vZGVsDQoNCiAgICAgICAgIG8gIEV2ZW50IG1vZGVsDQoNCiAgICAgICAgIG8gIEV2 aWRlbmNlIG1vZGVsDQoNCiAgICAgICAgIG8gIElkZW50aXR5IG1vZGVsDQoNCiAgICAgICAgIG8g IEluY2lkZW50IG9iamVjdCBtb2RlbA0KDQogICAgICAgICBvICBJbmNpZGVudCBxdWVyeSBtb2Rl bA0KDQogICAgICAgICBvICBJbmZvcm1hdGlvbiBzaGFyaW5nIG1vZGVsDQoNCiAgICAgICAgIG8g IEtleSBtYW5hZ2VtZW50IG1vZGVsDQoNCiAgICAgICAgIG8gIExvY2F0aW9uIG1vZGVsDQoNCiAg ICAgICAgIG8gIE1hbHdhcmUgbW9kZWwNCg0KICAgICAgICAgbyAgT3BlcmF0aW9ucyBtb2RlbA0K DQogICAgICAgICBvICBQbGF0Zm9ybSBtb2RlbA0KDQogICAgICAgICBvICBSaXNrIG1vZGVsDQoN CiAgICAgICAgIG8gIFJ1bGUgbW9kZWwNCg0KICAgICAgICAgbyAgU29mdHdhcmUgYXNzdXJhbmNl IG1vZGVsDQoNCiAgICAgICAgIG8gIFNvZnR3YXJlIHdlYWtuZXNzIG1vZGVsDQoNCiAgICAgICAg IG8gIFNvZnR3YXJlIHdlYWtuZXNzIHNjb3JpbmcgbW9kZWwNCg0KICAgICAgICAgbyAgU3RhdGUg bW9kZWwNCg0KICAgICAgICAgbyAgU3lzdGVtIG1hbmFnZW1lbnQgbW9kZWwNCg0KICAgICAgICAg byAgVHJhbnNwb3J0IG1vZGVsDQoNCiAgICAgICAgIG8gIFRydXN0IG1vZGVsDQoNCiAgICAgICAg IG8gIFZ1bG5lcmFiaWxpdHkgbW9kZWwNCg0KIA0KDQoNCjxBdXRob3I+ICAgICAgICAgICAgICAg ICBFeHBpcmVzIDxFeHBpcnkgRGF0ZT4gICAgICAgICAgICAgICAgICBbUGFnZSA4XQ0KDA0KSU5U RVJORVQgRFJBRlQgICAgICAgICAgICAgIDxTdGFuZGFyZCBOYW1lPiAgICAgICAgICAgICAgICAg PElzc3VlIERhdGU+DQoNCg0KICAgICAgICAgbyAgVnVsbmVyYWJpbGl0eSByZXBvcnQgbW9kZWwN Cg0KICAgICAgICAgbyAgVnVsbmVyYWJpbGl0eSBzY29yaW5nIG1vZGVsDQoNCiAgICAgICAgIG8g IFdvcmtmbG93IG1vZGVsDQoNCg0KNSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICAgICAg ICBUaGlzIG1lbW8gaGFzIG5vIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLg0KDQo2IEFja25vd2xl ZGdlbWVudHMNCg0KICAgICAgICAgVEJEDQoNCjcgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICAg ICAgICBUQkQNCg0KDQo4ICBSZWZlcmVuY2VzDQoNCjguMSAgTm9ybWF0aXZlIFJlZmVyZW5jZXMN Cg0KDQogICBbS0VZV09SRFNdIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZD cyB0byBJbmRpY2F0ZQ0KICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQs IFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0KDQoNCjguMiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0K DQogICAgICAgICAgICAgIFRCRA0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0KDQogICAgICAgICAg ICAgIEFkYW0gVy4gTW9udHZpbGxlDQogICAgICAgICAgICAgIEVNYWlsOiBhbW9udHZpbGxlQHRy aXB3aXJlLmNvbQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQo8QXV0aG9yPiAgICAgICAgICAg ICAgICAgRXhwaXJlcyA8RXhwaXJ5IERhdGU+ICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCg== --_002_CC42D1C5EB8Bamontvilletripwirecom_-- From lnunez@c3isecurity.com Sat Aug 4 14:40:38 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA2621F860D for ; Sat, 4 Aug 2012 14:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.132 X-Spam-Level: X-Spam-Status: No, score=-3.132 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7DB+5EBzusw for ; Sat, 4 Aug 2012 14:40:34 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id BFB5121F861C for ; Sat, 4 Aug 2012 14:40:33 -0700 (PDT) Received: by yhq56 with SMTP id 56so1903766yhq.31 for ; Sat, 04 Aug 2012 14:40:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=QbmWClohNksilZxOpEiTlmp+ObI5qDrwPwr1oA+kLmw=; b=MOoj37dhiONHLTnwPKCEs4no3K/HSDONcVmAGZSLJp/WJxwtJ+R4X/j4BTKcfPkZlA zRnKP5kkMmjv4v3AMfwRpS9xGyyMPD5SJWQh6DWbGMH6beKp7exhXA0Rx/MpagTdPQk1 2z5UcKV9G4P1cxdL56aPT2kB1qczZu0xqu/5z90pYaFoJV8Ue2KLoYhtbcdDcpynXN/P mE3MMT8Rd3VvKn59T/C+782ah3iu/brjrCk4B9nqt39NiVO7kYCnTRXOKC5/L2fxeeWY MvWdxKhSAkjbqwgVaiGrtsun00IV0c7ZzgjMYppX7xJjbtTedFnP/4VkFaO5QbqNE/Os An5w== Received: by 10.236.74.37 with SMTP id w25mr6127705yhd.30.1344116429822; Sat, 04 Aug 2012 14:40:29 -0700 (PDT) Received: from [192.168.1.30] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id r22sm11621572anh.6.2012.08.04.14.40.27 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Aug 2012 14:40:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Luis Nunez In-Reply-To: Date: Sat, 4 Aug 2012 17:40:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adam Montville X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkpDKARhzhcz5I4A9863tT8F68WEMsBXHkhRUbHgU5uNylKf8THHfDQOFwLtb1sg7Y/Djur Cc: Sean Turner , Stephen Hanna , "Waltermire, David A." , "'sacm@ietf.org'" Subject: Re: [sacm] Next Steps X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 21:40:38 -0000 Adam, thank you for putting this together. It is a great read and it sets the = context for building a security communications model we need now and for = the foreseeable future. I think we see through sections 3.1 and 3.2 as a means to connect to the = use cases. -ln On Aug 4, 2012, at 4:26 PM, Adam Montville wrote: > Hi Steve, >=20 > Here's what I have. Please note a few things. First, it's still in = very > rough form and will likely need a few more passes before it would be > concise enough (that's my guess anyway). Second, the format may not = be > correct - I'm experimenting with the nroff editor and formatting can = be > updated easily enough so it's more important to focus on the message. > Third, some stakes are put in the ground with respect to common = security > controls and derived information models, but they're intended to spark = a > conversation - not a flame=8A >=20 > All that said, have a look, and if it makes sense we can continue = working > on it. Otherwise, we'll let it be and turn immediately to the use = cases > and charter. >=20 > Regards, >=20 > Adam >=20 > On 8/3/12 3:25 PM, "Stephen Hanna" wrote: >=20 >> Could we get a glimpse at the latest draft Background document before >> we decide whether it should be added to the use cases? I'd be glad >> to have more background for the use cases (either as one doc or two) >> but I'm a bit concerned about documenting business processes. Those >> vary widely from one enterprise to the next. We shouldn't tie >> ourselves to one set of business processes. >>=20 >> I'm perfectly fine with having a Glossary document, if we end up >> using a lot of special words. If it's only a few (less than 30-40), >> it will be easier to just include a glossary section in each document >> or (maybe even better) in an Overview document with use cases and a >> reference model, as we did in NEA with RFC 5209. >>=20 >> Thanks, >>=20 >> Steve >>=20 >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of >>> Sean Turner >>> Sent: Friday, August 03, 2012 5:29 PM >>> To: Waltermire, David A. >>> Cc: 'sacm@ietf.org'; 'amontville@tripwire.com' >>> Subject: Re: [sacm] Next Steps >>>=20 >>> There are drafts that address each one and then there are drafts = that >>> do >>> all three. Regardless of which choice you make somebody will say = that >>> it would have better to have made the other choice ;) I'd not spend = too >>> much time worrying about which path to take - unless it's going to = be >>> 300 pages. >>>=20 >>> spt >>>=20 >>> On 8/3/12 1:07 PM, Waltermire, David A. wrote: >>>> Regarding the Use Case/Background/Glossary discussion, it would be >>> interesting to consider what IETF WGs have done in this regard. I >>> think it makes sense to follow the "IETF approach" to this kind of >>> exercise. >>>>=20 >>>> Does anyone have any guidance based on historic examples? >>>>=20 >>>> Dave >>>>=20 >>>> ----- Original Message ----- >>>> From: Adam Montville >>>> To: Waltermire, David A.; sacm@ietf.org >>>> Sent: Fri Aug 03 16:02:56 2012 >>>> Subject: Re: Next Steps >>>>=20 >>>>=20 >>>>=20 >>>> On 8/3/12 11:01 AM, "Waltermire, David A." >>> >>>> wrote: >>>>=20 >>>>> Adam, >>>>>=20 >>>>> Thanks for sending this out. >>>>=20 >>>> You're welcome. >>>>=20 >>>>> I agree on your timeframe for the charter and would be glad to >>>>> participate in the effort to complete the draft. >>>>=20 >>>> Great! >>>>=20 >>>>>=20 >>>>> I am also happy to continue editing the use case draft. I like = your >>> idea >>>>> of providing some background information and use case motivations. >>> I >>>>> also see a glossary as useful. In these cases, there are existing >>>>> sections in the use cases draft that map to these items. The "1. >>>>> Introduction" and "2 Key Concepts" sections would be a good place >>> for the >>>>> background information. One possible approach for capturing >>> motivations >>>>> might be to include them in each of the use case sections. We = could >>> add >>>>> a new section for a glossary maybe under key concepts or as a >>> standalone >>>>> section. I personally like this approach better than creating >>> multiple >>>>> drafts that would make the information much more disconnected and >>> harder >>>>> to follow. >>>>=20 >>>> I'm not certain I agree (which is not to say that I disagree). The >>>> motivations for these use cases are, when you trace it all back to >>>> business processes, not brief. The skeletal document I've been >>> working on >>>> already contains about five pages of overview and expands to ten = when >>>> simply enumerating information security controls and required = models >>>> (where the enumerated controls and models are only placeholders). >>> Perhaps >>>> not all of that information is perceived as being required, but I >>> think >>>> this type of information would be useful in setting the exact = context >>> in >>>> which we intend to work and from which the use cases are derived. = In >>>> short, I think it would enable us to be much more focused in our >>> efforts. >>>>=20 >>>> That said, we could pare the overarching information down a bit to >>> fit it >>>> in to the use case document and decide at a later time whether a = more >>>> comprehensive, distinct document is required based on perceived >>> demand >>>> from the sacm and other communities. >>>>=20 >>>> With respect to the glossary, I'm thinking that this will be more = or >>> less >>>> a living document with published updates every so often as we = address >>> new >>>> problems. Does a referential glossary of terms belong in a use = case >>>> document? If I approach this effort using software architecture >>>> communication mechanisms as a guide, the glossary would be distinct >>> from >>>> other documents. >>>>=20 >>>> In fact, if we take that type of approach, we would be inclined to >>> create >>>> a couple of different "meta" documents, which to me would include a >>> "frame >>>> of reference," "derived use cases," and a "glossary" to start. Our >>> data >>>> models would then be the conceptual details of the use cases we >>> decide to >>>> tackle, and the specific bindings (I.e. to XML, or whatever) would = be >>> the >>>> lower-level logical details. Using this type of approach might = prove >>> to >>>> be useful not only to us, but to the other IETF working groups with >>> which >>>> we need to cooperate. >>>>=20 >>>> This seems like a lot of work to get done within a short timeframe, >>> but >>>> I'm willing to put in a little extra effort over the short term to >>> help >>>> ensure our long term success. >>>>=20 >>>>=20 >>>>>=20 >>>>> If this approach is acceptable, would you be interested in co- >>> editing the >>>>> use case draft with me to work in this content? >>>>=20 >>>> Yes. >>>>=20 >>>>>=20 >>>>> As for holding weekly meetings, I think this is a great idea that >>> will >>>>> allow us to move more efficiently. Would you send 2-3 day/time >>> options >>>>> that we can use to develop some consensus on a timeslot? >>>>=20 >>>> Yes. How would these options work for everyone wishing to >>> participate in >>>> these meetings (all times Eastern)? >>>>=20 >>>> Monday 08:00 - 09:00 >>>> Tuesday 08:00 - 09:00 >>>> Thursday 08:00 - 09:00 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Dave >>>>> ________________________________________ >>>>> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of >>> Adam >>>>> Montville [amontville@tripwire.com] >>>>> Sent: Friday, August 03, 2012 7:43 PM >>>>> To: sacm@ietf.org >>>>> Subject: [sacm] Next Steps >>>>>=20 >>>>> All: >>>>>=20 >>>>> Yesterday's meeting went very well, in my opinion - thank you to = all >>> who >>>>> attended and participated. We received a lot of very good advice, >>> and we >>>>> have a lot of work to do. It seems that the first order of = business >>> is >>>>> really getting our use cases and charter squared off, with a goal = of >>>>> getting an acceptable draft charter done within the next four to = six >>>>> weeks. I propose that we shoot for five weeks (September 7), >>> provided >>>>> that is enough time to submit before Atlanta. >>>>>=20 >>>>> With respect to the use cases, there seemed to be some agreement >>> that we >>>>> would focus on use cases 1 and 3 ("Acceptance and Enforcement of >>>>> Acceptable State" and "Security Control Verification and = Monitoring" >>>>> respectively). I'm assuming that Dave will continue acting as the >>> editor >>>>> for the use case document and that Kent will continue acting as = the >>> editor >>>>> for the charter. >>>>>=20 >>>>> There has already been excellent discussion on the list regarding >>> the >>>>> above, and I hope to see this continue. Dave and Kent, can each = of >>> you >>>>> provide a list of things that need to get done for each document = so >>> we can >>>>> effectively track the work (I'm willing to do the tracking)? >>>>>=20 >>>>> I would also like to propose that we consider two additional >>> informational >>>>> drafts. The first would provide additional background and >>> motivation for >>>>> the use cases - essentially tying them, in a very generic way, to >>> the >>>>> business processes that would leverage security automation and >>> continuous >>>>> monitoring standards to their benefit. The second would be an >>>>> informational glossary sacm, and other efforts, could leverage to >>> help us >>>>> all stay on the same page. >>>>>=20 >>>>> If these are things the community would find useful, I would >>> certainly >>>>> volunteer to draft them. >>>>>=20 >>>>> Finally, if it makes sense, perhaps we should set up a weekly call >>> for the >>>>> next few weeks, especially with respect to the charter. I can >>> provide >>>>> dial-in details for these calls. If this is deemed a good idea by >>> the >>>>> community, we can work out an acceptable time that will = accommodate >>> our >>>>> international base. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Adam >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> sacm mailing list >>>>> sacm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >>>>=20 >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >>=20 >=20 > = _______________________________= ________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From amontville@tripwire.com Sun Aug 5 12:17:38 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7102F21F84FB for ; Sun, 5 Aug 2012 12:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.879 X-Spam-Level: X-Spam-Status: No, score=-3.879 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2oJ1NYhQsbK for ; Sun, 5 Aug 2012 12:17:38 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id AE06F21F84EB for ; Sun, 5 Aug 2012 12:17:37 -0700 (PDT) Received: from mail49-db3-R.bigfish.com (10.3.81.253) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Sun, 5 Aug 2012 19:17:36 +0000 Received: from mail49-db3 (localhost [127.0.0.1]) by mail49-db3-R.bigfish.com (Postfix) with ESMTP id 0F7D732030D for ; Sun, 5 Aug 2012 19:17:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(z3d0Izzz1202hz31izz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail49-db3 (localhost.localdomain [127.0.0.1]) by mail49-db3 (MessageSwitch) id 1344194254534715_2806; Sun, 5 Aug 2012 19:17:34 +0000 (UTC) Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.248]) by mail49-db3.bigfish.com (Postfix) with ESMTP id 772A72C0047 for ; Sun, 5 Aug 2012 19:17:34 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 5 Aug 2012 19:17:34 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 5 Aug 2012 12:19:34 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Sun, 5 Aug 2012 12:17:31 -0700 From: Adam Montville To: "'sacm@ietf.org'" Thread-Topic: Weekly Meetings for Charter and Use Case Discussion Thread-Index: AQHNcz71G4HXk6Xx6kKyTzC8edNDKg== Date: Sun, 5 Aug 2012 19:17:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: [sacm] Weekly Meetings for Charter and Use Case Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 19:17:38 -0000 All: Hope you're having a relaxing weekend after Vancouver! I propose that we meet on Monday, Tuesday, or Thursday at 08:00 Eastern for 30-60 minutes (depending on agenda needs). This time seems to be one that will accommodate the most people internationally. I'd like to get a time preference as soon as possible so we can start meeting right away (preferably this week). Once we generally agree on a time slot, I will schedule a recurring WebEx. Regards, Adam From david.oliva@verizon.net Sun Aug 5 13:22:55 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFFC21F8552 for ; Sun, 5 Aug 2012 13:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=0.650, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNBG+40NiOrM for ; Sun, 5 Aug 2012 13:22:54 -0700 (PDT) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A3921F854A for ; Sun, 5 Aug 2012 13:22:54 -0700 (PDT) Received: from vms170025pub.verizon.net ([unknown] [192.168.1.3]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M8A00DTATXK91PD@vms173001.mailsrvcs.net> for sacm@ietf.org; Sun, 05 Aug 2012 15:22:33 -0500 (CDT) Received: from 96.241.55.45 ([96.241.55.45]) by vms170025 (Verizon Webmail) with HTTP; Sun, 05 Aug 2012 15:22:32 -0500 (CDT) Date: Sun, 05 Aug 2012 15:22:32 -0500 (CDT) From: david.oliva@verizon.net To: david.waltermire@nist.gov, sacm@ietf.org Message-id: <30177170.1710579.1344198152943.JavaMail.root@vms170025> 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.55.45] Subject: Re: [sacm] Interop testing X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 20:22:55 -0000
&nb= sp;
 
 David and all:
 
<= DIV>Interoperability of SACM products is of interest to the users and needs= attention.
Very likely, interoperability testing will consist of=  two processes.
 
1.  Taking one va= lidated product and running content from a reputable repository (such as th= e National Checklist Program Repository).
2.  Gene= rating content from a validated product and running it on another and = viceversa.
 
The second testing process will proba= bly be needed to ensure that SCAP 1.2  Asset Management appl= ications (that incorporate Vulnerability and Configuration reporting)&= nbsp;work as intended.
 
David Oliva
&n= bsp;
 
 
On 08/03/12, Waltermire, David A.<david.walterm= ire@nist.gov> wrote:
 
Another thing we m= ight want to address in the charter is some concept of interop= testing as part of the I/D development process.  This has been di= scussed within the Security Automation community historically, but was not = mentioned during the side meeting.
 
Dave


___________________________= ____________________
sacm mailing list
sacm@ietf.org
= https://www.ietf.org/mailman/listinfo/sacm
From shanna@juniper.net Sun Aug 5 17:59:43 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D4A21F859A for ; Sun, 5 Aug 2012 17:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHo9+6zsUc71 for ; Sun, 5 Aug 2012 17:59:42 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id D5CF521F8593 for ; Sun, 5 Aug 2012 17:59:41 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUB8W/bTWNt/D6Qcl9Js8BKtngTRsxYDd@postini.com; Sun, 05 Aug 2012 17:59:42 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 5 Aug 2012 17:59:23 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Sun, 5 Aug 2012 20:59:23 -0400 From: Stephen Hanna To: Adam Montville , "'sacm@ietf.org'" Date: Sun, 5 Aug 2012 20:59:21 -0400 Thread-Topic: Weekly Meetings for Charter and Use Case Discussion Thread-Index: AQHNcz71G4HXk6Xx6kKyTzC8edNDKpdL9NaQ 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 06 Aug 2012 00:59:43 -0000 Great! All those times are fine with me. BTW, such a weekly call wouldn't be OK for an IETF Working Group. Instead, we'd want to do most of our work on the email list with occasional interim meetings, as described in this IESG statement: https://www.ietf.org/iesg/statement/interim-meetings.html However, since we don't yet have a WG or even a BOF, I don't think there's a problem with having a weekly call as a way to accelerate the development of a proposed charter and use cases. Still, I think it's essential that we consider these calls subservient to and supportive of discussions on the email list. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Sunday, August 05, 2012 3:18 PM > To: 'sacm@ietf.org' > Subject: [sacm] Weekly Meetings for Charter and Use Case Discussion >=20 > All: >=20 > Hope you're having a relaxing weekend after Vancouver! I propose that > we > meet on Monday, Tuesday, or Thursday at 08:00 Eastern for 30-60 minutes > (depending on agenda needs). This time seems to be one that will > accommodate the most people internationally. >=20 > I'd like to get a time preference as soon as possible so we can start > meeting right away (preferably this week). Once we generally agree on > a > time slot, I will schedule a recurring WebEx. >=20 > Regards, >=20 > Adam >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From amontville@tripwire.com Mon Aug 6 06:35:15 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A7C21F86B0 for ; Mon, 6 Aug 2012 06:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.864 X-Spam-Level: X-Spam-Status: No, score=-3.864 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4SPxloqL2eM for ; Mon, 6 Aug 2012 06:35:14 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 9370A21F86A8 for ; Mon, 6 Aug 2012 06:35:14 -0700 (PDT) Received: from mail112-co1-R.bigfish.com (10.243.78.234) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 Aug 2012 13:35:14 +0000 Received: from mail112-co1 (localhost [127.0.0.1]) by mail112-co1-R.bigfish.com (Postfix) with ESMTP id 2027344023F for ; Mon, 6 Aug 2012 13:35:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -32 X-BigFish: VPS-32(z3d0Izbb2dI98dI9371I148cI542M1432I4015I1447Izz1202hz31iz8275ch1033IL8275dhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail112-co1 (localhost.localdomain [127.0.0.1]) by mail112-co1 (MessageSwitch) id 1344260111733645_9113; Mon, 6 Aug 2012 13:35:11 +0000 (UTC) Received: from CO1EHSMHS013.bigfish.com (unknown [10.243.78.232]) by mail112-co1.bigfish.com (Postfix) with ESMTP id A7182140050; Mon, 6 Aug 2012 13:35:11 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by CO1EHSMHS013.bigfish.com (10.243.66.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 6 Aug 2012 13:35:09 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Aug 2012 06:37:11 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Mon, 6 Aug 2012 06:35:08 -0700 From: Adam Montville To: Stephen Hanna , "'sacm@ietf.org'" Thread-Topic: Weekly Meetings for Charter and Use Case Discussion Thread-Index: AQHNcz71G4HXk6Xx6kKyTzC8edNDKpdL9NaQgADVQAA= Date: Mon, 6 Aug 2012 13:35:07 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <5FA0627DA4828A4D8350D29351E91253@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 06 Aug 2012 13:35:15 -0000 On 8/5/12 5:59 PM, "Stephen Hanna" wrote: >Great! All those times are fine with me. > >BTW, such a weekly call wouldn't be OK for an IETF Working Group. >Instead, we'd want to do most of our work on the email list with >occasional interim meetings, as described in this IESG statement: > >https://www.ietf.org/iesg/statement/interim-meetings.html Thanks for the link! > >However, since we don't yet have a WG or even a BOF, I don't >think there's a problem with having a weekly call as a way to >accelerate the development of a proposed charter and use cases. >Still, I think it's essential that we consider these calls >subservient to and supportive of discussions on the email list. Steve, Thanks for pointing out that which can be lost from time to time - the mailing list is king, and these calls are really just an effort to get things moving quickly. > >Thanks, > >Steve > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Adam Montville >> Sent: Sunday, August 05, 2012 3:18 PM >> To: 'sacm@ietf.org' >> Subject: [sacm] Weekly Meetings for Charter and Use Case Discussion >>=20 >> All: >>=20 >> Hope you're having a relaxing weekend after Vancouver! I propose that >> we >> meet on Monday, Tuesday, or Thursday at 08:00 Eastern for 30-60 minutes >> (depending on agenda needs). This time seems to be one that will >> accommodate the most people internationally. >>=20 >> I'd like to get a time preference as soon as possible so we can start >> meeting right away (preferably this week). Once we generally agree on >> a >> time slot, I will schedule a recurring WebEx. >>=20 >> Regards, >>=20 >> Adam >>=20 >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > From amontville@tripwire.com Mon Aug 6 06:36: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 44B3B21F86A8 for ; Mon, 6 Aug 2012 06:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxlxRkoANT8F for ; Mon, 6 Aug 2012 06:36:32 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 9217821F86A5 for ; Mon, 6 Aug 2012 06:36:32 -0700 (PDT) Received: from mail177-co1-R.bigfish.com (10.243.78.233) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 Aug 2012 13:36:32 +0000 Received: from mail177-co1 (localhost [127.0.0.1]) by mail177-co1-R.bigfish.com (Postfix) with ESMTP id 0B976CC033E; Mon, 6 Aug 2012 13:36:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zzbb2dI98dI9371I542M1432I4015Izz1202hzz8275ch1033IL8275dhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail177-co1 (localhost.localdomain [127.0.0.1]) by mail177-co1 (MessageSwitch) id 1344260190564989_6964; Mon, 6 Aug 2012 13:36:30 +0000 (UTC) Received: from CO1EHSMHS014.bigfish.com (unknown [10.243.78.229]) by mail177-co1.bigfish.com (Postfix) with ESMTP id 7DEC148004A; Mon, 6 Aug 2012 13:36:30 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by CO1EHSMHS014.bigfish.com (10.243.66.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 6 Aug 2012 13:36:29 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Aug 2012 06:38:31 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Mon, 6 Aug 2012 06:36:29 -0700 From: Adam Montville To: Stephen Hanna , "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: [sacm] Interop testing Thread-Index: AQHNca5+vj+bRlxdgE+kOgZq3aShJpdIg10AgAAdDwCABC0sgA== Date: Mon, 6 Aug 2012 13:36:28 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <44341319229DB645B5F8635E0861D95D@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Subject: Re: [sacm] Interop testing X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 06 Aug 2012 13:36:33 -0000 On 8/3/12 2:58 PM, "Stephen Hanna" wrote: >I'm a big fan of interop testing. Without it, things just don't interop. >And when interop testing is combined into a certification program, >customers can find products that actually work together. If they >then require certifications in RFPs, vendors have an incentive to >make their products interop. There are lots of complexities and >pitfalls that we can talk about but... > >The IETF does not provide interop testing for its standards so I don't >think we could/should include that in our charter. Such testing is often >provided by outside labs or informal groupings (plugfests) but not by the >IETF. So while it's OK to talk a bit about interop testing on IETF lists, >such testing is not an IETF activity. At least, that's my understanding. >As such, I don't think we should talk about it in the charter. Agreed. > >There will be plenty of time to talk about interop testing and >certification >and related issues AFTER the charter has been figured out and approved. > >If other IETF experts want to weigh in on this, feel free. Paul Hoffman >(for example) has decades of experience with interop testing for IETF >specs. As interoperability is critical to this effort, I second this call for additional advice with respect to such testing. > >Thanks, > >Steve > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Adam Montville >> Sent: Friday, August 03, 2012 4:06 PM >> To: Waltermire, David A.; sacm@ietf.org >> Subject: Re: [sacm] Interop testing >>=20 >>=20 >>=20 >> From: , "David A." >> > >> Date: Friday, August 3, 2012 12:30 PM >> To: "sacm@ietf.org" >> > >> Subject: [sacm] Interop testing >>=20 >> Another thing we might want to address in the charter is some concept >> of interop testing as part of the I/D development process. This has >> been discussed within the Security Automation community historically, >> but was not mentioned during the side meeting. >>=20 >> This seems like a good idea. >>=20 >>=20 >> Dave >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > From amontville@tripwire.com Mon Aug 6 07:27:10 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9E421F858F for ; Mon, 6 Aug 2012 07:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.839 X-Spam-Level: X-Spam-Status: No, score=-3.839 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8s1imC9uHVvK for ; Mon, 6 Aug 2012 07:27:09 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id E947221F850B for ; Mon, 6 Aug 2012 07:27:08 -0700 (PDT) Received: from mail73-am1-R.bigfish.com (10.3.201.242) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 Aug 2012 14:27:07 +0000 Received: from mail73-am1 (localhost [127.0.0.1]) by mail73-am1-R.bigfish.com (Postfix) with ESMTP id E97452E0198; Mon, 6 Aug 2012 14:27:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1202hzz8275chz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail73-am1 (localhost.localdomain [127.0.0.1]) by mail73-am1 (MessageSwitch) id 134426322671805_3343; Mon, 6 Aug 2012 14:27:06 +0000 (UTC) Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.242]) by mail73-am1.bigfish.com (Postfix) with ESMTP id 0E1EC46004D; Mon, 6 Aug 2012 14:27:06 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 6 Aug 2012 14:27:05 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Aug 2012 07:29:05 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Mon, 6 Aug 2012 07:27:02 -0700 From: Adam Montville To: Stephen Hanna , Luis Nunez , Omar Santos Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAA== Date: Mon, 6 Aug 2012 14:27:01 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 06 Aug 2012 14:27:10 -0000 On 8/3/12 3:51 PM, "Stephen Hanna" wrote: > >As for defining the term "Endpoint", RFC 5209 (the NEA Overview) has >the following definition: > > Endpoint - Any computing device that can be connected to a network. > Such devices normally are associated with a particular link layer > address before joining the network and potentially an IP address > once on the network. This includes: laptops, desktops, servers, > cell phones, or any device that may have an IP address. > >Does that definition look acceptable? I hope so, since it would be >confusing to have multiple incompatible definitions of a term in >related specs! ;-) It seems acceptable to me. If there is some distinction to be made between the definition presented here and what Luis had in mind, let's explore it. > >And I also agree on the importance of scoping UC1 and UC3 carefully. >We should prioritize which parts of the problem are most urgent >and focus on those first. UC1 and UC3 both require assessment of endpoint state. If not for the NEA ties in UC1, it seems a subset of UC3. So, we should be able to start with the main concern of UC3: Security Configuration Management. From lnunez@c3isecurity.com Mon Aug 6 08:08:45 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF27321F85BB for ; Mon, 6 Aug 2012 08:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.675 X-Spam-Level: X-Spam-Status: No, score=-3.675 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FH0xIVtrbDXk for ; Mon, 6 Aug 2012 08:08:44 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8406621F84E4 for ; Mon, 6 Aug 2012 08:08:44 -0700 (PDT) Received: by yenm5 with SMTP id m5so734418yen.31 for ; Mon, 06 Aug 2012 08:08:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=POKEmy6c5zyU1/EBqrGqHq73OMkhwvMlS6l7YEo7qEI=; b=jngFx82B1ie5yZF1E3cxKVisTdftyoY6zBCPuvRumzp3+46yjR24BQY0GrLBiarE8z 6BOiER7tBheHBPVDnvg03zvFCAOtaJHvyTgQpP/GXtGreefQSDaf7vqBRzfLnjqtwK6x ayoNuTQ3fpZt4NbRavn6CxsdivenOpMytyyzW2LBJMtjIvHG5uT5VVr3WlaQQZhRoDqJ DsZUyDc16wJvQJys6AsZ5RQToHd/yoJlA+k4OiRDE08nIwKdKc0AuEPDFgfhpulzVApx umtSwJRyFxu2lxaCt6Fu6RP2G2AsbpHavk6GClvJKAyYKPouFvD6tHxp3OtkyYSDsrEr KZsQ== Received: by 10.236.131.146 with SMTP id m18mr9941725yhi.65.1344265724122; Mon, 06 Aug 2012 08:08:44 -0700 (PDT) Received: from [192.168.1.48] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id d9sm15366555ank.4.2012.08.06.08.08.42 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Aug 2012 08:08:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Luis Nunez In-Reply-To: Date: Mon, 6 Aug 2012 11:08:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adam Montville X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlTGxHIT1TgZlly75ECg4bno3fquZ9rC6B3YSHdcSFumToTzT2GULOAcKTHZMyRXABb7qCw Cc: Stephen Hanna , "'sacm@ietf.org'" Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 06 Aug 2012 15:08:46 -0000 I open for the proposed times. It may be good to have it on a Monday so = that we can work on specifics during the week. -ln On Aug 6, 2012, at 9:35 AM, Adam Montville wrote: >=20 >=20 > On 8/5/12 5:59 PM, "Stephen Hanna" wrote: >=20 >> Great! All those times are fine with me. >>=20 >> BTW, such a weekly call wouldn't be OK for an IETF Working Group. >> Instead, we'd want to do most of our work on the email list with >> occasional interim meetings, as described in this IESG statement: >>=20 >> https://www.ietf.org/iesg/statement/interim-meetings.html >=20 > Thanks for the link! >=20 >>=20 >> However, since we don't yet have a WG or even a BOF, I don't >> think there's a problem with having a weekly call as a way to >> accelerate the development of a proposed charter and use cases. >> Still, I think it's essential that we consider these calls >> subservient to and supportive of discussions on the email list. >=20 > Steve, Thanks for pointing out that which can be lost from time to = time - > the mailing list is king, and these calls are really just an effort to = get > things moving quickly. >=20 >>=20 >> Thanks, >>=20 >> Steve >>=20 >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of >>> Adam Montville >>> Sent: Sunday, August 05, 2012 3:18 PM >>> To: 'sacm@ietf.org' >>> Subject: [sacm] Weekly Meetings for Charter and Use Case Discussion >>>=20 >>> All: >>>=20 >>> Hope you're having a relaxing weekend after Vancouver! I propose = that >>> we >>> meet on Monday, Tuesday, or Thursday at 08:00 Eastern for 30-60 = minutes >>> (depending on agenda needs). This time seems to be one that will >>> accommodate the most people internationally. >>>=20 >>> I'd like to get a time preference as soon as possible so we can = start >>> meeting right away (preferably this week). Once we generally agree = on >>> a >>> time slot, I will schedule a recurring WebEx. >>>=20 >>> Regards, >>>=20 >>> Adam >>>=20 >>>=20 >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >>=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From amontville@tripwire.com Mon Aug 6 08:20: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 D111A21F85CE for ; Mon, 6 Aug 2012 08:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.828 X-Spam-Level: X-Spam-Status: No, score=-3.828 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxLvr5b+CUo6 for ; Mon, 6 Aug 2012 08:20:42 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1469721F85B8 for ; Mon, 6 Aug 2012 08:20:42 -0700 (PDT) Received: from mail111-ch1-R.bigfish.com (10.43.68.239) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 Aug 2012 15:20:40 +0000 Received: from mail111-ch1 (localhost [127.0.0.1]) by mail111-ch1-R.bigfish.com (Postfix) with ESMTP id A1E032A0297; Mon, 6 Aug 2012 15:20:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -34 X-BigFish: VPS-34(z3d0Izbb2dI98dI9371I148cI542M1452I1432I4015I1447Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h944hd25he5bhf0ah107ah) Received: from mail111-ch1 (localhost.localdomain [127.0.0.1]) by mail111-ch1 (MessageSwitch) id 1344266438724866_19944; Mon, 6 Aug 2012 15:20:38 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.228]) by mail111-ch1.bigfish.com (Postfix) with ESMTP id A35D0600C3; Mon, 6 Aug 2012 15:20:38 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 6 Aug 2012 15:20:37 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Aug 2012 08:22:38 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Mon, 6 Aug 2012 08:20:36 -0700 From: Adam Montville To: Luis Nunez Thread-Topic: [sacm] Weekly Meetings for Charter and Use Case Discussion Thread-Index: AQHNcz71G4HXk6Xx6kKyTzC8edNDKpdL9NaQgADVQACAAI+GgP//jfSs Date: Mon, 6 Aug 2012 15:20:35 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Cc: Stephen Hanna , "sacm@ietf.org" Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 06 Aug 2012 15:20:42 -0000 How are others feeling about Mondays at 08:00 Eastern? We would start next= week and go long enough to get consensus on use cases and a draft charter = - calls will augment mailing list activity and serve as high bandwidth stat= us reporting and issue identification. Sent from my iPhone On Aug 6, 2012, at 8:08 AM, "Luis Nunez" wrote: > I open for the proposed times. It may be good to have it on a Monday so = that we can work on specifics during the week. >=20 > -ln >=20 > On Aug 6, 2012, at 9:35 AM, Adam Montville wrote: >=20 >>=20 >>=20 >> On 8/5/12 5:59 PM, "Stephen Hanna" wrote: >>=20 >>> Great! All those times are fine with me. >>>=20 >>> BTW, such a weekly call wouldn't be OK for an IETF Working Group. >>> Instead, we'd want to do most of our work on the email list with >>> occasional interim meetings, as described in this IESG statement: >>>=20 >>> https://www.ietf.org/iesg/statement/interim-meetings.html >>=20 >> Thanks for the link! >>=20 >>>=20 >>> However, since we don't yet have a WG or even a BOF, I don't >>> think there's a problem with having a weekly call as a way to >>> accelerate the development of a proposed charter and use cases. >>> Still, I think it's essential that we consider these calls >>> subservient to and supportive of discussions on the email list. >>=20 >> Steve, Thanks for pointing out that which can be lost from time to time = - >> the mailing list is king, and these calls are really just an effort to g= et >> things moving quickly. >>=20 >>>=20 >>> Thanks, >>>=20 >>> Steve >>>=20 >>>> -----Original Message----- >>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf O= f >>>> Adam Montville >>>> Sent: Sunday, August 05, 2012 3:18 PM >>>> To: 'sacm@ietf.org' >>>> Subject: [sacm] Weekly Meetings for Charter and Use Case Discussion >>>>=20 >>>> All: >>>>=20 >>>> Hope you're having a relaxing weekend after Vancouver! I propose that >>>> we >>>> meet on Monday, Tuesday, or Thursday at 08:00 Eastern for 30-60 minute= s >>>> (depending on agenda needs). This time seems to be one that will >>>> accommodate the most people internationally. >>>>=20 >>>> I'd like to get a time preference as soon as possible so we can start >>>> meeting right away (preferably this week). Once we generally agree on >>>> a >>>> time slot, I will schedule a recurring WebEx. >>>>=20 >>>> Regards, >>>>=20 >>>> Adam >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >>>=20 >>=20 >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >=20 >=20 From Kent_Landfield@mcafee.com Mon Aug 6 08:24: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 ED8FC21F865F for ; Mon, 6 Aug 2012 08:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkHdi8Ct6Mz8 for ; Mon, 6 Aug 2012 08:24:14 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id DDE8021F865E for ; Mon, 6 Aug 2012 08:24:13 -0700 (PDT) Received: from DALEXHT1.corp.nai.org (unknown [10.64.5.51]) by dalsmrelay2.nai.com with smtp id 6d72_858f_3c424b7b_851e_48c7_addd_edec62c89e81; Mon, 06 Aug 2012 10:24:05 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT1.corp.nai.org ([::1]) with mapi; Mon, 6 Aug 2012 10:23:34 -0500 From: To: , Date: Mon, 6 Aug 2012 10:24:36 -0500 Thread-Topic: [sacm] Weekly Meetings for Charter and Use Case Discussion Thread-Index: Ac1z53HGVKmQyAIqQT+dsT5SBecskw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC454B4B392BCkentlandfieldmcafeecom_" MIME-Version: 1.0 Cc: shanna@juniper.net, sacm@ietf.org Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 06 Aug 2012 15:24:15 -0000 --_000_CC454B4B392BCkentlandfieldmcafeecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Personally I'd rather do this on the list. I have no problem with calls but= that reduces the transparency at a time we really need it. I will be putting out a revised agenda to the list on Wednesday with the co= mments and agreements we discussed in Vancouver. If we are going to have = a call I'd rather it be closer to the conclusion than each week. I am not = sure we will do ourselves any favors with calls on the charter at this poin= t. JMO Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Luis Nunez > Date: Monday, August 6, 2012 10:08 AM To: Adam Montville = > Cc: Stephen Hanna >, "'sacm@i= etf.org'" > Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion I open for the proposed times. It may be good to have it on a Monday so th= at we can work on specifics during the week. -ln On Aug 6, 2012, at 9:35 AM, Adam Montville wrote: On 8/5/12 5:59 PM, "Stephen Hanna" > wrote: Great! All those times are fine with me. BTW, such a weekly call wouldn't be OK for an IETF Working Group. Instead, we'd want to do most of our work on the email list with occasional interim meetings, as described in this IESG statement: https://www.ietf.org/iesg/statement/interim-meetings.html Thanks for the link! However, since we don't yet have a WG or even a BOF, I don't think there's a problem with having a weekly call as a way to accelerate the development of a proposed charter and use cases. Still, I think it's essential that we consider these calls subservient to and supportive of discussions on the email list. Steve, Thanks for pointing out that which can be lost from time to time - the mailing list is king, and these calls are really just an effort to get things moving quickly. Thanks, Steve -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Sunday, August 05, 2012 3:18 PM To: 'sacm@ietf.org' Subject: [sacm] Weekly Meetings for Charter and Use Case Discussion All: Hope you're having a relaxing weekend after Vancouver! I propose that we meet on Monday, Tuesday, or Thursday at 08:00 Eastern for 30-60 minutes (depending on agenda needs). This time seems to be one that will accommodate the most people internationally. I'd like to get a time preference as soon as possible so we can start meeting right away (preferably this week). Once we generally agree on a time slot, I will schedule a recurring WebEx. Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_CC454B4B392BCkentlandfieldmcafeecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Pers= onally I'd rather do this on the list. I have no problem with calls but tha= t reduces the transparency at a time we really need it.  
I will be putting out a revised agenda to the list on Wednesda= y with the comments and agreements we discussed in Vancouver.   If we = are going to have a call I'd rather it be closer to the conclusion than eac= h week.  I am not sure we will do ourselves any favors with calls on t= he charter at this point.

JMO

=
Kent Landfield


Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: = ww= w.mcafee.com

From: Luis Nunez <lnunez@c3isecurity.com>
Date: Monday, August 6, 2012 10:08 AM
To: Adam Montville <amontville@tripwire.com>
Cc: Stephen Hanna <shanna@juniper.net>, "'sacm= @ietf.org'" <sacm@ietf.org><= br>Subject: Re: [sacm] Weekly Meet= ings for Charter and Use Case Discussion

I open for the pro= posed times.  It may be good to have it on a Monday so that we ca= n work on specifics during the week.

-ln

On Aug 6, 2012, at 9:35 AM, Adam Montville wrote:

=
On 8/5/12 5:59 PM, "Stephen Hanna" <shanna@juniper.net> wrote:
Great! All those time= s are fine with me.
BTW, such a weekly call wouldn't= be OK for an IETF Working Group.
Instead, we'd want to do most = of our work on the email list with
occasional interim meetings, = as described in this IESG statement:
Thanks for the link!
However, since we don't yet have a WG o= r even a BOF, I don't
think there's a problem with having a week= ly call as a way to
accelerate the development of a proposed cha= rter and use cases.
Still, I think it's essential that we consid= er these calls
subservient to and supportive of discussions on t= he email list.
Steve, Thanks for pointi= ng out that which can be lost from time to time -
the mailing li= st is king, and these calls are really just an effort to get
thi= ngs moving quickly.
Thanks,
Steve
<= div>
-----O= riginal Message-----
Adam Montville
=
Sent: Sunday, August 05, 2012 3:18 PM
Subject: [sacm] Weekly Mee= tings for Charter and Use Case Discussion
All:
=
Hope you're having a relaxing weekend after Vancouver!&nb= sp; I propose that
we
meet on Monday, Tuesday, o= r Thursday at 08:00 Eastern for 30-60 minutes
(depending on agen= da needs).  This time seems to be one that will
accomm= odate the most people internationally.
I'd like to g= et a time preference as soon as possible so we can start
meeting= right away (preferably this week).  Once we generally agree on
a
time slot, I will schedule a recurring WebEx.
<= div>
Regards,
Adam
_______________________________________________
sa= cm mailing list
____________________________________= ___________
sacm mailing list

______________________________________________= _
sacm mailing list

 --_000_CC454B4B392BCkentlandfieldmcafeecom_-- From Kent_Landfield@mcafee.com Mon Aug 6 08:55: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 6EE4221F85B8 for ; Mon, 6 Aug 2012 08:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukoueO7fBbtG for ; Mon, 6 Aug 2012 08:55:49 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED7E21F85A3 for ; Mon, 6 Aug 2012 08:55:42 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 6d72_8dee_1723b178_88f6_414c_8d89_0bd8b9c55524; Mon, 06 Aug 2012 10:55:37 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Mon, 6 Aug 2012 10:54:37 -0500 From: To: , , Date: Mon, 6 Aug 2012 10:55:37 -0500 Thread-Topic: [sacm] Interop testing Thread-Index: Ac1z68dA/LvmQumITPGI97G4nfx4Jw== Message-ID: In-Reply-To: <30177170.1710579.1344198152943.JavaMail.root@vms170025> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC454EAC392DBkentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] Interop testing X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 06 Aug 2012 15:55:50 -0000 --_000_CC454EAC392DBkentlandfieldmcafeecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Interoperability testing is something we have wanted to do for quite a whil= e. I have been a big proponent of it but, I am not sure it should be in the= charter though. I would think this is something the working group could fo= ster but would like to ask others on the list with more IETF experience if = this is something that has been done in past charters? I believe that a true interoperability test at this point would be if I as = vendor A gave vendor B the content that I created and Vendor B processed it= and then gave me the results to evaluate. I would do the same with conten= t they developed. If there are deviations then the two vendors would need = to figure out what is different in the interpretation / evaluation. The pr= oblem is not evaluating content that exists in well known places but is cre= ated by guidance authors and vendors that are not well known and tested. Th= e example you gave is lacking content for most UNIX and Linux distributions= . Yes, interpretation of the well known content can be concerning but many= times that's due to what was not implemented. The other issue is there would need to be a reasonably stable test environm= ent that's configuration was known so that the results could be properly ev= aluated and relied on. That would mean multiple UNIX, Linux and Windows env= ironments at a minimum. The other issue this poses is a scalability issue.= If Vendor A needs to validate with 45+ other vendors, this becomes a very= large effort that will take good deal of planning and potentially some aut= omation to do a reasonable accurate evaluation of the generated results. I could see an Information I-D being developed that described the results /= lessons learned from interoperability testing but this type of testing req= uires that a reasonable set of vendors participate to be effective. That w= ould not be something a charter should mandate. Thoughts? Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: "david.oliva@verizon.net" > Date: Sunday, August 5, 2012 3:22 PM To: David Waltermire >, "sacm@ietf.org" > Subject: Re: [sacm] Interop testing David and all: Interoperability of SACM products is of interest to the users and needs att= ention. Very likely, interoperability testing will consist of two processes. 1. Taking one validated product and running content from a reputable repos= itory (such as the National Checklist Program Repository). 2. Generating content from a validated product and running it on another a= nd viceversa. The second testing process will probably be needed to ensure that SCAP 1.2 = Asset Management applications (that incorporate Vulnerability and Configur= ation reporting) work as intended. David Oliva On 08/03/12, Waltermire, David A.> wrote: Another thing we might want to address in the charter is some concept of in= terop testing as part of the I/D development process. This has been discus= sed within the Security Automation community historically, but was not ment= ioned during the side meeting. Dave ________________________________ _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_CC454EAC392DBkentlandfieldmcafeecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,=

Interoperability testing is something we have wan= ted to do for quite a while. I have been a big proponent of it but, I = am not sure it should be in the charter though. I would think this is somet= hing the working group could foster but would like to ask others on the lis= t with more IETF experience if this is something that has been done in past= charters?

I believe that a true interoperability = test at this point would be if I as vendor A gave vendor B the content that= I created and Vendor B processed it and then gave me the results to evalua= te.  I would do the same with content they developed.  If there a= re deviations then the two vendors would need to figure out what is differe= nt in the interpretation / evaluation.  The problem is not evaluating = content that exists in well known places but is created by guidance authors= and vendors that are not well known and tested. The example you gave is la= cking content for most UNIX and Linux distributions. Yes, interpretation of= the well known content can be concerning but  many times that's due t= o what was not implemented.

The other issue is the= re would need to be a reasonably stable test environment that's configurati= on was known so that the results could be properly evaluated and relied on.= That would mean multiple UNIX, Linux and Windows environments at a minimum= .  The other issue this poses is a scalability issue.  If Vendor = A needs to validate with 45+ other vendors, this becomes a very large effor= t that will take good deal of planning and potentially some automation to d= o a reasonable accurate evaluation of the generated results.

=
I could see an Information I-D being developed that described th= e results / lessons learned from interoperability testing but this type of = testing requires that a reasonable set of vendors participate to be effecti= ve.  That would not be something a charter should mandate.
<= br>
Thoughts?

Kent Landfield=

McAfee | An Intel Co= mpany
Di= rect: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

Fro= m: "david.oliva@verizon.= net" <david.oliva@verizon= .net>
Date: Sunday, Augu= st 5, 2012 3:22 PM
To: David Wa= ltermire <david.waltermire@= nist.gov>, "sacm@ietf.org" <= sacm@ietf.org>
Subject: Re: [sacm] Interop testing
<= br>
 
=  
 David and all:
 
Interopera= bility of SACM products is of interest to the users and needs attention.
Very likely, interoperability testing will consist of two proc= esses.
 
1.  Taking one validated produc= t and running content from a reputable repository (such as the National Che= cklist Program Repository).
2.  Generating content= from a validated product and running it on another and viceversa.
 
The second testing process will probably be needed = to ensure that SCAP 1.2  Asset Management applications (that= incorporate Vulnerability and Configuration reporting) work as i= ntended.
 
David Oliva
 
 
=  
On 08/03/12, Waltermire, David A.<david.waltermire@nist.gov> wrote: 
Another thing we might want to address in the = charter is some concept of interop testing as part of the I/D d= evelopment process.  This has been discussed within the Security Autom= ation community historically, but was not mentioned during the side meeting= .
&nbs= p;
Dave
=


______________________________________________= _
sacm mailing list
sacm@ietf.org
https://w= ww.ietf.org/mailman/listinfo/sacm
 --_000_CC454EAC392DBkentlandfieldmcafeecom_-- From amontville@tripwire.com Mon Aug 6 09:00: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 C6E0221F859A for ; Mon, 6 Aug 2012 09:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.818 X-Spam-Level: X-Spam-Status: No, score=-3.818 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3iH+w9GmMp9 for ; Mon, 6 Aug 2012 09:00:58 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 80B8421F84E6 for ; Mon, 6 Aug 2012 09:00:57 -0700 (PDT) Received: from mail99-db3-R.bigfish.com (10.3.81.225) by DB3EHSOBE007.bigfish.com (10.3.84.27) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 Aug 2012 16:00:56 +0000 Received: from mail99-db3 (localhost [127.0.0.1]) by mail99-db3-R.bigfish.com (Postfix) with ESMTP id 57C951802B4; Mon, 6 Aug 2012 16:00:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -43 X-BigFish: VPS-43(z3d0Izbb2dI98dI9371I9f17R148cI542M1452I4015I1447Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h946he5bhf0ah107ah) Received: from mail99-db3 (localhost.localdomain [127.0.0.1]) by mail99-db3 (MessageSwitch) id 1344268855185998_17026; Mon, 6 Aug 2012 16:00:55 +0000 (UTC) Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.225]) by mail99-db3.bigfish.com (Postfix) with ESMTP id 28B56A0071; Mon, 6 Aug 2012 16:00:55 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 6 Aug 2012 16:00:53 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Aug 2012 09:02:53 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Mon, 6 Aug 2012 09:00:50 -0700 From: Adam Montville To: "Kent_Landfield@McAfee.com" , "lnunez@c3isecurity.com" Thread-Topic: [sacm] Weekly Meetings for Charter and Use Case Discussion Thread-Index: AQHNcz71G4HXk6Xx6kKyTzC8edNDKpdL9NaQgADVQACAAI+GgIAABGsA//+UxoA= Date: Mon, 6 Aug 2012 16:00:50 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Cc: "shanna@juniper.net" , "sacm@ietf.org" Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 06 Aug 2012 16:00:58 -0000 From: kent_landfield > Date: Monday, August 6, 2012 8:24 AM To: "lnunez@c3isecurity.com" >, Adam Montville > Cc: "shanna@juniper.net" >, "sacm@ietf.org" > Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion Personally I'd rather do this on the list. I have no problem with calls but= that reduces the transparency at a time we really need it. It's no problem to do this on the list either, but I want to emphasize that= the calls would merely be a way to keep momentum going and that it's up to= us as to whether transparency is reduced. To be clear, the intent of havi= ng calls would not be to reduce transparency. That said, if most would pre= fer working from the list, then that's exactly what we should (and will) do= . I will be putting out a revised agenda to the list on Wednesday with the co= mments and agreements we discussed in Vancouver. Did you mean a revised charter? If we are going to have a call I'd rather it be closer to the conclusion th= an each week. This sounds like a preference for Thursday, if calls are had. I am not sure we will do ourselves any favors with calls on the charter at= this point. I think the calls are intended to be checkpoints for status and to quickly = identify/raise issues =96 think of them more along the lines of a scrum sta= ndup than a working session. That said, I'm not sure that calls would not = do the charter or use case documents a favor =96 perhaps to the contrary. JMO If that's "just my opinion," then mine too. ;-) Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Luis Nunez > Date: Monday, August 6, 2012 10:08 AM To: Adam Montville = > Cc: Stephen Hanna >, "'sacm@i= etf.org'" > Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion I open for the proposed times. It may be good to have it on a Monday so th= at we can work on specifics during the week. -ln On Aug 6, 2012, at 9:35 AM, Adam Montville wrote: On 8/5/12 5:59 PM, "Stephen Hanna" > wrote: Great! All those times are fine with me. BTW, such a weekly call wouldn't be OK for an IETF Working Group. Instead, we'd want to do most of our work on the email list with occasional interim meetings, as described in this IESG statement: https://www.ietf.org/iesg/statement/interim-meetings.html Thanks for the link! However, since we don't yet have a WG or even a BOF, I don't think there's a problem with having a weekly call as a way to accelerate the development of a proposed charter and use cases. Still, I think it's essential that we consider these calls subservient to and supportive of discussions on the email list. Steve, Thanks for pointing out that which can be lost from time to time - the mailing list is king, and these calls are really just an effort to get things moving quickly. Thanks, Steve -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Sunday, August 05, 2012 3:18 PM To: 'sacm@ietf.org' Subject: [sacm] Weekly Meetings for Charter and Use Case Discussion All: Hope you're having a relaxing weekend after Vancouver! I propose that we meet on Monday, Tuesday, or Thursday at 08:00 Eastern for 30-60 minutes (depending on agenda needs). This time seems to be one that will accommodate the most people internationally. I'd like to get a time preference as soon as possible so we can start meeting right away (preferably this week). Once we generally agree on a time slot, I will schedule a recurring WebEx. Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From Kent_Landfield@mcafee.com Mon Aug 6 09:05:00 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F7F11E8072 for ; Mon, 6 Aug 2012 09:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dp2AWakLLv8K for ; Mon, 6 Aug 2012 09:04:59 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 427A421F8617 for ; Mon, 6 Aug 2012 09:04:59 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 6d72_93b3_351ae953_bb9f_4184_9aba_9144452ddfce; Mon, 06 Aug 2012 11:04:51 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Mon, 6 Aug 2012 11:03:17 -0500 From: To: , Date: Mon, 6 Aug 2012 11:04:16 -0500 Thread-Topic: [sacm] Weekly Meetings for Charter and Use Case Discussion Thread-Index: Ac1z7P19HOFe6MqYT9OOKJ4FBPuwfg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC4554F839313kentlandfieldmcafeecom_" MIME-Version: 1.0 Cc: shanna@juniper.net, sacm@ietf.org Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 06 Aug 2012 16:05:00 -0000 --_000_CC4554F839313kentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable :-) Yes, a revised charter=85. Doing too many meetings lately. ;-) Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville > Date: Monday, August 6, 2012 11:00 AM To: Kent Landfield >, Luis Nunez > Cc: "shanna@juniper.net" >, "sacm@ietf.org" > Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion From: kent_landfield > Date: Monday, August 6, 2012 8:24 AM To: "lnunez@c3isecurity.com" >, Adam Montville > Cc: "shanna@juniper.net" >, "sacm@ietf.org" > Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion Personally I'd rather do this on the list. I have no problem with calls but= that reduces the transparency at a time we really need it. It's no problem to do this on the list either, but I want to emphasize that= the calls would merely be a way to keep momentum going and that it's up to= us as to whether transparency is reduced. To be clear, the intent of havi= ng calls would not be to reduce transparency. That said, if most would pre= fer working from the list, then that's exactly what we should (and will) do= . I will be putting out a revised agenda to the list on Wednesday with the co= mments and agreements we discussed in Vancouver. Did you mean a revised charter? If we are going to have a call I'd rather it be closer to the conclusion th= an each week. This sounds like a preference for Thursday, if calls are had. I am not sure we will do ourselves any favors with calls on the charter at = this point. I think the calls are intended to be checkpoints for status and to quickly = identify/raise issues =96 think of them more along the lines of a scrum sta= ndup than a working session. That said, I'm not sure that calls would not = do the charter or use case documents a favor =96 perhaps to the contrary. JMO If that's "just my opinion," then mine too. ;-) Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Luis Nunez > Date: Monday, August 6, 2012 10:08 AM To: Adam Montville = > Cc: Stephen Hanna >, "'sacm@ietf.org'" > Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion I open for the proposed times. It may be good to have it on a Monday so th= at we can work on specifics during the week. -ln On Aug 6, 2012, at 9:35 AM, Adam Montville wrote: On 8/5/12 5:59 PM, "Stephen Hanna" > wrote: Great! All those times are fine with me. BTW, such a weekly call wouldn't be OK for an IETF Working Group. Instead, we'd want to do most of our work on the email list with occasional interim meetings, as described in this IESG statement: https://www.ietf.org/iesg/statement/interim-meetings.html Thanks for the link! However, since we don't yet have a WG or even a BOF, I don't think there's a problem with having a weekly call as a way to accelerate the development of a proposed charter and use cases. Still, I think it's essential that we consider these calls subservient to and supportive of discussions on the email list. Steve, Thanks for pointing out that which can be lost from time to time - the mailing list is king, and these calls are really just an effort to get things moving quickly. Thanks, Steve -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville Sent: Sunday, August 05, 2012 3:18 PM To: 'sacm@ietf.org' Subject: [sacm] Weekly Meetings for Charter and Use Case Discussion All: Hope you're having a relaxing weekend after Vancouver! I propose that we meet on Monday, Tuesday, or Thursday at 08:00 Eastern for 30-60 minutes (depending on agenda needs). This time seems to be one that will accommodate the most people internationally. I'd like to get a time preference as soon as possible so we can start meeting right away (preferably this week). Once we generally agree on a time slot, I will schedule a recurring WebEx. Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_CC4554F839313kentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
:-) Ye= s, a revised charter=85.  Doing too many meetings lately. ;-)

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 <= /span>
= Mobile: +1.81= 7.637.8026=
Web: www.mcafee.com
From: Adam Montville = <amontville@tripwire.com&= gt;
Date: Monday, August 6, 201= 2 11:00 AM
To: Kent Landfield &= lt;Kent_Landfield@McAfee.com>, Luis Nunez <lnunez@c3i= security.com>
Cc: "= shanna@juniper.net" <shanna@juniper.net>, "sacm@ietf.org" <sacm@ietf.org>
Subje= ct: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion<= br>



From: kent_landfield <kent_landfield@mcafee.com<<= a href=3D"mailto:kent_landfield@mcafee.com>">mailto:kent_landfield@mcafe= e.com>>
Date: Monday, August 6, 2012 8:24 AM
=
Subject: Re: [sacm] = Weekly Meetings for Charter and Use Case Discussion

Personally I'd rather do this on the list. I have no problem with calls b= ut that reduces the transparency at a time we really need it.
It's no problem to do this on the list either, but I want to em= phasize that the calls would merely be a way to keep momentum going and tha= t it's up to us as to whether transparency is reduced.  To be cle= ar, the intent of having calls would not be to reduce transparency. &n= bsp;That said, if most would prefer working from the list, then that's exac= tly what we should (and will) do.


I= will be putting out a revised agenda to the list on Wednesday with the com= ments and agreements we discussed in Vancouver.

Di= d you mean a revised charter?

If we are going to h= ave a call I'd rather it be closer to the conclusion than each week.
<= div>
This sounds like a preference for Thursday, if calls are= had.

I am not sure we will do ourselves any favo= rs with calls on the charter at this point.

I thin= k the calls are intended to be checkpoints for status and to quickly identi= fy/raise issues =96 think of them more along the lines of a scrum standup t= han a working session.  That said, I'm not sure that calls would = not do the charter or use case documents a favor =96 perhaps to the contrar= y.


JMO

If = that's "just my opinion," then mine too. ;-)

=

Kent Landfield

McAfee | An Int= el Company
Direct: +1.972.963.7096
Mobile: +1.8= 17.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

Date: Monday, August 6, 2012 10:08 AM
Subject: Re: [sacm] Weekly Meetings= for Charter and Use Case Discussion

I open for th= e proposed times.  It may be good to have it on a Monday so that = we can work on specifics during the week.

-ln

On Aug 6, 2012, at 9:35 AM, Adam Montville wrote:

On 8/5/12 5:59 PM, "Stephen Hanna" <shanna@juniper.net<mailto:shanna@juniper.net>> wrote:
Great! All those times are fine with me.
BTW, such a weekly= call wouldn't be OK for an IETF Working Group.
Instead, we'd wan= t to do most of our work on the email list with
occasional interi= m meetings, as described in this IESG statement:
Thanks for the link!
However, since we don't yet have a WG or even a BOF, I don't
think there's a problem with having a weekly call as a way to
= accelerate the development of a proposed charter and use cases.
S= till, I think it's essential that we consider these calls
subserv= ient to and supportive of discussions on the email list.
Steve, T= hanks for pointing out that which can be lost from time to time -
the mailing list is king, and these calls are really just an effort to get=
things moving quickly.
Thanks,
Steve
-----Original Message-----
Adam Mo= ntville
Sent: Sunday, August 05, 2012 3:18 PM
Subject: [sacm] Wee= kly Meetings for Charter and Use Case Discussion
All:
H= ope you're having a relaxing weekend after Vancouver!  I propose = that
we
meet on Monday, Tuesday, or Thursday at 08:00 E= astern for 30-60 minutes
(depending on agenda needs).  = This time seems to be one that will
accommodate the most people i= nternationally.
I'd like to get a time preference as soon as poss= ible so we can start
meeting right away (preferably this week).&n= bsp; Once we generally agree on
a
time slot, I wil= l schedule a recurring WebEx.
Regards,
Adam
_= ______________________________________________
sacm mailing list<= /div>
_______________________________________________
sacm mailing list
--_000_CC4554F839313kentlandfieldmcafeecom_-- From mrex@sap.com Mon Aug 6 09:32:25 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5600E21F84FE for ; Mon, 6 Aug 2012 09:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.878 X-Spam-Level: X-Spam-Status: No, score=-8.878 tagged_above=-999 required=5 tests=[AWL=-1.229, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQf+mnpXJV3f for ; Mon, 6 Aug 2012 09:32:23 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2EE21F8523 for ; Mon, 6 Aug 2012 09:32:23 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q76GWLCA028880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Aug 2012 18:32:21 +0200 (MEST) In-Reply-To: <501D2DAC.7000908@yaanatech.com> To: tony@yaanatech.com Date: Mon, 6 Aug 2012 18:32:21 +0200 (CEST) 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: <20120806163221.42ED71A127@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: mrex@sap.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: Mon, 06 Aug 2012 16:32:25 -0000 Tony Rutkowski wrote: > > Martin Rex wrote: >> >> In Germany, an employer monitoring a company-owned PC that an employee uses >> for communication (EMail, VoiP, IM) would be unconditionally illegal. > > Really? No kidding! > > That is not consistent with comments > I've seen concerning German law. There is a significant amount of mis-information floating the internet. And a mindboggling large number of lawyers are making wild guesses, rather that doing research. The decisions of the german federal constitional court (GFCC) have been quite consistent over the past decade about what with respect to encroaching on the general right of personality, informational self-determination, freedom of conduct and created a "fundamental right to the guarantee of the integrity and confidentiality of information technology systems". The court has set the minimum requirements that are prerequisite to such encroachment, such as the prerequisite of a clear formal statute law, which needs to be limited to situation where real facts create probable cause. The original GFCC decision in german language is quite comprehensible (to me, at least), while I'm having some difficulties understanding the english translation (and the english translation is shorter!?). BVerfG-Entscheidung "1 BvR 370/07 vom 27.2.2008" Randnummer 196- http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007.html#abs196 english translation of "1 BvR 370/07 vom 27.2.2008" http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007en.html#abs130 > > To be *unconditionally* illegal, would > preclude almost any rationally required > maintenance or threat mitigation. It is possible to perform maintenance and threat mitigation entirely without "monitoring" systems. A mere threat is insufficient for monitoring, if that involves collecting PII data, i.e. data from which a persons conduct can be infered. > > It is fair to observe that recent German > Constitutional Court decisions impose > constraints, but they certainly are > not "unconditional." One of the prerequisite is a clear formal statute law, which currently does not exist for the purposes "sacm" is about. quoting from the above GFCC decision: 2. The fundamental right to the guarantee of the confidentiality and integrity of information technology systems is not unrestricted. Encroachments may be justified both for preventive purposes, and for criminal prosecution. The individual must only accept such restrictions of his or her right which are based on a statutory foundation that is constitutional. This currently makes collecting data about peoples conduct "unconditionally" illegal for most practical purposes (exempting from prosecution only individual occasions of justified self-defence against an imminent vicious attack based on real facts that create probable cause). This applies to all surveillance that impairs persons "freedom of conduct". The majority of past decisions of specific events was about surveillance with a camera, but the GFCC decision makes it crystal clear that this applies to *any* kind of surveillance. Different to monitoring of computer systems, there is statutory law for camera surveillance, that allows optical surveillance under certain conditions (Art. 6b BDSG "BundesDatenSchutzGesetz). The lack of a formal statutory foundation makes surveillance illegal and entitles subjects to "cease and desist" rulings and sometimes damages. In one more recent (and constitutionally correct) rulings, an employer had put up a camera that had in view not only the entrance door, but also two workplaces. The employees protested against this camera, but the employer would not "fix" it, so at least one employee sued, The court confirmed that this camera surveillance at the workplace was illegal due to its chilling effect alone, and since it had been installed for a whole year, the employee was arwarded 4 month of income as damages (for the chilling effect). Another recent decision was about evidence from a covert video surveillance showing an employee taking a package of cigarettes on two occasions, where the German Federal Labour Court (the supreme court for labor related issues) remanded the decision to the trial court because it had failed to establish whether the covert video surveillance really met all constitutional prerequisites otherwise the video surveillance would have been illegal and not be admissible as evidence in court. (German decision: http://lexetius.com/2012,2351) The German Federal Constitional Court neutered numerous laws during the last decade due to lack of clarity and/or overbroad encroachment of the personal right of self-determination and the right to confidentiality of telecommunications. See also the GFCC decision about the scanning of license plates (the decision 1 BvR 2074/05 vom 11.3.2008 in german) http://www.bverfg.de/entscheidungen/rs20080311_1bvr2-07405.html where it confirmed that data collection requires formal statue law, and that the law in question wasn't limited to probable cause and therefore unconstitutional. The only currently existing formal statue law in Germany, that could be used in some limited fashion for "Monitoring" is Art.100 TKG, http://www.gesetze-im-internet.de/tkg_2004/__100.html but that statue is clearly limited in purpose, it will not allow that data to be used for automatic surveillance of "employee conduct" with respect to "company-defined policies". Employers try hard to avoid TKG for their networks (for which they will have to formally register), but that also means that they do not have a formal statutory law for performing any kind of surveillance/monitoring as described in Art. 100 TKG for systems that are used by employees for telecommunications and a significant part of their daily activies. -Martin From Kent_Landfield@mcafee.com Mon Aug 6 09:43: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 689DC21E8085 for ; Mon, 6 Aug 2012 09:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxMK6TINezke for ; Mon, 6 Aug 2012 09:43:19 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id ADF5621E8044 for ; Mon, 6 Aug 2012 09:43:18 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 6d84_5de6_394bbcfe_5e39_4f8b_b998_d1d353233b28; Mon, 06 Aug 2012 11:43:10 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Mon, 6 Aug 2012 11:41:54 -0500 From: To: , Date: Mon, 6 Aug 2012 11:42:55 -0500 Thread-Topic: [sacm] Legal aspects of System monitoring Thread-Index: Ac1z8mLKE6tXRjevQN6OuxRblWbQ3Q== Message-ID: In-Reply-To: <20120806163221.42ED71A127@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC455CE539383kentlandfieldmcafeecom_" MIME-Version: 1.0 Cc: sacm@ietf.org Subject: Re: [sacm] Legal aspects of System 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: Mon, 06 Aug 2012 16:43:20 -0000 --_000_CC455CE539383kentlandfieldmcafeecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable None of the efforts we are talking about for SACM are targeted toward PII o= r individuals. They are targeted at the configuration of the platforms depl= oyed in the enterprise to assure they comply with the site's security polic= y. PII is not collected. This is not monitoring of individual or employee = actions. I am not a lawyer and will not speak as one. We will let the lawy= er's decide at the appropriate time. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Martin Rex > Reply-To: "mrex@sap.com" > Date: Monday, August 6, 2012 11:32 AM To: "tony@yaanatech.com" > Cc: "mrex@sap.com" >= , "sacm@ietf.org" > Subject: Re: [sacm] Legal aspects of System monitoring Tony Rutkowski wrote: Martin Rex wrote: In Germany, an employer monitoring a company-owned PC that an employee uses for communication (EMail, VoiP, IM) would be unconditionally illegal. Really? No kidding! That is not consistent with comments I've seen concerning German law. There is a significant amount of mis-information floating the internet. And a mindboggling large number of lawyers are making wild guesses, rather that doing research. The decisions of the german federal constitional court (GFCC) have been quite consistent over the past decade about what with respect to encroaching on the general right of personality, informational self-determination, freedom of conduct and created a "fundamental right to the guarantee of the integrity and confidentiality of information technology systems". The court has set the minimum requirements that are prerequisite to such encroachment, such as the prerequisite of a clear formal statute law, which needs to be limited to situation where real facts create probable cause. The original GFCC decision in german language is quite comprehensible (to me, at least), while I'm having some difficulties understanding the english translation (and the english translation is shorter!?). BVerfG-Entscheidung "1 BvR 370/07 vom 27.2.2008" Randnummer 196- http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007.html#abs196 english translation of "1 BvR 370/07 vom 27.2.2008" http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007en.html#abs130 To be *unconditionally* illegal, would preclude almost any rationally required maintenance or threat mitigation. It is possible to perform maintenance and threat mitigation entirely without "monitoring" systems. A mere threat is insufficient for monitoring, if that involves collecting PII data, i.e. data from which a persons conduct can be infered. It is fair to observe that recent German Constitutional Court decisions impose constraints, but they certainly are not "unconditional." One of the prerequisite is a clear formal statute law, which currently does not exist for the purposes "sacm" is about. quoting from the above GFCC decision: 2. The fundamental right to the guarantee of the confidentiality and integrity of information technology systems is not unrestricted. Encroachments may be justified both for preventive purposes, and for criminal prosecution. The individual must only accept such restrictions of his or her right which are based on a statutory foundation that is constitutional. This currently makes collecting data about peoples conduct "unconditionally= " illegal for most practical purposes (exempting from prosecution only individual occasions of justified self-defence against an imminent vicious attack based on real facts that create probable cause). This applies to all surveillance that impairs persons "freedom of conduct". The majority of past decisions of specific events was about surveillance with a camera, but the GFCC decision makes it crystal clear that this applies to *any* kind of surveillance. Different to monitoring of computer systems, there is statutory law for camera surveillance, that allows optical surveillance under certain conditions (Art. 6b BDSG "BundesDatenSchutzGesetz). The lack of a formal statutory foundation makes surveillance illegal and entitles subjects to "cease and desist" rulings and sometimes damages. In one more recent (and constitutionally correct) rulings, an employer had put up a camera that had in view not only the entrance door, but also two workplaces. The employees protested against this camera, but the employer would not "fix" it, so at least one employee sued, The court confirmed that this camera surveillance at the workplace was illegal due to its chilling effect alone, and since it had been installed for a whole year, the employee was arwarded 4 month of income as damages (for the chilling effect). Another recent decision was about evidence from a covert video surveillance showing an employee taking a package of cigarettes on two occasions, where the German Federal Labour Court (the supreme court for labor related issues) remanded the decision to the trial court because it had failed to establish whether the covert video surveillance really met all constitutional prerequisites otherwise the video surveillance would have been illegal and not be admissible as evidence in court. (German decision: http://lexetius.com/2012,2351) The German Federal Constitional Court neutered numerous laws during the last decade due to lack of clarity and/or overbroad encroachment of the personal right of self-determination and the right to confidentiality of telecommunications. See also the GFCC decision about the scanning of license plates (the decision 1 BvR 2074/05 vom 11.3.2008 in german) http://www.bverfg.de/entscheidungen/rs20080311_1bvr2-07405.html where it confirmed that data collection requires formal statue law, and that the law in question wasn't limited to probable cause and therefore unconstitutional. The only currently existing formal statue law in Germany, that could be used in some limited fashion for "Monitoring" is Art.100 TKG, http://www.gesetze-im-internet.de/tkg_2004/__100.html but that statue is clearly limited in purpose, it will not allow that data to be used for automatic surveillance of "employee conduct" with respect to "company-defined policies". Employers try hard to avoid TKG for their networks (for which they will have to formally register), but that also means that they do not have a formal statutory law for performing any kind of surveillance/monitoring as described in Art. 100 TKG for systems that are used by employees for telecommunications and a significant part of their daily activies. -Martin _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_CC455CE539383kentlandfieldmcafeecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
None= of the efforts we are talking about for SACM are targeted toward PII or in= dividuals. They are targeted at the configuration of the platforms deployed= in the enterprise to assure they comply with the site's security policy. &= nbsp;PII is not collected. This is not monitoring of individual or employee= actions.  I am not a lawyer and will not speak as one. We will let th= e lawyer's decide at the appropriate time.

Kent Landfi= eld
= Mc= Afee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com=

From: Martin Rex <m= rex@sap.com>
Reply-To: "= mrex@sap.com" <mrex@sap.com>
Date: <= /span> Monday, August 6, 2012 11:32 AM
= To: "tony@yaanatech.com" = <tony@yaanatech.com>
Cc: "= mrex@sap.com" <mrex@sap.com>,= "sacm@ietf.org" <sacm@ietf.org>
S= ubject: Re: [sacm] Legal aspects of System monitoring

Tony Rutkowski wrote:
Martin Rex wrote:

In Germany, an employer monit= oring a company-owned PC that an employee uses
for communication= (EMail, VoiP, IM) would be unconditionally illegal.

Really?

No kidding!<= /div>



That is not consistent with comments
=
I've seen concerning German law.

There is a significant amount of mis-information floating the internet.
And a mindboggling large number of lawyers are making wild guesses= , rather
that doing research.

The decisi= ons of the german federal constitional court (GFCC) have been
qui= te consistent over the past decade about what with respect to
enc= roaching on the general right of personality, informational
self-= determination, freedom of conduct and created a "fundamental right
to the guarantee of the integrity and confidentiality of information
technology systems".  The court has set the minimum require= ments that
are prerequisite to such encroachment, such as the pre= requisite of a
clear formal statute law, which needs to be limite= d to situation where
real facts create probable cause.
=
The original GFCC decision in german language is quite compr= ehensible
(to me, at least), while I'm having some difficulties u= nderstanding
the english translation (and the english translation= is shorter!?).

BVerfG-Entscheidung "1 BvR 370/07 = vom 27.2.2008" Randnummer 196-

eng= lish translation of "1 BvR 370/07 vom 27.2.2008"
<= div>

To be *unconditionally* illegal, would
p= reclude almost any rationally required
maintenance or threat mit= igation.

It is possible to perform ma= intenance and threat mitigation entirely
without "monitoring" sys= tems.

A mere threat is insufficient for monitoring= , if that involves collecting
PII data, i.e. data from which a pe= rsons conduct can be infered.



It is fair t= o observe that recent German
Constitutional Court decisions impo= se
constraints, but they certainly are
not "unconditi= onal."

One of the prerequisite is a c= lear formal statute law,
which currently does not exist for the p= urposes "sacm" is about.

quoting from the above GF= CC decision:

  2. The fundamental right = to the guarantee of the confidentiality and
  integrity= of information technology systems is not unrestricted.
 &nb= sp;Encroachments may be justified both for preventive purposes, and for
  criminal prosecution.  The individual must onl= y accept such restrictions
  of his or her right which = are based on a statutory foundation that
  is constitut= ional.


This currently makes collec= ting data about peoples conduct "unconditionally"
illegal for mos= t practical purposes (exempting from prosecution only
individual = occasions of justified self-defence against an imminent
vicious a= ttack based on real facts that create probable cause).

=
This applies to all surveillance that impairs persons "freedom of cond= uct".
The majority of past decisions of specific events was about= surveillance
with a camera, but the GFCC decision makes it cryst= al clear that
this applies to *any* kind of surveillance. &n= bsp;Different to monitoring of
computer systems, there is statuto= ry law for camera surveillance,
that allows optical surveillance = under certain conditions
(Art. 6b BDSG "BundesDatenSchutzGesetz).=

The lack of a formal statutory foundation makes s= urveillance illegal
and entitles subjects to "cease and desist" r= ulings and sometimes
damages.

In one mor= e recent (and constitutionally correct) rulings, an employer
had = put up a camera that had in view not only the entrance door, but
= also two workplaces.  The employees protested against this camera= ,
but the employer would not "fix" it, so at least one employee s= ued,
The court confirmed that this camera surveillance at the wor= kplace
was illegal due to its chilling effect alone, and since it= had been
installed for a whole year, the employee was arwarded 4= month of income
as damages (for the chilling effect).
=
Another recent decision was about evidence from a covert vid= eo
surveillance showing an employee taking a package of cigarette= s
on two occasions, where the German Federal Labour Court
(the supreme court for labor related issues) remanded the decision
=
to the trial court because it had failed to establish whether the
covert video surveillance really met all constitutional prerequisites=
otherwise the video surveillance would have been illegal and not=
be admissible as evidence in court.
(German decision: = http://lexetius.com/2012,2351= )

The German Federal Constitional Court neutered n= umerous laws during the
last decade due to lack of clarity and/or= overbroad encroachment of
the personal right of self-determinati= on and the right to confidentiality
of telecommunications.
<= div>
See also the GFCC decision about the scanning of license= plates
(the decision 1 BvR 2074/05 vom 11.3.2008 in german)
http://www.bverfg.de/entscheidungen/rs20080311_1bvr2-07405.html<= /div>

where it confirmed that data collection requires f= ormal statue law,
and that the law in question wasn't limited to = probable cause and
therefore unconstitutional.


The only currently existing formal statue law in Germ= any, that could be
used in some limited fashion for "Monitoring" = is Art.100 TKG,
but that statue is clearly limited in purpose, it wil= l not allow that data
to be used for automatic surveillance of "e= mployee conduct" with respect
to "company-defined policies". = ; Employers try hard to avoid TKG for their
networks (for wh= ich they will have to formally register), but that also
means tha= t they do not have a formal statutory law for performing any
kind= of surveillance/monitoring as described in Art. 100 TKG for systems
<= div>that are used by employees for telecommunications and a significant par= t
of their daily activies.


-Martin
_______________________________________________
sacm mailing list

 --_000_CC455CE539383kentlandfieldmcafeecom_-- From lnunez@c3isecurity.com Mon Aug 6 10:16:00 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5807511E808A for ; Mon, 6 Aug 2012 10:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.667 X-Spam-Level: X-Spam-Status: No, score=-3.667 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZLXq1xY7OU7 for ; Mon, 6 Aug 2012 10:15:58 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC6821F85D6 for ; Mon, 6 Aug 2012 10:15:58 -0700 (PDT) Received: by yenm5 with SMTP id m5so889811yen.31 for ; Mon, 06 Aug 2012 10:15:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=ujNU1vlDR4eOJvRT4kChXvf3aZSo+LG04urTz2PYFa0=; b=KShZ5N7BqSAfjQDTvvC9X+dxdgOZxmL5kElOYm1eALe/A3lWKOQgTWvjsMcSHA3YmS 5oWX3DhtQsCrcOU5XjIKhA69I6xB+o4/N6/C9hKl97eoHKgHgdhnLPQ7rT8xAv+XkAX5 bgehgFGWphsJ4ko5ALSzNQU7k7ZsoANHaI7Qf79unBfuHHO73EHXyF7RZ/3eJLadw87R B/lwmqnIGJOazkFL/ybOVzox0EP12fd+PrOOgyXfWgXS1585wZneg/sOJPwDRnyF1CTt BaUoJLekTrBPxmwGkdXycO1JH5ZVUqi2+5TNMJCroH9Q2P16TZqByjgzlfDwhVqDO/yG aRRw== Received: by 10.101.152.14 with SMTP id e14mr3201935ano.83.1344273357877; Mon, 06 Aug 2012 10:15:57 -0700 (PDT) Received: from [192.168.1.48] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id t20sm15644317anl.19.2012.08.06.10.15.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Aug 2012 10:15:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_E88926A6-F667-4A75-8C94-12A608F7AC31" From: Luis Nunez In-Reply-To: Date: Mon, 6 Aug 2012 13:16:00 -0400 Message-Id: References: To: X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnSXzC1LwMPq4WCwc4mz4/r0t2RETyjilkooddwSXx2QM5S0a6IQr2zF5AlFuugouMNMGyD Cc: mrex@sap.com, sacm@ietf.org, tony@yaanatech.com Subject: Re: [sacm] Legal aspects of System 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: Mon, 06 Aug 2012 17:16:00 -0000 --Apple-Mail=_E88926A6-F667-4A75-8C94-12A608F7AC31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Looking at it another way I could see security automation as a way to = discover if a system is configured to meet privacy policies . =20 Security automation is an enabler for transparency so that individuals = and organizations may understand the complex computing environment. Thanks for bring up this issue. As a community we may want to look at = building content around privacy controls. -ln On Aug 6, 2012, at 12:42 PM, wrote: > None of the efforts we are talking about for SACM are targeted toward = PII or individuals. They are targeted at the configuration of the = platforms deployed in the enterprise to assure they comply with the = site's security policy. PII is not collected. This is not monitoring of = individual or employee actions. I am not a lawyer and will not speak as = one. We will let the lawyer's decide at the appropriate time. >=20 > Kent Landfield >=20 > McAfee | An Intel Company > Direct: +1.972.963.7096=20 > Mobile: +1.817.637.8026 > Web: www.mcafee.com >=20 > From: Martin Rex > Reply-To: "mrex@sap.com" > Date: Monday, August 6, 2012 11:32 AM > To: "tony@yaanatech.com" > Cc: "mrex@sap.com" , "sacm@ietf.org" > Subject: Re: [sacm] Legal aspects of System monitoring >=20 >> Tony Rutkowski wrote: >>> Martin Rex wrote: >>>>=20 >>>> In Germany, an employer monitoring a company-owned PC that an = employee uses >>>> for communication (EMail, VoiP, IM) would be unconditionally = illegal. >>>=20 >>> Really? >>=20 >> No kidding! >>=20 >>=20 >>>=20 >>> That is not consistent with comments >>> I've seen concerning German law. >>=20 >> There is a significant amount of mis-information floating the = internet. >> And a mindboggling large number of lawyers are making wild guesses, = rather >> that doing research. >>=20 >> The decisions of the german federal constitional court (GFCC) have = been >> quite consistent over the past decade about what with respect to >> encroaching on the general right of personality, informational >> self-determination, freedom of conduct and created a "fundamental = right >> to the guarantee of the integrity and confidentiality of information >> technology systems". The court has set the minimum requirements that >> are prerequisite to such encroachment, such as the prerequisite of a >> clear formal statute law, which needs to be limited to situation = where >> real facts create probable cause. >>=20 >> The original GFCC decision in german language is quite comprehensible >> (to me, at least), while I'm having some difficulties understanding >> the english translation (and the english translation is shorter!?). >>=20 >> BVerfG-Entscheidung "1 BvR 370/07 vom 27.2.2008" Randnummer 196- >> http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007.html#abs196 >>=20 >> english translation of "1 BvR 370/07 vom 27.2.2008" >> = http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007en.html#abs130 >>=20 >>=20 >>> To be *unconditionally* illegal, would >>> preclude almost any rationally required >>> maintenance or threat mitigation. >>=20 >> It is possible to perform maintenance and threat mitigation entirely >> without "monitoring" systems. >>=20 >> A mere threat is insufficient for monitoring, if that involves = collecting >> PII data, i.e. data from which a persons conduct can be infered. >>=20 >>=20 >>>=20 >>> It is fair to observe that recent German >>> Constitutional Court decisions impose >>> constraints, but they certainly are >>> not "unconditional." >>=20 >> One of the prerequisite is a clear formal statute law, >> which currently does not exist for the purposes "sacm" is about. >>=20 >> quoting from the above GFCC decision: >>=20 >> 2. The fundamental right to the guarantee of the confidentiality = and >> integrity of information technology systems is not unrestricted. >> Encroachments may be justified both for preventive purposes, and = for >> criminal prosecution. The individual must only accept such = restrictions >> of his or her right which are based on a statutory foundation that >> is constitutional. >>=20 >>=20 >> This currently makes collecting data about peoples conduct = "unconditionally" >> illegal for most practical purposes (exempting from prosecution only >> individual occasions of justified self-defence against an imminent >> vicious attack based on real facts that create probable cause). >>=20 >> This applies to all surveillance that impairs persons "freedom of = conduct". >> The majority of past decisions of specific events was about = surveillance >> with a camera, but the GFCC decision makes it crystal clear that >> this applies to *any* kind of surveillance. Different to monitoring = of >> computer systems, there is statutory law for camera surveillance, >> that allows optical surveillance under certain conditions >> (Art. 6b BDSG "BundesDatenSchutzGesetz). >>=20 >> The lack of a formal statutory foundation makes surveillance illegal >> and entitles subjects to "cease and desist" rulings and sometimes >> damages. >>=20 >> In one more recent (and constitutionally correct) rulings, an = employer >> had put up a camera that had in view not only the entrance door, but >> also two workplaces. The employees protested against this camera, >> but the employer would not "fix" it, so at least one employee sued, >> The court confirmed that this camera surveillance at the workplace >> was illegal due to its chilling effect alone, and since it had been >> installed for a whole year, the employee was arwarded 4 month of = income >> as damages (for the chilling effect). >>=20 >> Another recent decision was about evidence from a covert video >> surveillance showing an employee taking a package of cigarettes >> on two occasions, where the German Federal Labour Court >> (the supreme court for labor related issues) remanded the decision >> to the trial court because it had failed to establish whether the >> covert video surveillance really met all constitutional prerequisites >> otherwise the video surveillance would have been illegal and not >> be admissible as evidence in court. >> (German decision: http://lexetius.com/2012,2351) >>=20 >> The German Federal Constitional Court neutered numerous laws during = the >> last decade due to lack of clarity and/or overbroad encroachment of >> the personal right of self-determination and the right to = confidentiality >> of telecommunications. >>=20 >> See also the GFCC decision about the scanning of license plates >> (the decision 1 BvR 2074/05 vom 11.3.2008 in german) >> http://www.bverfg.de/entscheidungen/rs20080311_1bvr2-07405.html >>=20 >> where it confirmed that data collection requires formal statue law, >> and that the law in question wasn't limited to probable cause and >> therefore unconstitutional. >>=20 >>=20 >> The only currently existing formal statue law in Germany, that could = be >> used in some limited fashion for "Monitoring" is Art.100 TKG, >> http://www.gesetze-im-internet.de/tkg_2004/__100.html >> but that statue is clearly limited in purpose, it will not allow that = data >> to be used for automatic surveillance of "employee conduct" with = respect >> to "company-defined policies". Employers try hard to avoid TKG for = their >> networks (for which they will have to formally register), but that = also >> means that they do not have a formal statutory law for performing any >> kind of surveillance/monitoring as described in Art. 100 TKG for = systems >> that are used by employees for telecommunications and a significant = part >> of their daily activies. >>=20 >>=20 >> -Martin >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >>=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --Apple-Mail=_E88926A6-F667-4A75-8C94-12A608F7AC31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Kent_Landfield@McAfee.com>= ; wrote:
Kent Landfield

McAfee | An = Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: 
From: = Martin Rex <mrex@sap.com>
Reply-To: "mrex@sap.com" <mrex@sap.com>
Date: Monday, August 6, 2012 11:32 = AM
To: "tony@yaanatech.com" <tony@yaanatech.com>
Cc: "mrex@sap.com" <mrex@sap.com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Legal aspects of = System monitoring

Tony Rutkowski wrote:
=
Martin Rex wrote:

In Germany, an employer monitoring a = company-owned PC that an employee uses
for communication = (EMail, VoiP, IM) would be unconditionally = illegal.

= Really?

No = kidding!



That is not consistent with = comments
I've seen concerning German = law.

There is a significant amount = of mis-information floating the internet.
And a mindboggling = large number of lawyers are making wild guesses, rather
that = doing research.

The decisions of the german = federal constitional court (GFCC) have been
quite consistent = over the past decade about what with respect to
encroaching on = the general right of personality, = informational
self-determination, freedom of conduct and = created a "fundamental right
to the guarantee of the integrity = and confidentiality of information
technology = systems".  The court has set the minimum requirements = that
are prerequisite to such encroachment, such as the = prerequisite of a
clear formal statute law, which needs to be = limited to situation where
real facts create probable = cause.

The original GFCC decision in german = language is quite comprehensible
(to me, at least), while I'm = having some difficulties understanding
the english translation = (and the english translation is = shorter!?).

BVerfG-Entscheidung "1 BvR 370/07 = vom 27.2.2008" Randnummer 196-

english translation of "1 BvR 370/07 vom = 27.2.2008"


=
To be *unconditionally* illegal, would
preclude = almost any rationally required
maintenance or threat = mitigation.

It is possible to = perform maintenance and threat mitigation entirely
without = "monitoring" systems.

A mere threat is = insufficient for monitoring, if that involves collecting
PII = data, i.e. data from which a persons conduct can be = infered.



It is fair to observe that recent = German
Constitutional Court decisions impose
= constraints, but they certainly are
not = "unconditional."

One of the = prerequisite is a clear formal statute law,
which currently = does not exist for the purposes "sacm" is = about.

quoting from the above GFCC = decision:

  2. The fundamental right = to the guarantee of the confidentiality = and
  integrity of information technology systems is = not unrestricted.
  Encroachments may be justified = both for preventive purposes, and for
  criminal = prosecution.  The individual must only accept such = restrictions
  of his or her right which are based = on a statutory foundation that
  is constitutional. =


This currently makes collecting = data about peoples conduct "unconditionally"
illegal for most = practical purposes (exempting from prosecution only
individual = occasions of justified self-defence against an = imminent
vicious attack based on real facts that create = probable cause).

This applies to all = surveillance that impairs persons "freedom of conduct".
The = majority of past decisions of specific events was about = surveillance
with a camera, but the GFCC decision makes it = crystal clear that
this applies to *any* kind of = surveillance.  Different to monitoring of
computer = systems, there is statutory law for camera surveillance,
that = allows optical surveillance under certain conditions
(Art. 6b = BDSG "BundesDatenSchutzGesetz).

The lack of a = formal statutory foundation makes surveillance illegal
and = entitles subjects to "cease and desist" rulings and = sometimes
damages.

In one more recent = (and constitutionally correct) rulings, an employer
had put up = a camera that had in view not only the entrance door, but
also = two workplaces.  The employees protested against this = camera,
but the employer would not "fix" it, so at least one = employee sued,
The court confirmed that this camera = surveillance at the workplace
was illegal due to its chilling = effect alone, and since it had been
installed for a whole = year, the employee was arwarded 4 month of income
as damages = (for the chilling effect).

Another recent = decision was about evidence from a covert video
surveillance = showing an employee taking a package of cigarettes
on two = occasions, where the German Federal Labour Court
(the supreme = court for labor related issues) remanded the decision
to the = trial court because it had failed to establish whether = the
covert video surveillance really met all constitutional = prerequisites
otherwise the video surveillance would have been = illegal and not
be admissible as evidence in = court.
(German decision: http://lexetius.com/2012,2351)<= /div>

The German Federal Constitional Court neutered = numerous laws during the
last decade due to lack of clarity = and/or overbroad encroachment of
the personal right of = self-determination and the right to confidentiality
of = telecommunications.

See also the GFCC decision = about the scanning of license plates
(the decision 1 BvR = 2074/05 vom 11.3.2008 in german)

where it confirmed that data collection requires = formal statue law,
and that the law in question wasn't limited = to probable cause and
therefore = unconstitutional.


The only = currently existing formal statue law in Germany, that could = be
used in some limited fashion for "Monitoring" is Art.100 = TKG,
but that statue = is clearly limited in purpose, it will not allow that data
to = be used for automatic surveillance of "employee conduct" with = respect
to "company-defined policies".  Employers = try hard to avoid TKG for their
networks (for which they will = have to formally register), but that also
means that they do = not have a formal statutory law for performing any
kind of = surveillance/monitoring as described in Art. 100 TKG for = systems
that are used by employees for telecommunications and = a significant part
of their daily = activies.


-Martin
______= _________________________________________
sacm mailing = list

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

= --Apple-Mail=_E88926A6-F667-4A75-8C94-12A608F7AC31-- From mrex@sap.com Mon Aug 6 10:21: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 923D911E809A for ; Mon, 6 Aug 2012 10:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.15 X-Spam-Level: X-Spam-Status: No, score=-10.15 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16EX9W482dCl for ; Mon, 6 Aug 2012 10:21:13 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id BCA9621F84F9 for ; Mon, 6 Aug 2012 10:21:12 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q76HL5jC012238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Aug 2012 19:21:10 +0200 (MEST) In-Reply-To: To: Kent_Landfield@McAfee.com Date: Mon, 6 Aug 2012 19:21:05 +0200 (CEST) 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: <20120806172105.958D21A126@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: mrex@sap.com, sacm@ietf.org, tony@yaanatech.com 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: Mon, 06 Aug 2012 17:21:13 -0000 Kent_Landfield@McAfee.com wrote: > > None of the efforts we are talking about for SACM are targeted toward > PII or individuals. They are targeted at the configuration of the > platforms deployed in the enterprise to assure they comply with the > site's security policy. PII is not collected. For many "office PCs" and even more so "laptops", the user using this device is implied, and a lot of actions of the devices are the result of user conduct. So monitoring (collecting, processing&storing) the behaviour of such devices constitutes the collection of PII data. (And many monitoring activity actually collects the name of the user running a process or opening a network connection along with it). "comply with a site's security policy" is a deceiving way to describe constant electronic surveillance to compare employee conduct with a company policy. > > This is not monitoring of individual or employee actions. As soon as an employees action could be infered from the data that is monitored, a formal statute law is required in Germany. Whether the collected data is used in that fashion or not, does not matter at all. Monitoring important central servers, which are used only for a short time or very limited purposes, would probably be OK. Monitoring end user systems, which are being used for a large part of the working day, or for telecommunication, will usually be illegal. 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. -Martin From michael.hammer@yaanatech.com Mon Aug 6 10:39: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 8F04221E8039 for ; Mon, 6 Aug 2012 10:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+VkcIcN+nxc for ; Mon, 6 Aug 2012 10:39:02 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 0743221F84A2 for ; Mon, 6 Aug 2012 10:39:02 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 6 Aug 2012 10:39:00 -0700 From: Michael Hammer To: "mrex@sap.com" , "Kent_Landfield@McAfee.com" Thread-Topic: [sacm] Legal aspects of System monitoring Thread-Index: AQHNcebv9wpWqLOXkkW1HGuGxo9Hw5dKJ8AAgANL5YCAAAL0gIAACqqA//+OHDA= Date: Mon, 6 Aug 2012 17:38:53 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB30B9105DB@EX2K10MB1.corp.yaanatech.com> References: <20120806172105.958D21A126@ld9781.wdf.sap.corp> In-Reply-To: <20120806172105.958D21A126@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.18] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_00D3_01CD73D8.CD0C2DB0" MIME-Version: 1.0 Cc: "sacm@ietf.org" , Tony Rutkowski Subject: Re: [sacm] Legal aspects of System 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: Mon, 06 Aug 2012 17:39:02 -0000 ------=_NextPart_000_00D3_01CD73D8.CD0C2DB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Martin, If what you say is true, then Germany can probably kiss any Cloud operation goodbye to some other country, since by your definitions all Clouds would be operating illegally. You cannot ask an implementation to ensure privacy and security, and at the same time make it illegal to use the very mechanisms needed for that assurance. Mike -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Martin Rex Sent: Monday, August 06, 2012 1:21 PM To: Kent_Landfield@McAfee.com Cc: mrex@sap.com; sacm@ietf.org; Tony Rutkowski Subject: Re: [sacm] Legal aspects of System monitoring Kent_Landfield@McAfee.com wrote: > > None of the efforts we are talking about for SACM are targeted toward > PII or individuals. They are targeted at the configuration of the > platforms deployed in the enterprise to assure they comply with the > site's security policy. PII is not collected. For many "office PCs" and even more so "laptops", the user using this device is implied, and a lot of actions of the devices are the result of user conduct. So monitoring (collecting, processing&storing) the behaviour of such devices constitutes the collection of PII data. (And many monitoring activity actually collects the name of the user running a process or opening a network connection along with it). "comply with a site's security policy" is a deceiving way to describe constant electronic surveillance to compare employee conduct with a company policy. > > This is not monitoring of individual or employee actions. As soon as an employees action could be infered from the data that is monitored, a formal statute law is required in Germany. Whether the collected data is used in that fashion or not, does not matter at all. Monitoring important central servers, which are used only for a short time or very limited purposes, would probably be OK. Monitoring end user systems, which are being used for a large part of the working day, or for telecommunication, will usually be illegal. 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. -Martin _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_000_00D3_01CD73D8.CD0C2DB0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgw NjE3Mzg0NVowIwYJKoZIhvcNAQkEMRYEFDEaPlZU/RUUAhiDvOlZhD9RDya5MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGALZ+HyjwsB9kDqciHqnmZDyDQ9UK884/r9jHbZat7QZoH Ah5BIc8Zz1ldCZIH6QeGqZt5Fo2lHwDzhP8OYSFPEwRHMbiHjKPASPOXsouGACiK9WekzrLf7l2G wAWmEWYcS6Gxp6PIv7j30ZwVglYRENJHMCLLfTmZjkUu0TCGRZgAAAAAAAA= ------=_NextPart_000_00D3_01CD73D8.CD0C2DB0-- From mrex@sap.com Mon Aug 6 10:47:00 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4A221F8514 for ; Mon, 6 Aug 2012 10:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hy+8Piv3axDR for ; Mon, 6 Aug 2012 10:46:58 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 96D1021F8518 for ; Mon, 6 Aug 2012 10:46:58 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q76HksEr007194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Aug 2012 19:46:55 +0200 (MEST) In-Reply-To: <00C069FD01E0324C9FFCADF539701DB30B9105DB@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer Date: Mon, 6 Aug 2012 19:46:54 +0200 (CEST) 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: <20120806174654.BF8751A126@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Tony Rutkowski , "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: Mon, 06 Aug 2012 17:47:00 -0000 Michael Hammer wrote: > > If what you say is true, It is. > > then Germany can probably kiss any Cloud operation goodbye to some > other country, since by your definitions all Clouds would be > operating illegally. There are a number of aspects about Cloud services which are currently operating in the legal void. When the Facebook mess becomes sorted out, they'll realize that they've been doing many illegal things all those years. > > You cannot ask an implementation to ensure privacy and security, > and at the same time make it illegal to use the very mechanisms > needed for that assurance. As I've mentioned, there is the narrowly tailored exemption of Art. 100 TKG http://www.gesetze-im-internet.de/tkg_2004/__100.html but this clearly limits what aspects of a security policy could be enforced with it. But do not underestimate the "paperwork" associated with each individual investigation authorized under the exemption of Art. 100 TKG. -Martin From gunnar.engelbach@threatguard.com Mon Aug 6 10:58: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 C06A211E80A5 for ; Mon, 6 Aug 2012 10:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ECPKPfIzUnp for ; Mon, 6 Aug 2012 10:58:08 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1601811E80A4 for ; Mon, 6 Aug 2012 10:58:08 -0700 (PDT) Received: (qmail 17024 invoked from network); 6 Aug 2012 12:04:51 -0700 Received: from h69-130-58-233.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.227?) (69.130.58.233) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 6 Aug 2012 12:04:51 -0700 Message-ID: <502005AF.2040901@ThreatGuard.com> Date: Mon, 06 Aug 2012 13:58:07 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mrex@sap.com References: <20120806174654.BF8751A126@ld9781.wdf.sap.corp> In-Reply-To: <20120806174654.BF8751A126@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Hammer , "Kent_Landfield@McAfee.com" , "sacm@ietf.org" , Tony Rutkowski Subject: Re: [sacm] Legal aspects of System 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: Mon, 06 Aug 2012 17:58:08 -0000 As work progresses it's worth keeping this in mind to see if these differences can be addressed -- but not if it means compromising the ability for everywhere else to effectively implement and monitor system security. The consequence would be that Germany will be increasingly vulnerable relative to elsewhere, and that's their decision to make. On 8/6/2012 1:46 PM, Martin Rex wrote: > Michael Hammer wrote: >> >> If what you say is true, > > It is. > > >> >> then Germany can probably kiss any Cloud operation goodbye to some >> other country, since by your definitions all Clouds would be >> operating illegally. > > There are a number of aspects about Cloud services which are currently > operating in the legal void. When the Facebook mess becomes sorted out, > they'll realize that they've been doing many illegal things all those > years. > > >> >> You cannot ask an implementation to ensure privacy and security, >> and at the same time make it illegal to use the very mechanisms >> needed for that assurance. > > As I've mentioned, there is the narrowly tailored exemption of Art. 100 TKG > http://www.gesetze-im-internet.de/tkg_2004/__100.html > but this clearly limits what aspects of a security policy could be > enforced with it. But do not underestimate the "paperwork" associated > with each individual investigation authorized under the exemption > of Art. 100 TKG. > > > -Martin > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From tony@yaanatech.com Mon Aug 6 10:58: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 B2A1121F859B for ; Mon, 6 Aug 2012 10:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xITzq-My60lt for ; Mon, 6 Aug 2012 10:58:53 -0700 (PDT) Received: from extmail1.prd.yaanatech.com (extmail1.prd.yaanatech.com [205.140.198.37]) by ietfa.amsl.com (Postfix) with ESMTP id 25C5921F84F3 for ; Mon, 6 Aug 2012 10:58:53 -0700 (PDT) Received: from [192.168.0.4] (pool-173-72-150-118.clppva.fios.verizon.net [173.72.150.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extmail1.prd.yaanatech.com (Postfix) with ESMTP id 7540958081; Mon, 6 Aug 2012 17:58:52 +0000 (UTC) Message-ID: <502005DB.80605@yaanatech.com> Date: Mon, 06 Aug 2012 13:58:51 -0400 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: mrex@sap.com References: <20120806172105.958D21A126@ld9781.wdf.sap.corp> In-Reply-To: <20120806172105.958D21A126@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: tony@yaanatech.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 17:58:53 -0000 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. --tony 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. From mrex@sap.com Mon Aug 6 11:52: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 7A9E911E80C5 for ; Mon, 6 Aug 2012 11:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.854 X-Spam-Level: X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFZmqR9GFT0y for ; Mon, 6 Aug 2012 11:52:40 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 21EFA11E808A for ; Mon, 6 Aug 2012 11:52:39 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q76IqXB7018486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Aug 2012 20:52:38 +0200 (MEST) In-Reply-To: <502005DB.80605@yaanatech.com> To: tony@yaanatech.com Date: Mon, 6 Aug 2012 20:52:32 +0200 (CEST) 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: <20120806185232.ED6741A126@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out 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: Mon, 06 Aug 2012 18:52:41 -0000 Tony Rutkowski wrote: > Maybe this is getting off-topic, but could > you provide some citations to "German law." I already did: http://www.ietf.org/mail-archive/web/sacm/current/msg00446.html Maybe you misunderstand how the constitutional protections work. The German Federal Constitutional Court ruled: The individual must only accept such restrictions of his or her right which are based on a statutory foundation that is constitutional. In order for TelCos to be allowed to monitor their networks, they desperately need Art. 100 TKG as the "statutory foundation". If an employer wants to monitor end user PCs that are used by employees for the greater part of their working and for telecommunications, then a similar "statutory foundation that is constitutional" will be required. There currently exist *no* such statutory foundation that employers might use other than Art. 100 TKG, and without it, constant surveillance/monitoring of end user systems will be illegal, and individuals are entitled to "cease and desist rulings" and potentially awarding of damages. That is what "the individual must only accept such restrictions" is about. And this decision and ruling of the GFCC is legally binding for the legislator, courts&judges and the executive branch. That's what Art. 31 (1) BVerfGG is about: http://www.gesetze-im-internet.de/bverfgg/__31.html > > 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. Ask them for the specific "statutory foundation" (name and article of law) that would authorize the collection of such data. The GFCC has established this requirement as a prerequisite. If lawyers or judges "forget" to justify their decision with a suitable "statutory foundation", then their decision will be shredded on appeal to the GFCC and remanded, like this one here: http://www.bverfg.de/entscheidungen/rk20090811_2bvr094108.html#abs17 where GFCC sends a pretty clear message about the severe failure of the trial court and appelate court to identify a "statutory foundation" that would allow them to issue a speeding ticket based on analysis of an unconditional video surveillance of traffic. -Martin From tony@yaanatech.com Mon Aug 6 12:20:29 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBCE11E80FC for ; Mon, 6 Aug 2012 12:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkSYbbrjVYGf for ; Mon, 6 Aug 2012 12:20:28 -0700 (PDT) Received: from extmail1.prd.yaanatech.com (extmail1.prd.yaanatech.com [205.140.198.37]) by ietfa.amsl.com (Postfix) with ESMTP id A441311E80F8 for ; Mon, 6 Aug 2012 12:20:28 -0700 (PDT) Received: from [192.168.0.4] (pool-173-72-150-118.clppva.fios.verizon.net [173.72.150.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extmail1.prd.yaanatech.com (Postfix) with ESMTP id 1104558081; Mon, 6 Aug 2012 19:20:27 +0000 (UTC) Message-ID: <502018FA.20603@yaanatech.com> Date: Mon, 06 Aug 2012 15:20:26 -0400 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: mrex@sap.com References: <20120806185232.ED6741A126@ld9781.wdf.sap.corp> In-Reply-To: <20120806185232.ED6741A126@ld9781.wdf.sap.corp> Content-Type: multipart/alternative; boundary="------------090008010703030407030907" Cc: 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: tony@yaanatech.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 19:20:29 -0000 This is a multi-part message in MIME format. --------------090008010703030407030907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Martin, This is helpful for doing followup research and analysis. Yourconstruction is arguably a bit on the extreme side. However, there are 192 nations out there; and many of them have bizarre requirements and constructs that often have nothing to do with reality. The IETF generally focuses on protocols, structured information, and platforms, and lets the implementers deal with the local environment. In the ITU-T, the German BNetzA routinely inserts the same phrase in almost every standard that is developed, and everyone moves on. Some specific national and regional regulation and legislation may require implementation of mechanisms to protect personally identifiable information. --tony --------------090008010703030407030907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Martin,

This is helpful for doing followup research
and analysis.  Your construction is arguably
a bit on the extreme side.

However, there are 192 nations out there;
and many of them have bizarre requirements
and constructs that often have nothing to
do with reality.  The IETF generally focuses
on protocols, structured information, and
platforms, and lets the implementers deal
with the local environment.

In the ITU-T, the German BNetzA routinely
inserts the same phrase in almost every standard
that is developed, and everyone moves on.
Some specific national and regional regulation and legislation may require
implementation of mechanisms to protect personally identifiable information.
--tony
--------------090008010703030407030907-- From athiasjerome@gmail.com Mon Aug 6 14:34: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 22A4211E80F4 for ; Mon, 6 Aug 2012 14:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cN7Wi8K5hVHM for ; Mon, 6 Aug 2012 14:34:34 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 39E2511E80F2 for ; Mon, 6 Aug 2012 14:34:34 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2099693wgb.13 for ; Mon, 06 Aug 2012 14:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=entSNOFMA06Nkp/B4hEIPj4PjmFEd+i7lUF23LTTXF8=; b=mKbJOh4r8mUYRh3SgKxMc4I4IjR9Ex7Y8YMWviLRCZblr3bOGB4Zdg0mdtReJhGNvx s/v7Hr7CHLOFh3qffSWM00bscESXjef85jjlY/7wP4YM2kezrO15kSCUyOJtf7Gsf6my 6e4CjdyxGExMOWbnumQJLytLPKzBTkNJUp/z+MIdSS+0qMcdj3//Y1pw7Wxnzswp6wNn Vcob5wXmI85fJlLa37331emXd5zo6xW5yPOVLjTcbzohUuRoVWxhOGelhqQLmA8QzKtk k2tL5mm7kyqVfB5Bwwku/+yEf12GoXe95Y0HObcbgPrDz8k8dKp/u95g1YZtRmazq0eZ 4rMg== Received: by 10.180.97.135 with SMTP id ea7mr21624178wib.11.1344288873150; Mon, 06 Aug 2012 14:34:33 -0700 (PDT) Received: from [192.168.123.4] (adsl196-173-221-217-196.adsl196-15.iam.net.ma. [196.217.221.173]) by mx.google.com with ESMTPS id l5sm26015323wix.5.2012.08.06.14.34.26 (version=SSLv3 cipher=OTHER); Mon, 06 Aug 2012 14:34:32 -0700 (PDT) Message-ID: <50203859.4060707@gmail.com> Date: Mon, 06 Aug 2012 23:34:17 +0200 From: Jerome Athias User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: sacm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sacm] Interop testing X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 06 Aug 2012 21:34:35 -0000 Hi, I am greatly interested by interop design, implementation and testing. If any new mailing-list, wiki or efforts are needed or initiated, I would definitely be in. Thanks and regards /JA Le 06/08/2012 15:36, Adam Montville a écrit : > > On 8/3/12 2:58 PM, "Stephen Hanna" wrote: > >> I'm a big fan of interop testing. Without it, things just don't interop. >> And when interop testing is combined into a certification program, >> customers can find products that actually work together. If they >> then require certifications in RFPs, vendors have an incentive to >> make their products interop. There are lots of complexities and >> pitfalls that we can talk about but... >> >> The IETF does not provide interop testing for its standards so I don't >> think we could/should include that in our charter. Such testing is often >> provided by outside labs or informal groupings (plugfests) but not by the >> IETF. So while it's OK to talk a bit about interop testing on IETF lists, >> such testing is not an IETF activity. At least, that's my understanding. >> As such, I don't think we should talk about it in the charter. > Agreed. > >> There will be plenty of time to talk about interop testing and >> certification >> and related issues AFTER the charter has been figured out and approved. >> >> If other IETF experts want to weigh in on this, feel free. Paul Hoffman >> (for example) has decades of experience with interop testing for IETF >> specs. > As interoperability is critical to this effort, I second this call for > additional advice with respect to such testing. > >> Thanks, >> >> Steve >> >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >>> Adam Montville >>> Sent: Friday, August 03, 2012 4:06 PM >>> To: Waltermire, David A.; sacm@ietf.org >>> Subject: Re: [sacm] Interop testing >>> >>> >>> >>> From: , "David A." >>> > >>> Date: Friday, August 3, 2012 12:30 PM >>> To: "sacm@ietf.org" >>> > >>> Subject: [sacm] Interop testing >>> >>> Another thing we might want to address in the charter is some concept >>> of interop testing as part of the I/D development process. This has >>> been discussed within the Security Automation community historically, >>> but was not mentioned during the side meeting. >>> >>> This seems like a good idea. >>> >>> >>> Dave >>> >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From amontville@tripwire.com Mon Aug 6 18:08:10 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D98421F8565 for ; Mon, 6 Aug 2012 18:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.809 X-Spam-Level: X-Spam-Status: No, score=-3.809 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CB78gceloPNO for ; Mon, 6 Aug 2012 18:08:09 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id CD73F21F855D for ; Mon, 6 Aug 2012 18:08:01 -0700 (PDT) Received: from mail7-db3-R.bigfish.com (10.3.81.225) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 7 Aug 2012 01:08:00 +0000 Received: from mail7-db3 (localhost [127.0.0.1]) by mail7-db3-R.bigfish.com (Postfix) with ESMTP id 3ECF8E0180 for ; Tue, 7 Aug 2012 01:08:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzzz1202hzzz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail7-db3 (localhost.localdomain [127.0.0.1]) by mail7-db3 (MessageSwitch) id 1344301678681562_8392; Tue, 7 Aug 2012 01:07:58 +0000 (UTC) Received: from DB3EHSMHS013.bigfish.com (unknown [10.3.81.243]) by mail7-db3.bigfish.com (Postfix) with ESMTP id 9A7F240109 for ; Tue, 7 Aug 2012 01:07:58 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by DB3EHSMHS013.bigfish.com (10.3.87.113) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 7 Aug 2012 01:07:58 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Aug 2012 18:09:58 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Mon, 6 Aug 2012 18:07:55 -0700 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: Using the Frame of Reference Thread-Index: AQHNdDkTRwSx007YrEGOEBCjcgvwtw== Date: Tue, 7 Aug 2012 01:07:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <7AD56DF69A86884EAFCDC3D7EF873CED@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: [sacm] Using the Frame of Reference X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 07 Aug 2012 01:08:10 -0000 All: Here's how I would envision using the frame of reference using Security Configuration Management (SCM) as an example. SCM is really five controls often assisted by technical toolsets (depending on who you ask, so this is just one perspective): 1. Configuration Assessment (password length is set to x) 2. Patch and Vulnerability Assessment (software package x is at version a.b.c) 3. Configuration Remediation (set password length to x) 4. Patch Remediation (bring software package x to at least version a.b.c) 5. Rate of Change (how are the files, registry entries, and other Settings changing over time Because asset management is critical to the success of these controls, I assert that we should revisit what we have today in the way of models and where we need improvement (gaps or less than ideal coverage). Appropriate asset models are required for each of SCM's constituent parts, as listed below. We might assert the following information model relationships: o Security Configuration Management is composed of o Configuration Assessment, which requires a/an - Asset Model (information/characterization) - Observable Model, - Assessment Model (checklists), - Scoring/Risk Model; o Patch and Vulnerability Assessment, which requires a/an - Asset Model, - Observable Model, - Assessment Model, - Vulnerability Model, - Scoring/Risk Model; o Configuration Remediation, which requires a/an - Asset Model, - Observable Model, - Remediation Model; o Patch Remediation, which requires a/an - Asset Model, - Observable Model, - Remediation Model. Note that some of the Supporting Concepts would be helpful here as well. Tasking/Workflow, is one example (consider assessing an endpoint, remediating, then reassessing). The Observable Model should be one that describes that which can be technically observed on an endpoint and which is able to provide contextual information with respect to that observable (either directly or through use of another model). For example, if I'm looking at a the Account Lockout Duration setting for a Windows Server 2008 R2 machine Group Policy Object, then we should provide the means for content producers to include acceptable values for that configuration item, such that implementers using these specifications can provide guidance to their users with respect to that particular setting. Something that seems lacking here is tying back to control frameworks (control in the ISO 27000/NIST 800-53 sense of the term). In the case of SCM, we could use any number of the available control frameworks to guide us. For example, the third SANS Top 20 Critical Control, "Secure Configurations for Hardware and Software on Laptops, Workstations, and Servers" might require one or more SCM constituents as defined above. I'm particularly interested in this because it has been shown that, to date, security automation efforts have been rather shotgun in their approach and have not necessarily done a good job ensuring that requirements derived from top-level scenarios are being satisfied. Also, knowing the exact needs of these controls can help us focus on what that which must be done, rather than upon that which could be done. Regards, Adam From amontville@tripwire.com Mon Aug 6 18:17: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 6A7F221F86CB for ; Mon, 6 Aug 2012 18:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5kQ0KK7NvWA for ; Mon, 6 Aug 2012 18:17:31 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id C1C2021F86CA for ; Mon, 6 Aug 2012 18:17:31 -0700 (PDT) Received: from mail62-co1-R.bigfish.com (10.243.78.238) by CO1EHSOBE016.bigfish.com (10.243.66.79) with Microsoft SMTP Server id 14.1.225.23; Tue, 7 Aug 2012 01:17:31 +0000 Received: from mail62-co1 (localhost [127.0.0.1]) by mail62-co1-R.bigfish.com (Postfix) with ESMTP id 173B31002E0; Tue, 7 Aug 2012 01:17:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(z3d0Izbb2dI98dI9371I1452I1432Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail62-co1 (localhost.localdomain [127.0.0.1]) by mail62-co1 (MessageSwitch) id 1344302248888149_29915; Tue, 7 Aug 2012 01:17:28 +0000 (UTC) Received: from CO1EHSMHS024.bigfish.com (unknown [10.243.78.232]) by mail62-co1.bigfish.com (Postfix) with ESMTP id CCD08C40019; Tue, 7 Aug 2012 01:17:28 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by CO1EHSMHS024.bigfish.com (10.243.66.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 7 Aug 2012 01:17:28 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Aug 2012 18:19:30 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Mon, 6 Aug 2012 18:17:27 -0700 From: Adam Montville To: "Kent_Landfield@McAfee.com" , "lnunez@c3isecurity.com" Thread-Topic: [sacm] Weekly Meetings for Charter and Use Case Discussion Thread-Index: AQHNcz71G4HXk6Xx6kKyTzC8edNDKpdL9NaQgADVQACAAI+GgIAABGsA//+UxoCAAHZPAIAAJTUA Date: Tue, 7 Aug 2012 01:17:27 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <71B4B0A9735A0845AEBF3167637831E3@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Cc: "shanna@juniper.net" , "sacm@ietf.org" Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 07 Aug 2012 01:17:32 -0000 > > > >>From: kent_landfield >>> >>Date: Monday, August 6, 2012 8:24 AM >>To: "lnunez@c3isecurity.com" >>>, >> Adam Montville > >>Cc: "shanna@juniper.net" >>>, >> "sacm@ietf.org" >>> >>Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion >> >> >>Personally I'd rather do this on the list. I have no problem with calls >>but that reduces the transparency at a time we really need it. >> >>Kent Landfield >> >> >>McAfee | An Intel Company >>Direct: +1.972.963.7096 >>Mobile: +1.817.637.8026 >>Web: www.mcafee.com >> >> >>From: Luis Nunez > >>Date: Monday, August 6, 2012 10:08 AM >>To: Adam Montville >>> >>Cc: Stephen Hanna >, >>"'sacm@ietf.org'" >> > >>Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion >> >> >>I open for the proposed times. It may be good to have it on a Monday so >>that we can work on specifics during the week. >> >> >>-ln >> >> >>On Aug 6, 2012, at 9:35 AM, Adam Montville wrote: >> >> >>On 8/5/12 5:59 PM, "Stephen Hanna" >>> wrote: >>Great! All those times are fine with me. Any other opinions regarding doing this work exclusively on the list or augmenting the on-list communication with weekly calls until our use cases and/or draft charter are "done." I'd like to see this topic come to a close later this week, perhaps by end of day Thursday (Pacific time). From kathleen.moriarty@emc.com Mon Aug 6 19:21:45 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3EB021F86B1 for ; Mon, 6 Aug 2012 19:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYasHvakcsT1 for ; Mon, 6 Aug 2012 19:21:44 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id E425221F86B2 for ; Mon, 6 Aug 2012 19:21:43 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q772LaKT022295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2012 22:21:36 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 6 Aug 2012 22:21:20 -0400 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q772LKxp020338; Mon, 6 Aug 2012 22:21:20 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Mon, 6 Aug 2012 22:21:20 -0400 From: To: , , Date: Mon, 6 Aug 2012 22:21:18 -0400 Thread-Topic: [sacm] Weekly Meetings for Charter and Use Case Discussion Thread-Index: AQHNcz71G4HXk6Xx6kKyTzC8edNDKpdL9NaQgADVQACAAI+GgIAABGsA//+UxoCAAHZPAIAAJTUAgAARZWA= 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: shanna@juniper.net, sacm@ietf.org Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 07 Aug 2012 02:21:46 -0000 As Steve mentioned, calls could be used to accelerate the progress, so I th= ink that would be helpful. This won't be an option if a working group is f= ormed, but is possible now. I think we should take the opportunity to spee= d up progress and could provide minutes to the list for anyone who could no= t join and to provide transparency for those who join later. Thank you, Kathleen -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ada= m Montville Sent: Monday, August 06, 2012 9:17 PM To: Kent_Landfield@McAfee.com; lnunez@c3isecurity.com Cc: shanna@juniper.net; sacm@ietf.org Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion > > > >>From: kent_landfield >>> >>Date: Monday, August 6, 2012 8:24 AM >>To: "lnunez@c3isecurity.com" >>>, >> Adam Montville > >>Cc: "shanna@juniper.net" >>>, >> "sacm@ietf.org" >>> >>Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion >> >> >>Personally I'd rather do this on the list. I have no problem with calls >>but that reduces the transparency at a time we really need it. >> >>Kent Landfield >> >> >>McAfee | An Intel Company >>Direct: +1.972.963.7096 >>Mobile: +1.817.637.8026 >>Web: www.mcafee.com >> >> >>From: Luis Nunez > >>Date: Monday, August 6, 2012 10:08 AM >>To: Adam Montville >>> >>Cc: Stephen Hanna >, >>"'sacm@ietf.org'" >> > >>Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion >> >> >>I open for the proposed times. It may be good to have it on a Monday so >>that we can work on specifics during the week. >> >> >>-ln >> >> >>On Aug 6, 2012, at 9:35 AM, Adam Montville wrote: >> >> >>On 8/5/12 5:59 PM, "Stephen Hanna" >>> wrote: >>Great! All those times are fine with me. Any other opinions regarding doing this work exclusively on the list or augmenting the on-list communication with weekly calls until our use cases and/or draft charter are "done." I'd like to see this topic come to a close later this week, perhaps by end of day Thursday (Pacific time). _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From Kent_Landfield@mcafee.com Mon Aug 6 19:39:36 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E3721F865E for ; Mon, 6 Aug 2012 19:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNE8SgJy5und for ; Mon, 6 Aug 2012 19:39:35 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBE821F8625 for ; Mon, 6 Aug 2012 19:39:35 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 6d72_312c_38a99748_c57d_46ca_8fe8_38bdec4d5601; Mon, 06 Aug 2012 21:39:26 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Mon, 6 Aug 2012 21:39:24 -0500 From: To: , , Date: Mon, 6 Aug 2012 21:40:18 -0500 Thread-Topic: [sacm] Weekly Meetings for Charter and Use Case Discussion Thread-Index: Ac10RdrD6QSYwiVsTAu4t8Qym5p4Ng== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC45F82C3947Ckentlandfieldmcafeecom_" MIME-Version: 1.0 Cc: shanna@juniper.net, sacm@ietf.org Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 07 Aug 2012 02:39:36 -0000 --_000_CC45F82C3947Ckentlandfieldmcafeecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well that's what consensus is all about. Please include me on the calls if= they are set up. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Kathleen Moriarty > Date: Monday, August 6, 2012 10:21 PM To: Adam Montville = >, Kent Landfield >, Luis Nunez > Cc: "shanna@juniper.net" >, "sacm@ietf.org" > Subject: RE: [sacm] Weekly Meetings for Charter and Use Case Discussion As Steve mentioned, calls could be used to accelerate the progress, so I th= ink that would be helpful. This won't be an option if a working group is f= ormed, but is possible now. I think we should take the opportunity to spee= d up progress and could provide minutes to the list for anyone who could no= t join and to provide transparency for those who join later. Thank you, Kathleen -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Monday, August 06, 2012 9:17 PM To: Kent_Landfield@McAfee.com; lnunez@c3i= security.com Cc: shanna@juniper.net; sacm@ietf.org Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion From: kent_landfield > Date: Monday, August 6, 2012 8:24 AM To: "lnunez@c3isecurity.com" >, Adam Montville > Cc: "shanna@juniper.net" >, "sacm@ietf.org" > Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion Personally I'd rather do this on the list. I have no problem with calls but that reduces the transparency at a time we really need it. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Luis Nunez > Date: Monday, August 6, 2012 10:08 AM To: Adam Montville > Cc: Stephen Hanna >, "'sacm@ietf.org'" > Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion I open for the proposed times. It may be good to have it on a Monday so that we can work on specifics during the week. -ln On Aug 6, 2012, at 9:35 AM, Adam Montville wrote: On 8/5/12 5:59 PM, "Stephen Hanna" > = wrote: Great! All those times are fine with me. Any other opinions regarding doing this work exclusively on the list or augmenting the on-list communication with weekly calls until our use cases and/or draft charter are "done." I'd like to see this topic come to a close later this week, perhaps by end of day Thursday (Pacific time). _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_CC45F82C3947Ckentlandfieldmcafeecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Well= that's what consensus is all about.  Please include me on the calls i= f they are set up.

Kent Landfield

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

From: Kathleen Moriarty <kat= hleen.moriarty@emc.com>
Date: Monday, August 6, 2012 10:21 PM
T= o: Adam Montville <am= ontville@tripwire.com>, Kent Landfield <Kent_Landfield@McAfee.com>, Luis Nunez <lnunez@c3isecurity.com>
Cc: "shanna@juniper.net" <shan= na@juniper.net>, "sacm@ietf.org= " <sacm@ietf.org>
Subject: RE: [sacm] Weekly Meetings for Chart= er and Use Case Discussion

As Steve mentioned, calls could = be used to accelerate the progress, so I think that would be helpful. =  This won't be an option if a working group is formed, but is possible= now.  I think we should take the opportunity to speed up progres= s and could provide minutes to the list for anyone who could not join and t= o provide transparency for those who join later.

T= hank you,
Kathleen

-----Original Message= -----
From: sacm-bounces= @ietf.org [mailto:sacm-bounces= @ietf.org] On Behalf Of Adam Montville
Sent: Monday, August 0= 6, 2012 9:17 PM




Date: Monday, August 6, 2012 8:24 AM
To:= "lnunez@c3isecurity.com<<= a href=3D"mailto:lnunez@c3isecurity.com>">mailto:lnunez@c3isecurity.com&= gt;"
S= ubject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion


Personally I'd rather do this on the li= st. I have no problem with calls
but that reduces the transparenc= y at a time we really need it.

Kent Landfield


McAfee | An Intel Company
Dir= ect: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.m= cafee.com<http://www.mcafee.com/&= gt;


From: Luis Nunez <lnunez@c3isecurity.com<mailto:lnunez@c3isecurity.com>><= /div>
Date: Monday, August 6, 2012 10:08 AM
To: Adam Montvill= e
Subject: Re: [sacm] Weekly Meet= ings for Charter and Use Case Discussion


I open for the proposed times.  It may be good to have it o= n a Monday so
that we can work on specifics during the week.


-ln


=
On Aug 6, 2012, at 9:35 AM, Adam Montville wrote:

=

On 8/5/12 5:59 PM, "Stephen Hanna"
=
Great! All those times are fine with me.


Any other opinions regarding doing thi= s work exclusively on the list or
augmenting the on-list communic= ation with weekly calls until our use cases
and/or draft charter = are "done."  I'd like to see this topic come to a
close= later this week, perhaps by end of day Thursday (Pacific time).
=



_______________= ________________________________
sacm mailing list


--_000_CC45F82C3947Ckentlandfieldmcafeecom_-- From mrex@sap.com Mon Aug 6 20:42: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 8742321F8691 for ; Mon, 6 Aug 2012 20:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.852 X-Spam-Level: X-Spam-Status: No, score=-9.852 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRJitAJIF5Ha for ; Mon, 6 Aug 2012 20:42:39 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 52BCC21F8688 for ; Mon, 6 Aug 2012 20:42:39 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q773gbFu014986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Aug 2012 05:42:37 +0200 (MEST) In-Reply-To: <502018FA.20603@yaanatech.com> To: tony@yaanatech.com Date: Tue, 7 Aug 2012 05:42:36 +0200 (CEST) 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: <20120807034236.D32801A126@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out 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, 07 Aug 2012 03:42:40 -0000 Tony Rutkowski wrote: > > This is helpful for doing followup research > and analysis. Yourconstruction is arguably > a bit on the extreme side. Just to the contrary. There is stuff described in http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-01 which is clearly illegal for personal end-user systems (Office PC,Laptop,Tablet,SmartPhone) The shit hits the fan in Section 3.2 with these: o User/host behavior Possible desired outcomes to address: o Change in state is recorded and reported o User/system activity is recorded and reported o User/system access is terminated or altered and gets worse up to the extreme 3.5. UC5: Automated Forensics Investigation which is a complete no-go. > > However, there are 192 nations out there; The European Court of Human Rights showed to share many of the same concerns as the German Federal Constitutional Courts, and proved on at least two occasions I'm aware of to be be more sensitive/concerned than the GFCC. > > In the ITU-T, the German BNetzA routinely > inserts the same phrase in almost every standard > that is developed, and everyone moves on. > > Some specific national and regional regulation and legislation > may require implementation of mechanisms to protect personally > identifiable information. That statement is insufficient an misleading. The problem is not insufficient protection of the collected PII, the problem is the unbounded collection of PII with the complete lack of a probable cause prerequisite ("wholesale surveillance"). The "fix" to the previously mentioned unconstitutional covert video surveillance of traffic required to changes: (1) a technical change to the monitoring equipment so that instead of unconditionally recording all traffic, it would only perform video recordings (i.e. collect PII) for vehicles after detecting that they were over the speed limit (=probable cause) (2) The trial courts correctly identified a "statutory foundation" for justifying the evidence admissibility in Art 100h StPO http://www.gesetze-im-internet.de/stpo/__100h.html You would have to limit most in Section 3.2 and later to situations where facts create probable cause _before_ collecting and evaluating the data, and limit all collections upfront(!) to probable cause. (2) is not applicable to employers that want to monitor end-user equipment, it is clearly limited to law enforcement. And for 3.5, automated forensics for system in entirely unjustifiable for an end user system. There is a constitutional requirement for due process that includes an educated and case-specific decision involving at least one human being (exceptional emergency) or several humans (regular), real facts and and probable cause, and reliable accountability whether the human decision is within certain discretionary limits. Process-wise all those "security policies", when implemented in automated fashion, result in even more counter-productive and discrimitating action than the security theater that the TSA is performing on airtravel passengers, i.e. in "zero discretion" policies that are often dumb because they seriously inconvenience everyone all the time, without making anyone measurably safer. -Martin From anton.chuvakin@gmail.com Mon Aug 6 21:56:15 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DEE21F85F4 for ; Mon, 6 Aug 2012 21:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLtykk-qNWVZ for ; Mon, 6 Aug 2012 21:56:14 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF4F21F85A3 for ; Mon, 6 Aug 2012 21:56:14 -0700 (PDT) Received: by weyu54 with SMTP id u54so2788738wey.31 for ; Mon, 06 Aug 2012 21:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=b5MrWkWkXHqTxSbbs2N7cRy59anAXL5dG4TZyAmBrjU=; b=aPsAUWI1TI/SwlQ/epmqn7yBWSE+oHTa/TpaOmHQgGIKBeuQqG95aARdTQ9o/0Cp1v 6y0Dg9YHS1qh7xxnWd2KY/0qUQoSpHZeoE7PWqXMybGqQpSKK0MPUNVLRsJlv9s4/P0B MQ1Xri2HEoiBy6iGGApnMn2No/NrQ1z8m5dmAl8KhPTdFjyoz+Xao4psV9dROkmo0hyA 0cxisPBAJGL9ZvGdqceatX7gC8hl7Rq4KYFE8vJhh6fy+RUo5X38TiQJ4HAvOX1VeI4g ppETqwzfV8ihgFHOdfFtR2Md7zKRsYyx4jtbfSpddZY/nE9vBOHw6qGH4+gUyuQ7+vc2 IwMQ== Received: by 10.216.147.4 with SMTP id s4mr7239467wej.9.1344315373299; Mon, 06 Aug 2012 21:56:13 -0700 (PDT) MIME-Version: 1.0 Sender: anton.chuvakin@gmail.com Received: by 10.223.65.18 with HTTP; Mon, 6 Aug 2012 21:55:43 -0700 (PDT) In-Reply-To: <20120807034236.D32801A126@ld9781.wdf.sap.corp> References: <502018FA.20603@yaanatech.com> <20120807034236.D32801A126@ld9781.wdf.sap.corp> From: Anton Chuvakin Date: Mon, 6 Aug 2012 21:55:43 -0700 X-Google-Sender-Auth: Q4CSnnSXWNs1nJFQtt08mdiJPVc Message-ID: To: sacm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [sacm] Legal aspects of System 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, 07 Aug 2012 04:56:15 -0000 On Mon, Aug 6, 2012 at 8:42 PM, Martin Rex wrote: > You would have to limit most in Section 3.2 and later to situations > where facts create probable cause _before_ collecting and evaluating > the data, and limit all collections upfront(!) to probable cause. If you do that (reduce to 'probably cause') it won't really be 'monitoring', now will it? It would be 'investigation.' Monitoring is how you realize that you have a cause to investigate. P.S. This email thread is crazy :-) -- Dr. Anton Chuvakin Site: http://www.chuvakin.org Twitter: @anton_chuvakin Work: http://www.linkedin.com/in/chuvakin From mrex@sap.com Mon Aug 6 23:38: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 5723421F86C5 for ; Mon, 6 Aug 2012 23:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.144 X-Spam-Level: X-Spam-Status: No, score=-10.144 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oL0sLmKoEnM for ; Mon, 6 Aug 2012 23:38:55 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7146C21F86C7 for ; Mon, 6 Aug 2012 23:38:55 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q776cpr2000304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Aug 2012 08:38:51 +0200 (MEST) In-Reply-To: To: Anton Chuvakin Date: Tue, 7 Aug 2012 08:38:51 +0200 (CEST) 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: <20120807063851.7CF191A125@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 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, 07 Aug 2012 06:38:56 -0000 Anton Chuvakin wrote: > > Martin Rex wrote: >> >> You would have to limit most in Section 3.2 and later to situations >> where facts create probable cause _before_ collecting and evaluating >> the data, and limit all collections upfront(!) to probable cause. > > If you do that (reduce to 'probably cause') it won't really be > 'monitoring', now will it? It would be 'investigation.' > Monitoring is how you realize that you have a cause to investigate. Which is exactly what I wrote in my initial message in this thread: On 8/3/2012 10:14 PM, Martin Rex wrote: > In Germany, an employer monitoring a company-owned PC that an employee uses > for communication (EMail, VoiP, IM) would be unconditionally illegal. What puzzles me is that monitoring of end-user systems is not at least recognized as highly unethical for jurisdictions where it is not outright illegal. The US legal system seems seriously skewed on some aspects. While there seem to extremly strong "fruit from the forbidden tree" provisions in the US that may exclude illegally obtained evidence from prosecution even in cases of murder, the appear to be effectively zero privacy protections for employees at the workplace (or outside their homes or without curtains closed...). -Martin From shanna@juniper.net Tue Aug 7 02:21:27 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA2421F85EF for ; Tue, 7 Aug 2012 02:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.586 X-Spam-Level: X-Spam-Status: No, score=-106.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBbKV3Zb+1+d for ; Tue, 7 Aug 2012 02:21:26 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3DA21F8627 for ; Tue, 7 Aug 2012 02:21:21 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUCDeDx4NVaNVSE0/gDv2Z8hK42Jzt/Pe@postini.com; Tue, 07 Aug 2012 02:21:23 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 7 Aug 2012 02:17:26 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 7 Aug 2012 05:17:25 -0400 From: Stephen Hanna To: "kathleen.moriarty@emc.com" , "amontville@tripwire.com" , "Kent_Landfield@McAfee.com" , "lnunez@c3isecurity.com" Date: Tue, 7 Aug 2012 05:17:24 -0400 Thread-Topic: [sacm] Weekly Meetings for Charter and Use Case Discussion Thread-Index: AQHNcz71G4HXk6Xx6kKyTzC8edNDKpdL9NaQgADVQACAAI+GgIAABGsA//+UxoCAAHZPAIAAJTUAgAARZWCAAHSzMA== 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 07 Aug 2012 09:21:27 -0000 +1 > -----Original Message----- > From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] > Sent: Monday, August 06, 2012 10:21 PM > To: amontville@tripwire.com; Kent_Landfield@McAfee.com; > lnunez@c3isecurity.com > Cc: Stephen Hanna; sacm@ietf.org > Subject: RE: [sacm] Weekly Meetings for Charter and Use Case Discussion >=20 > As Steve mentioned, calls could be used to accelerate the progress, so > I think that would be helpful. This won't be an option if a working > group is formed, but is possible now. I think we should take the > opportunity to speed up progress and could provide minutes to the list > for anyone who could not join and to provide transparency for those who > join later. >=20 > Thank you, > Kathleen >=20 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Monday, August 06, 2012 9:17 PM > To: Kent_Landfield@McAfee.com; lnunez@c3isecurity.com > Cc: shanna@juniper.net; sacm@ietf.org > Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion >=20 > > > > > > > >>From: kent_landfield > >>> > >>Date: Monday, August 6, 2012 8:24 AM > >>To: "lnunez@c3isecurity.com" > >>>, > >> Adam Montville > > > >>Cc: "shanna@juniper.net" > >>>, > >> "sacm@ietf.org" > >>> > >>Subject: Re: [sacm] Weekly Meetings for Charter and Use Case > Discussion > >> > >> > >>Personally I'd rather do this on the list. I have no problem with > calls > >>but that reduces the transparency at a time we really need it. > >> > >>Kent Landfield > >> > >> > >>McAfee | An Intel Company > >>Direct: +1.972.963.7096 > >>Mobile: +1.817.637.8026 > >>Web: www.mcafee.com > >> > >> > >>From: Luis Nunez > > > >>Date: Monday, August 6, 2012 10:08 AM > >>To: Adam Montville > >>> > >>Cc: Stephen Hanna >, > >>"'sacm@ietf.org'" > >> > > >>Subject: Re: [sacm] Weekly Meetings for Charter and Use Case > Discussion > >> > >> > >>I open for the proposed times. It may be good to have it on a Monday > so > >>that we can work on specifics during the week. > >> > >> > >>-ln > >> > >> > >>On Aug 6, 2012, at 9:35 AM, Adam Montville wrote: > >> > >> > >>On 8/5/12 5:59 PM, "Stephen Hanna" > >>> wrote: > >>Great! All those times are fine with me. >=20 >=20 > Any other opinions regarding doing this work exclusively on the list or > augmenting the on-list communication with weekly calls until our use > cases > and/or draft charter are "done." I'd like to see this topic come to a > close later this week, perhaps by end of day Thursday (Pacific time). >=20 >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From tony@yaanatech.com Tue Aug 7 04:11: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 E60E221F861B for ; Tue, 7 Aug 2012 04:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QNwKp9qUgoH for ; Tue, 7 Aug 2012 04:11:02 -0700 (PDT) Received: from extmail1.prd.yaanatech.com (extmail1.prd.yaanatech.com [205.140.198.37]) by ietfa.amsl.com (Postfix) with ESMTP id 82AEC21F85DB for ; Tue, 7 Aug 2012 04:10:58 -0700 (PDT) Received: from [192.168.0.4] (pool-173-72-150-118.clppva.fios.verizon.net [173.72.150.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extmail1.prd.yaanatech.com (Postfix) with ESMTP id 0664C58081; Tue, 7 Aug 2012 11:10:56 +0000 (UTC) Message-ID: <5020F7C0.7020806@yaanatech.com> Date: Tue, 07 Aug 2012 07:10:56 -0400 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: mrex@sap.com References: <20120807063851.7CF191A125@ld9781.wdf.sap.corp> In-Reply-To: <20120807063851.7CF191A125@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sacm@ietf.org, Anton Chuvakin Subject: Re: [sacm] Legal aspects of System 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: Tue, 07 Aug 2012 11:11:03 -0000 Hi Martin, Could you take this discussion, including your political commentary concerning countries, to another appropriate venue. I am a lawyer and very familiar with the subject matter. Your constructions here are extreme even in the jurisdictions you reference. You have every right to voice them - in the appropriate forum. This is not a forum for advancing socio-political views. --tony On 8/7/2012 2:38 AM, Martin Rex wrote: > The US legal system seems seriously skewed on some aspects. From shanna@juniper.net Tue Aug 7 04:16:57 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 2708021F86A1 for ; Tue, 7 Aug 2012 04:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4UgJS-EKBrJ for ; Tue, 7 Aug 2012 04:16:55 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9F921F8672 for ; Tue, 7 Aug 2012 04:16:53 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUCD5JfOs89RB0tZ9KpT62NLNsxIOy2Ht@postini.com; Tue, 07 Aug 2012 04:16:55 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 7 Aug 2012 04:15:48 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 7 Aug 2012 07:15:47 -0400 From: Stephen Hanna To: "mrex@sap.com" Date: Tue, 7 Aug 2012 07:15:46 -0400 Thread-Topic: [sacm] Legal aspects of System monitoring Thread-Index: Ac10TrS0Q654CVi+TcmStnnPJolS+AAObFfA Message-ID: References: <502018FA.20603@yaanatech.com> <20120807034236.D32801A126@ld9781.wdf.sap.corp> In-Reply-To: <20120807034236.D32801A126@ld9781.wdf.sap.corp> 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 Cc: "sacm@ietf.org" Subject: Re: [sacm] Legal aspects of System 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, 07 Aug 2012 11:16:57 -0000 I am certainly no expert on European law in this area. However, I will note that monitoring and auditing corporate information systems and networks is common practice in corporate environments. Generally, the Acceptable Use Policy includes consent to monitoring and audits. For example, look at the SANS template for an Acceptable Use Policy available at http://www.sans.org/security-resources/policies/Acceptable_Use_Policy.pdf In some environments (universities and libraries), intellectual freedom may trump security in some cases. However, even universities generally include provisions for monitoring when necessary. For example, here are a few policies for universities in the USA, UK, and Germany: http://www.it.ufl.edu/policies/monitoring.html http://www.admin.ox.ac.uk/statutes/regulations/196-052.shtml http://www.cip.bv.tum.de/en/cippools-/termsofuse These policies were chosen at random, not deliberately to support one point of view or another. But they are remarkably similar in many respects. I observe that the Technical University of Munich permits monitoring of user behavior and forensic analysis under appropriate circumstances. So I conclude that the techniques and technologies for monitoring user behavior and system configuration are used around the world. However, there is a constant balance between user privacy and system security. The nature of this balance may vary depending on the jurisdiction and on the application (military networks vs. corporate vs. university vs. home). There's a nice discussion of this balance in the (ISC)2 Guide to the CISSP CBK (Second Edition) on pages 516 and 517. In the SACM group, we're talking about developing technology that will help corporations to better secure their computer systems and networks. We should carefully note the importance of maintaining balance between user privacy and system security and obeying all relevant laws, rules, and regulations. However, it would be foolish for us to think that we can come up with one policy that would apply in all circumstances. Instead, we should permit system and network owners to establish and implement their own policies. At least, that's my point of view. Thanks, Steve From brford@cisco.com Tue Aug 7 05:11:39 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA1521F866B for ; Tue, 7 Aug 2012 05:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxZp6HEX-bRH for ; Tue, 7 Aug 2012 05:11:37 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2126F21F8639 for ; Tue, 7 Aug 2012 05:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=brford@cisco.com; l=2654; q=dns/txt; s=iport; t=1344341497; x=1345551097; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=TWzOmuVc52poIBMHvjfL1F1TfS02mfX3jyWhhIdxcNc=; b=b3vWJ1edrlOLgZ45K+HqRajoF+68CbpKBWFWUNd7dXpHTwC8dp/h9DtR TOJbquzlJB4BnYi3Ef6uq7Cr5aVJl1iv9Iee3rJuRxq5aOyLfsq7ABzl/ itudFz6CIeRSOnvFbp+CkJhpE8kxjjQaYLmX6abMly11L8sLmCIfrQ31v E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABMFIVCtJV2a/2dsb2JhbABCA7lHgQeCIAEBAQQSAScPMBIBCAcKAwECAR4JORQJCAIEDgUih2ubUqBIiw+DTIMhA5VIjiaBZoJf X-IronPort-AV: E=Sophos;i="4.77,726,1336348800"; d="scan'208";a="109133919" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 07 Aug 2012 12:11:33 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q77CBXkc018221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 12:11:33 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.192]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 07:11:33 -0500 From: "Brian Ford (brford)" To: "sacm@ietf.org" Thread-Topic: [sacm] Weekly Meetings for Charter and Use Case Discussion Thread-Index: AQHNdJXIpQdRnZU53kmSQn9iNiyCwg== Date: Tue, 7 Aug 2012 12:11:32 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.98.29.185] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19090.004 x-tm-as-result: No--49.213100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <126DFFEFBA9EC049BAC9ADF913586915@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lnunez@c3isecurity.com" , "shanna@juniper.net" , "Kent_Landfield@McAfee.com" , Adam Montville Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 07 Aug 2012 12:11:39 -0000 Folks, It seems that this discussion has suddenly picked up a lot of momentum since the creation of an interest list in late 2010. Holding "regular weekly calls" before charter feels like it amplifies the positions of those who facilitate and can participate in calls. It doesn't make this seem like an open forum. It would be one thing if these calls were about specific proposals or documents but otherwise it feels like an effort to steer this work. Liberty, Brian =20 On 8/6/12 9:17 PM, "Adam Montville" wrote: >> >> >> >>>From: kent_landfield >>>> >>>Date: Monday, August 6, 2012 8:24 AM >>>To: "lnunez@c3isecurity.com" >>>>, >>> Adam Montville=20 >>>> >>>Cc: "shanna@juniper.net" >>>>, >>> "sacm@ietf.org" >>>> >>>Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion >>> >>> >>>Personally I'd rather do this on the list. I have no problem with calls >>>but that reduces the transparency at a time we really need it. >>> >>>Kent Landfield >>> >>> >>>McAfee | An Intel Company >>>Direct: +1.972.963.7096 >>>Mobile: +1.817.637.8026 >>>Web: www.mcafee.com >>> >>> >>>From: Luis Nunez > >>>Date: Monday, August 6, 2012 10:08 AM >>>To: Adam Montville >>>> >>>Cc: Stephen Hanna >, >>>"'sacm@ietf.org'" >>> > >>>Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion >>> >>> >>>I open for the proposed times. It may be good to have it on a Monday so >>>that we can work on specifics during the week. >>> >>> >>>-ln >>> >>> >>>On Aug 6, 2012, at 9:35 AM, Adam Montville wrote: >>> >>> >>>On 8/5/12 5:59 PM, "Stephen Hanna" >>>> wrote: >>>Great! All those times are fine with me. > > >Any other opinions regarding doing this work exclusively on the list or >augmenting the on-list communication with weekly calls until our use cases >and/or draft charter are "done." I'd like to see this topic come to a >close later this week, perhaps by end of day Thursday (Pacific time). > > > > > From michael.hammer@yaanatech.com Tue Aug 7 06:32:15 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A92A21F8653 for ; Tue, 7 Aug 2012 06:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qC4iHi7ZP3Y for ; Tue, 7 Aug 2012 06:32:14 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 730FA21F8602 for ; Tue, 7 Aug 2012 06:32:13 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 7 Aug 2012 06:32:13 -0700 From: Michael Hammer To: "mrex@sap.com" , "anton@chuvakin.org" Thread-Topic: [sacm] Legal aspects of System monitoring Thread-Index: AQHNcebv9wpWqLOXkkW1HGuGxo9Hw5dKJ8AAgANL5YCAAAL0gIAACqqAgAAKjYCAAA8AAIAAB8sAgACMTgCAABRugIAAHNCA///9L9A= Date: Tue, 7 Aug 2012 13:32:11 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB30B910926@EX2K10MB1.corp.yaanatech.com> References: <20120807063851.7CF191A125@ld9781.wdf.sap.corp> In-Reply-To: <20120807063851.7CF191A125@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.20] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0016_01CD747F.846591D0" MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Legal aspects of System 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, 07 Aug 2012 13:32:15 -0000 ------=_NextPart_000_0016_01CD747F.846591D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Martin, In the U.S. so long as the employer explicitly points out to the user that he is using the employers equipment, and that such use is for business purposes only, and all other activity is prohibited, and that the employer will be monitoring to ensure the employer's equipment is used for business purposes only, it is in line with common business practice to do so. This is just the online version of an employer noticing his employee spending all his time reading Playboy at work and being on the phone talking to his girlfriend, and telling him to get back to work. Don't tell me that is permissible behavior in Germany. Mike -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Martin Rex Sent: Tuesday, August 07, 2012 2:39 AM To: Anton Chuvakin Cc: sacm@ietf.org Subject: Re: [sacm] Legal aspects of System monitoring Anton Chuvakin wrote: > > Martin Rex wrote: >> >> You would have to limit most in Section 3.2 and later to situations >> where facts create probable cause _before_ collecting and evaluating >> the data, and limit all collections upfront(!) to probable cause. > > If you do that (reduce to 'probably cause') it won't really be > 'monitoring', now will it? It would be 'investigation.' > Monitoring is how you realize that you have a cause to investigate. Which is exactly what I wrote in my initial message in this thread: On 8/3/2012 10:14 PM, Martin Rex wrote: > In Germany, an employer monitoring a company-owned PC that an employee > uses for communication (EMail, VoiP, IM) would be unconditionally illegal. What puzzles me is that monitoring of end-user systems is not at least recognized as highly unethical for jurisdictions where it is not outright illegal. The US legal system seems seriously skewed on some aspects. While there seem to extremly strong "fruit from the forbidden tree" provisions in the US that may exclude illegally obtained evidence from prosecution even in cases of murder, the appear to be effectively zero privacy protections for employees at the workplace (or outside their homes or without curtains closed...). -Martin _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_000_0016_01CD747F.846591D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgw NzEzMzIwOVowIwYJKoZIhvcNAQkEMRYEFHrfaoikEpymFydgPXbb3O4lR/8XMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAxVykDE/pgl1z0sRcLKZi1gRjtrBZADvH7BJC058HGGiN 5sS/B0g+nKhTzmWUeZYfYI4eaNmp8ZEAfTadctTw50MxD3FWx96vIS+D0iHWhUiOgndKn/5/lAO2 pGVoDdM6QzrL/2MNZpCn6nxXa7Nl2yBTSBN2mur1xgs3GAFmYj8AAAAAAAA= ------=_NextPart_000_0016_01CD747F.846591D0-- From shanna@juniper.net Tue Aug 7 07:34:39 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B30B21F86C5 for ; Tue, 7 Aug 2012 07:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4Iu4AEJWQIt for ; Tue, 7 Aug 2012 07:34:38 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5EB21F86B4 for ; Tue, 7 Aug 2012 07:34:36 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUCEne1a3fNh29/0b2qyggDsE4XXhYlmb@postini.com; Tue, 07 Aug 2012 07:34:38 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 7 Aug 2012 07:34:18 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 7 Aug 2012 07:34:18 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 7 Aug 2012 10:34:17 -0400 From: Stephen Hanna To: "Brian Ford (brford)" , "sacm@ietf.org" Date: Tue, 7 Aug 2012 10:34:16 -0400 Thread-Topic: [sacm] Weekly Meetings for Charter and Use Case Discussion Thread-Index: AQHNdJXIpQdRnZU53kmSQn9iNiyCwpdOaQXg 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lnunez@c3isecurity.com" , "Kent_Landfield@McAfee.com" , Adam Montville Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 07 Aug 2012 14:34:39 -0000 Good point, Brian. Let's skip the whole idea of weekly calls and move directly to working on the proposed charter and drafts and anything else that we'll need to move this project forward. BTW, I'm delighted to see the surge of energy on this list. Having a solid use case document has clearly helped a lot. Thanks, Steve > -----Original Message----- > From: Brian Ford (brford) [mailto:brford@cisco.com] > Sent: Tuesday, August 07, 2012 8:12 AM > To: sacm@ietf.org > Cc: Stephen Hanna; Adam Montville; lnunez@c3isecurity.com; > Kent_Landfield@McAfee.com > Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion >=20 >=20 > Folks, >=20 > It seems that this discussion has suddenly picked up a lot of momentum > since the creation of an interest list in late 2010. >=20 > Holding "regular weekly calls" before charter feels like it amplifies > the > positions of those who facilitate and can participate in calls. It > doesn't make this seem like an open forum. It would be one thing if > these > calls were about specific proposals or documents but otherwise it feels > like an effort to steer this work. >=20 > Liberty, >=20 > Brian >=20 >=20 > On 8/6/12 9:17 PM, "Adam Montville" wrote: >=20 > >> > >> > >> > >>>From: kent_landfield > >>>> > >>>Date: Monday, August 6, 2012 8:24 AM > >>>To: "lnunez@c3isecurity.com" > >>>>, > >>> Adam Montville > >>>> > >>>Cc: "shanna@juniper.net" > >>>>, > >>> "sacm@ietf.org" > >>>> > >>>Subject: Re: [sacm] Weekly Meetings for Charter and Use Case > Discussion > >>> > >>> > >>>Personally I'd rather do this on the list. I have no problem with > calls > >>>but that reduces the transparency at a time we really need it. > >>> > >>>Kent Landfield > >>> > >>> > >>>McAfee | An Intel Company > >>>Direct: +1.972.963.7096 > >>>Mobile: +1.817.637.8026 > >>>Web: www.mcafee.com > >>> > >>> > >>>From: Luis Nunez > > > >>>Date: Monday, August 6, 2012 10:08 AM > >>>To: Adam Montville > >>>> > >>>Cc: Stephen Hanna >, > >>>"'sacm@ietf.org'" > >>> > > >>>Subject: Re: [sacm] Weekly Meetings for Charter and Use Case > Discussion > >>> > >>> > >>>I open for the proposed times. It may be good to have it on a > Monday so > >>>that we can work on specifics during the week. > >>> > >>> > >>>-ln > >>> > >>> > >>>On Aug 6, 2012, at 9:35 AM, Adam Montville wrote: > >>> > >>> > >>>On 8/5/12 5:59 PM, "Stephen Hanna" > >>>> wrote: > >>>Great! All those times are fine with me. > > > > > >Any other opinions regarding doing this work exclusively on the list > or > >augmenting the on-list communication with weekly calls until our use > cases > >and/or draft charter are "done." I'd like to see this topic come to a > >close later this week, perhaps by end of day Thursday (Pacific time). > > > > > > > > > > From amontville@tripwire.com Tue Aug 7 08:17: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 145D821F8720 for ; Tue, 7 Aug 2012 08:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.793 X-Spam-Level: X-Spam-Status: No, score=-3.793 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RXmdtMna4x1 for ; Tue, 7 Aug 2012 08:17:51 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7FC21F871D for ; Tue, 7 Aug 2012 08:17:51 -0700 (PDT) Received: from mail118-ch1-R.bigfish.com (10.43.68.240) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Tue, 7 Aug 2012 15:17:49 +0000 Received: from mail118-ch1 (localhost [127.0.0.1]) by mail118-ch1-R.bigfish.com (Postfix) with ESMTP id E616B480155; Tue, 7 Aug 2012 15:17:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -6 X-BigFish: VPS-6(z3d0Izbb2dI98dI9371I1454I1432Izz1202hzz8275chz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail118-ch1 (localhost.localdomain [127.0.0.1]) by mail118-ch1 (MessageSwitch) id 1344352668217368_29348; Tue, 7 Aug 2012 15:17:48 +0000 (UTC) Received: from CH1EHSMHS021.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail118-ch1.bigfish.com (Postfix) with ESMTP id 27DEC140055; Tue, 7 Aug 2012 15:17:48 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 7 Aug 2012 15:17:46 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 7 Aug 2012 08:19:46 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Tue, 7 Aug 2012 08:17:45 -0700 From: Adam Montville To: Stephen Hanna , "Brian Ford (brford)" , "sacm@ietf.org" Thread-Topic: [sacm] Weekly Meetings for Charter and Use Case Discussion Thread-Index: AQHNcz71G4HXk6Xx6kKyTzC8edNDKpdL9NaQgADVQACAAI+GgIAABGsA//+UxoCAAHZPAIAAJTUAgAEsGgCAACfhAP//ls2A Date: Tue, 7 Aug 2012 15:17:44 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.16.97.192] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Cc: "lnunez@c3isecurity.com" , "Kent_Landfield@McAfee.com" Subject: Re: [sacm] Weekly Meetings for Charter and Use Case Discussion X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 07 Aug 2012 15:17:52 -0000 On 8/7/12 7:34 AM, "Stephen Hanna" wrote: >Good point, Brian. Let's skip the whole idea of weekly calls >and move directly to working on the proposed charter and >drafts and anything else that we'll need to move this >project forward. Very well, then it seems that there's no need for calls and we'll conduct all sacm-related business right here on the list. Good! Consequent to the Vancouver side meeting and subsequent discussion on this list, we have the following actions (thanks to Steve Hanna for starting this list): 1. Update the draft charter to reflect desired changes 2. Continue fleshing out the Use Case document 3. Review IPR statements from MITRE and decide whether they are acceptable. 4. Based on the controls supported by the Use Cases, we can identify gaps in the required models and start creating some additional drafts. This may include the content repository draft already proposed by Dave Waltermire and some existing, unencumbered specifications. So far, here's what I believe to be true: Kent Landfield will update the charter based on to-date feedback; Dave Waltermire and myself will co-edit the Use Case document (we'll more than likely need help with this); I have submitted a frame of reference document to this list as something that can be either included in the Use Case document or that will stand on it's own; I have volunteered to create a glossary, if needed (this work will come later). =20 The overall, community-imposed target deadline for this work is mid-September, but I would feel better pushing it up to Friday, September 7. That gives us almost five working weeks, with potentially an extra week if we need to go to the 14th. Kent, when do you think you'll be able to update the draft charter and send it to the list? Dave, how do envision moving forward with the use case document? Finally, if anyone has any issues with the way this is being organized, feel free to offer alternatives and/or constructive criticism. We all very much want this to be a community-focused effort and, while we have some IETF veterans in the group, sacm is new to this environment. > >BTW, I'm delighted to see the surge of energy on this list. >Having a solid use case document has clearly helped a lot. +1 Regards, Adam From david.oliva@verizon.net Tue Aug 7 08:47:24 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D283F21F876D for ; Tue, 7 Aug 2012 08:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMGjcodoQTtX for ; Tue, 7 Aug 2012 08:47:23 -0700 (PDT) Received: from vms173021pub.verizon.net (vms173021pub.verizon.net [206.46.173.21]) by ietfa.amsl.com (Postfix) with ESMTP id 428FB21F8733 for ; Tue, 7 Aug 2012 08:47:23 -0700 (PDT) Received: from vms170025pub.verizon.net ([unknown] [192.168.1.3]) by vms173021.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M8E002MI6I2J0L4@vms173021.mailsrvcs.net> for sacm@ietf.org; Tue, 07 Aug 2012 10:46:51 -0500 (CDT) Received: from 96.241.55.45 ([96.241.55.45]) by vms170025 (Verizon Webmail) with HTTP; Tue, 07 Aug 2012 10:46:50 -0500 (CDT) Date: Tue, 07 Aug 2012 10:46:50 -0500 (CDT) From: david.oliva@verizon.net To: lnunez@c3isecurity.com, sacm@ietf.org Message-id: <25991702.1861986.1344354410248.JavaMail.root@vms170025> 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.55.45] Subject: Re: [sacm] Legal aspects of System 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, 07 Aug 2012 15:47:25 -0000
&nb= sp;Luis and all:
 
You are on target.
SACM is not a law enforcement thing, but is a facilitator of leg= al issues in association with the protection of private information and hea= lth-related information.

I th= ink a couple of examples to show how SACM facilitates legal issues about pe= rsonal information is in order.

A = SACM configuration scanner is able to monitor the configuration of security= controls as specified in ISO/IEC 27001:2005.  This can be accomplished when tier IV SCAP content is use= d because the output maps the finding (compliance or non-compliance) of the= scanner to security control ISO/IEC 27001:2005 paragraph A.10.6.2 =E2=80= =9CSecurity of Network Services=E2=80=9D.=   Thus a SACM scanner is able to assist in international govern= ance compliance about personal information because SP 800-53 maps to ISO 27= 001.

A SACM vulnerability scanner = is able to meet compliance with ISO 27001, para A.12.6.1 =E2=80=9CControl o= f technical vulnerabilities=E2=80=9D because a SACM scanner using SCAP tier= IV content can map its output to the ISO governance.  SACM Vulnerability scanning can address aspects o= f confidentiality of personal information by identifying software vulnerabi= lities of the databases that house them, and do it in the context of an int= ernational set of security standards.

 
David Oliva
 
 
 
=
On 08/06/12, <= SPAN>Luis Nunez<lnunez@c3isecurity.com> wrote:
&nbs= p;
= Looking at it another way I could see security automation as a way to disco= ver if a system is configured to meet privacy policies .  

Security automation is an enabler for transparency  so that in= dividuals and organizations may understand the complex computing environmen= t.

Thanks for bring up this issue.  As a= community we may want to look at building content around privacy controls.=

-ln

On Aug 6, 2012, at 12= :42 PM, <Kent_Landfield@McAfee.com> wrote:

None of the efforts we are talking about for SAC= M are targeted toward PII or individuals. They are targeted at the configur= ation of the platforms deployed in the enterprise to assure they comply wit= h the site's security policy.  PII is not collected. This is not monit= oring of individual or employee actions.  I am not a lawyer and will n= ot speak as one. We will let the lawyer's decide at the appropriate time.

Kent Landfield

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

From:= Martin Rex <mrex@sap.com>
R= eply-To: "mrex@sap.com" <mrex@sap.com>
Date: Monday, August 6, 2012 11:32 AM
To: "tony@yaanatech.com" <tony@yaanatech.com= >
Cc: "mrex@sap.com" <mrex@sap.com<= /A>>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Legal aspects of System monitoring

Tony Rutkowski wrote:
Martin Rex wrote:

In = Germany, an employer monitoring a company-owned PC that an employee uses
for communication (EMail, VoiP, IM) would be unconditionally illega= l.

Really?
No kidding!



That is not= consistent with comments
I've seen concerning German law.
<= /BLOCKQUOTE>

There is a significant amount of mis-inform= ation floating the internet.
And a mindboggling large number of l= awyers are making wild guesses, rather
that doing research.
=

The decisions of the german federal constitional court = (GFCC) have been
quite consistent over the past decade about what= with respect to
encroaching on the general right of personality,= informational
self-determination, freedom of conduct and created= a "fundamental right
to the guarantee of the integrity and confi= dentiality of information
technology systems".  The cou= rt has set the minimum requirements that
are prerequisite to such= encroachment, such as the prerequisite of a
clear formal statute= law, which needs to be limited to situation where
real facts cre= ate probable cause.

The original GFCC decision in = german language is quite comprehensible
(to me, at least), while = I'm having some difficulties understanding
the english translatio= n (and the english translation is shorter!?).

BVer= fG-Entscheidung "1 BvR 370/07 vom 27.2.2008" Randnummer 196-

english translation of "1 BvR 37= 0/07 vom 27.2.2008"


To be *unconditionally* illegal, would
preclude = almost any rationally required
maintenance or threat mitigation.<= /DIV>

It is possible to perform maintenance= and threat mitigation entirely
without "monitoring" systems.

A mere threat is insufficient for monitoring, if that= involves collecting
PII data, i.e. data from which a persons con= duct can be infered.



It is fair t= o observe that recent German
Constitutional Court decisions impos= e
constraints, but they certainly are
not "unconditiona= l."

One of the prerequisite is a clea= r formal statute law,
which currently does not exist for the purp= oses "sacm" is about.

quoting from the above GFCC = decision:

  2. The fundamental right to = the guarantee of the confidentiality and
  integrity of= information technology systems is not unrestricted.
  = Encroachments may be justified both for preventive purposes, and for
<= DIV>  criminal prosecution.  The individual must only a= ccept such restrictions
  of his or her right which are= based on a statutory foundation that
  is constitution= al.


This currently makes collectin= g data about peoples conduct "unconditionally"
illegal for most p= ractical purposes (exempting from prosecution only
individual occ= asions of justified self-defence against an imminent
vicious atta= ck based on real facts that create probable cause).

This applies to all surveillance that impairs persons "freedom of conduct= ".
The majority of past decisions of specific events was about su= rveillance
with a camera, but the GFCC decision makes it crystal = clear that
this applies to *any* kind of surveillance.  = ;Different to monitoring of
computer systems, there is statutory = law for camera surveillance,
that allows optical surveillance und= er certain conditions
(Art. 6b BDSG "BundesDatenSchutzGesetz).

The lack of a formal statutory foundation makes surv= eillance illegal
and entitles subjects to "cease and desist" ruli= ngs and sometimes
damages.

In one more r= ecent (and constitutionally correct) rulings, an employer
had put= up a camera that had in view not only the entrance door, but
als= o two workplaces.  The employees protested against this camera,
but the employer would not "fix" it, so at least one employee sued= ,
The court confirmed that this camera surveillance at the workpl= ace
was illegal due to its chilling effect alone, and since it ha= d been
installed for a whole year, the employee was arwarded 4 mo= nth of income
as damages (for the chilling effect).
Another recent decision was about evidence from a covert video<= /DIV>
surveillance showing an employee taking a package of cigarettes
on two occasions, where the German Federal Labour Court
= (the supreme court for labor related issues) remanded the decision
to the trial court because it had failed to establish whether the
covert video surveillance really met all constitutional prerequisites
otherwise the video surveillance would have been illegal and not
be admissible as evidence in court.

The German Federal Constitional Cou= rt neutered numerous laws during the
last decade due to lack of c= larity and/or overbroad encroachment of
the personal right of sel= f-determination and the right to confidentiality
of telecommunica= tions.

See also the GFCC decision about the scanni= ng of license plates
(the decision 1 BvR 2074/05 vom 11.3.2008 in= german)

where it confirmed th= at data collection requires formal statue law,
and that the law i= n question wasn't limited to probable cause and
therefore unconst= itutional.


The only currently exist= ing formal statue law in Germany, that could be
used in some limi= ted fashion for "Monitoring" is Art.100 TKG,
but tha= t statue is clearly limited in purpose, it will not allow that data
to be used for automatic surveillance of "employee conduct" with respect=
to "company-defined policies".  Employers try hard to = avoid TKG for their
networks (for which they will have to formall= y register), but that also
means that they do not have a formal s= tatutory law for performing any
kind of surveillance/monitoring a= s described in Art. 100 TKG for systems
that are used by employee= s for telecommunications and a significant part
of their daily ac= tivies.


-Martin
_________= ______________________________________
sacm mailing list
sacm= @ietf.org

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


_________________________________________= ______
sacm mailing list
sacm@ietf.org
https://www.ie= tf.org/mailman/listinfo/sacm
From david.waltermire@nist.gov Tue Aug 7 13:10: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 D3CAC11E8097 for ; Tue, 7 Aug 2012 13:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLLic7-2cXyb for ; Tue, 7 Aug 2012 13:10:02 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id D490E21F8716 for ; Tue, 7 Aug 2012 13:10:01 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 7 Aug 2012 16:09:45 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 7 Aug 2012 16:08:39 -0400 From: "Waltermire, David A." To: Adam Montville , "sacm@ietf.org" Date: Tue, 7 Aug 2012 16:09:58 -0400 Thread-Topic: Using the Frame of Reference Thread-Index: AQHNdDkTRwSx007YrEGOEBCjcgvwt5dOvU9A 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] Using the Frame of Reference X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 07 Aug 2012 20:10:04 -0000 Are your 5 aspects of SCM controls or activities? I would argue more so that latter. I also like how you have broken down the different "layers" of information for each of the 5 aspects. In my mind the initial scope of this effort should focus on the "Observable Model" and lower which I would interpret as being the data formats that describe what is to be observed, how to observe it, and how to report those observations. Things like tasking are the protocol bits to ensure that the right observations are made and that the results are provided (or not provided) to specific network components. If we wanted to look further, we could then start into the Assessment and Remediation models. I would argue that "Configuration Assessment" might have a "configuration compliance" model above "assessment" that would be a peer to "vulnerability". This would put the configuration state in context within the enterprise, just like the "vulnerability model" does. It is at the scoring/risk layer that we may want to tie-in control frameworks. But what does this really mean? Does it mean that you are demonstrating successful implementation of a control through the collection of supporting data? Does it mean providing data that indicates that the use of the control is effective in reducing security exposure or risk? There are many other considerations as well. It might be enough for this effort to ensure that the results from the assessment/remediation model/layer is capable of being associated with the controls they implement. This could be done through identifier mapping, content references, or other methods. Sincerely, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Monday, August 06, 2012 9:08 PM > To: sacm@ietf.org > Subject: [sacm] Using the Frame of Reference > > All: > > Here's how I would envision using the frame of reference using Security > Configuration Management (SCM) as an example. > > SCM is really five controls often assisted by technical toolsets > (depending on who you ask, so this is just one perspective): > > 1. Configuration Assessment (password length is set to x) > 2. Patch and Vulnerability Assessment (software package x is at > version > a.b.c) > 3. Configuration Remediation (set password length to x) > 4. Patch Remediation (bring software package x to at least version > a.b.c) > 5. Rate of Change (how are the files, registry entries, and other > Settings changing over time > > Because asset management is critical to the success of these controls, > I assert that we should revisit what we have today in the way of models > and where we need improvement (gaps or less than ideal coverage). > Appropriate asset models are required for each of SCM's constituent > parts, as listed below. > > We might assert the following information model relationships: > > o Security Configuration Management is composed of > o Configuration Assessment, which requires a/an > - Asset Model (information/characterization) > - Observable Model, > - Assessment Model (checklists), > - Scoring/Risk Model; > o Patch and Vulnerability Assessment, which requires a/an > - Asset Model, > - Observable Model, > - Assessment Model, > - Vulnerability Model, > - Scoring/Risk Model; > o Configuration Remediation, which requires a/an > - Asset Model, > - Observable Model, > - Remediation Model; > o Patch Remediation, which requires a/an > - Asset Model, > - Observable Model, > - Remediation Model. > > Note that some of the Supporting Concepts would be helpful here as > well. > Tasking/Workflow, is one example (consider assessing an endpoint, > remediating, then reassessing). > > The Observable Model should be one that describes that which can be > technically observed on an endpoint and which is able to provide > contextual information with respect to that observable (either directly > or through use of another model). For example, if I'm looking at a the > Account Lockout Duration setting for a Windows Server 2008 R2 machine > Group Policy Object, then we should provide the means for content > producers to include acceptable values for that configuration item, > such that implementers using these specifications can provide guidance > to their users with respect to that particular setting. > > Something that seems lacking here is tying back to control frameworks > (control in the ISO 27000/NIST 800-53 sense of the term). In the case > of SCM, we could use any number of the available control frameworks to > guide us. For example, the third SANS Top 20 Critical Control, "Secure > Configurations for Hardware and Software on Laptops, Workstations, and > Servers" might require one or more SCM constituents as defined above. > > I'm particularly interested in this because it has been shown that, to > date, security automation efforts have been rather shotgun in their > approach and have not necessarily done a good job ensuring that > requirements derived from top-level scenarios are being satisfied. > Also, knowing the exact needs of these controls can help us focus on > what that which must be done, rather than upon that which could be > done. > > Regards, > > Adam > > > > > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From kathleen.moriarty@emc.com Tue Aug 7 13:21: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 55AA121F8600 for ; Tue, 7 Aug 2012 13:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IhSl7l1PLiu for ; Tue, 7 Aug 2012 13:21:52 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 668CC21F85F3 for ; Tue, 7 Aug 2012 13:21:51 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q77KLhva006467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Aug 2012 16:21:49 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 7 Aug 2012 16:21:34 -0400 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q77KLXSt006348; Tue, 7 Aug 2012 16:21:33 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub07.corp.emc.com ([128.222.70.204]) with mapi; Tue, 7 Aug 2012 16:21:32 -0400 From: "Moriarty, Kathleen" To: "Waltermire, David A." , Adam Montville , "sacm@ietf.org" Date: Tue, 7 Aug 2012 16:21:31 -0400 Thread-Topic: Using the Frame of Reference Thread-Index: AQHNdDkTRwSx007YrEGOEBCjcgvwt5dOvU9AgAAOJhA= 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] Using the Frame of Reference X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 07 Aug 2012 20:21:53 -0000 I would put policy, asset management, and configuration management at the b= ase level before you can move into these areas. Are we making an assumptio= n that this effort is separate from those? It seems like that may be the c= ase where assessments of configurations is separate from the management of = configurations. If that assumption is being made, we should state it clear= ly. Thanks, Kathleen -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Wal= termire, David A. Sent: Tuesday, August 07, 2012 4:10 PM To: Adam Montville; sacm@ietf.org Subject: Re: [sacm] Using the Frame of Reference Are your 5 aspects of SCM controls or activities? I would argue more so th= at latter. I also like how you have broken down the different "layers" of = information for each of the 5 aspects. In my mind the initial scope of thi= s effort should focus on the "Observable Model" and lower which I would int= erpret as being the data formats that describe what is to be observed, how = to observe it, and how to report those observations. Things like tasking a= re the protocol bits to ensure that the right observations are made and tha= t the results are provided (or not provided) to specific network components= . If we wanted to look further, we could then start into the Assessment and R= emediation models. I would argue that "Configuration Assessment" might have a "configuration c= ompliance" model above=20 "assessment" that would be a peer to "vulnerability". This would put the c= onfiguration state in context within the enterprise, just like the "vulnera= bility model" does. It is at the scoring/risk layer that we may want to tie-in control framewor= ks. But what does this really mean? Does it mean that you are demonstrati= ng successful implementation of a control through the collection of support= ing data? Does it mean providing data that indicates that the use of the c= ontrol is effective in reducing security exposure or risk? There are many = other considerations as well. It might be enough for this effort to ensure that the results from the asse= ssment/remediation model/layer is capable of being associated with the cont= rols they implement. This could be done through identifier mapping, conten= t references, or other methods. Sincerely, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Monday, August 06, 2012 9:08 PM > To: sacm@ietf.org > Subject: [sacm] Using the Frame of Reference >=20 > All: >=20 > Here's how I would envision using the frame of reference using Security > Configuration Management (SCM) as an example. >=20 > SCM is really five controls often assisted by technical toolsets > (depending on who you ask, so this is just one perspective): >=20 > 1. Configuration Assessment (password length is set to x) > 2. Patch and Vulnerability Assessment (software package x is at > version > a.b.c) > 3. Configuration Remediation (set password length to x) > 4. Patch Remediation (bring software package x to at least version > a.b.c) > 5. Rate of Change (how are the files, registry entries, and other > Settings changing over time >=20 > Because asset management is critical to the success of these controls, > I assert that we should revisit what we have today in the way of models > and where we need improvement (gaps or less than ideal coverage). > Appropriate asset models are required for each of SCM's constituent > parts, as listed below. >=20 > We might assert the following information model relationships: >=20 > o Security Configuration Management is composed of > o Configuration Assessment, which requires a/an > - Asset Model (information/characterization) > - Observable Model, > - Assessment Model (checklists), > - Scoring/Risk Model; > o Patch and Vulnerability Assessment, which requires a/an > - Asset Model, > - Observable Model, > - Assessment Model, > - Vulnerability Model, > - Scoring/Risk Model; > o Configuration Remediation, which requires a/an > - Asset Model, > - Observable Model, > - Remediation Model; > o Patch Remediation, which requires a/an > - Asset Model, > - Observable Model, > - Remediation Model. >=20 > Note that some of the Supporting Concepts would be helpful here as > well. > Tasking/Workflow, is one example (consider assessing an endpoint, > remediating, then reassessing). >=20 > The Observable Model should be one that describes that which can be > technically observed on an endpoint and which is able to provide > contextual information with respect to that observable (either directly > or through use of another model). For example, if I'm looking at a the > Account Lockout Duration setting for a Windows Server 2008 R2 machine > Group Policy Object, then we should provide the means for content > producers to include acceptable values for that configuration item, > such that implementers using these specifications can provide guidance > to their users with respect to that particular setting. >=20 > Something that seems lacking here is tying back to control frameworks > (control in the ISO 27000/NIST 800-53 sense of the term). In the case > of SCM, we could use any number of the available control frameworks to > guide us. For example, the third SANS Top 20 Critical Control, "Secure > Configurations for Hardware and Software on Laptops, Workstations, and > Servers" might require one or more SCM constituents as defined above. >=20 > I'm particularly interested in this because it has been shown that, to > date, security automation efforts have been rather shotgun in their > approach and have not necessarily done a good job ensuring that > requirements derived from top-level scenarios are being satisfied. > Also, knowing the exact needs of these controls can help us focus on > what that which must be done, rather than upon that which could be > done. >=20 > Regards, >=20 > Adam >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Tue Aug 7 14:16: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 B3B9511E80AE for ; Tue, 7 Aug 2012 14:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeGSBOTp1fZI for ; Tue, 7 Aug 2012 14:16:08 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id AD4CE11E809B for ; Tue, 7 Aug 2012 14:16:07 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 7 Aug 2012 17:15:40 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 7 Aug 2012 17:15:44 -0400 From: "Waltermire, David A." To: "Moriarty, Kathleen" , Adam Montville , "sacm@ietf.org" Date: Tue, 7 Aug 2012 17:15:42 -0400 Thread-Topic: Using the Frame of Reference Thread-Index: AQHNdDkTRwSx007YrEGOEBCjcgvwt5dOvU9AgAAOJhCAAA8kcA== 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] Using the Frame of Reference X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 07 Aug 2012 21:16:08 -0000 +1 on clearly defining our assumptions. If you don't mind me asking, what do you mean by "management of configurations"? I am probably being dense. ;-) Dave > -----Original Message----- > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > Sent: Tuesday, August 07, 2012 4:22 PM > To: Waltermire, David A.; Adam Montville; sacm@ietf.org > Subject: RE: Using the Frame of Reference > > I would put policy, asset management, and configuration management at > the base level before you can move into these areas. Are we making an > assumption that this effort is separate from those? It seems like that > may be the case where assessments of configurations is separate from > the management of configurations. If that assumption is being made, we > should state it clearly. > > Thanks, > Kathleen > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Waltermire, David A. > Sent: Tuesday, August 07, 2012 4:10 PM > To: Adam Montville; sacm@ietf.org > Subject: Re: [sacm] Using the Frame of Reference > > Are your 5 aspects of SCM controls or activities? I would argue more > so that latter. I also like how you have broken down the different > "layers" of information for each of the 5 aspects. In my mind the > initial scope of this effort should focus on the "Observable Model" and > lower which I would interpret as being the data formats that describe > what is to be observed, how to observe it, and how to report those > observations. Things like tasking are the protocol bits to ensure that > the right observations are made and that the results are provided (or > not provided) to specific network components. > > If we wanted to look further, we could then start into the Assessment > and Remediation models. > > I would argue that "Configuration Assessment" might have a > "configuration compliance" model above "assessment" that would be a > peer to "vulnerability". This would put the configuration state in > context within the enterprise, just like the "vulnerability model" > does. > > It is at the scoring/risk layer that we may want to tie-in control > frameworks. But what does this really mean? Does it mean that you are > demonstrating successful implementation of a control through the > collection of supporting data? Does it mean providing data that > indicates that the use of the control is effective in reducing security > exposure or risk? There are many other considerations as well. > > It might be enough for this effort to ensure that the results from the > assessment/remediation model/layer is capable of being associated with > the controls they implement. This could be done through identifier > mapping, content references, or other methods. > > Sincerely, > Dave > > > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam Montville > > Sent: Monday, August 06, 2012 9:08 PM > > To: sacm@ietf.org > > Subject: [sacm] Using the Frame of Reference > > > > All: > > > > Here's how I would envision using the frame of reference using > > Security Configuration Management (SCM) as an example. > > > > SCM is really five controls often assisted by technical toolsets > > (depending on who you ask, so this is just one perspective): > > > > 1. Configuration Assessment (password length is set to x) > > 2. Patch and Vulnerability Assessment (software package x is at > > version > > a.b.c) > > 3. Configuration Remediation (set password length to x) > > 4. Patch Remediation (bring software package x to at least version > > a.b.c) > > 5. Rate of Change (how are the files, registry entries, and other > > Settings changing over time > > > > Because asset management is critical to the success of these > controls, > > I assert that we should revisit what we have today in the way of > > models and where we need improvement (gaps or less than ideal > coverage). > > Appropriate asset models are required for each of SCM's constituent > > parts, as listed below. > > > > We might assert the following information model relationships: > > > > o Security Configuration Management is composed of > > o Configuration Assessment, which requires a/an > > - Asset Model (information/characterization) > > - Observable Model, > > - Assessment Model (checklists), > > - Scoring/Risk Model; > > o Patch and Vulnerability Assessment, which requires a/an > > - Asset Model, > > - Observable Model, > > - Assessment Model, > > - Vulnerability Model, > > - Scoring/Risk Model; > > o Configuration Remediation, which requires a/an > > - Asset Model, > > - Observable Model, > > - Remediation Model; > > o Patch Remediation, which requires a/an > > - Asset Model, > > - Observable Model, > > - Remediation Model. > > > > Note that some of the Supporting Concepts would be helpful here as > > well. > > Tasking/Workflow, is one example (consider assessing an endpoint, > > remediating, then reassessing). > > > > The Observable Model should be one that describes that which can be > > technically observed on an endpoint and which is able to provide > > contextual information with respect to that observable (either > > directly or through use of another model). For example, if I'm > > looking at a the Account Lockout Duration setting for a Windows > Server > > 2008 R2 machine Group Policy Object, then we should provide the means > > for content producers to include acceptable values for that > > configuration item, such that implementers using these specifications > > can provide guidance to their users with respect to that particular > setting. > > > > Something that seems lacking here is tying back to control frameworks > > (control in the ISO 27000/NIST 800-53 sense of the term). In the > case > > of SCM, we could use any number of the available control frameworks > to > > guide us. For example, the third SANS Top 20 Critical Control, > > "Secure Configurations for Hardware and Software on Laptops, > > Workstations, and Servers" might require one or more SCM constituents > as defined above. > > > > I'm particularly interested in this because it has been shown that, > to > > date, security automation efforts have been rather shotgun in their > > approach and have not necessarily done a good job ensuring that > > requirements derived from top-level scenarios are being satisfied. > > Also, knowing the exact needs of these controls can help us focus on > > what that which must be done, rather than upon that which could be > > done. > > > > Regards, > > > > Adam > > > > > > > > > > > > > > > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From kathleen.moriarty@emc.com Tue Aug 7 14:25:30 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFA221F84F1 for ; Tue, 7 Aug 2012 14:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2HsNWZ5f88V for ; Tue, 7 Aug 2012 14:25:29 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 585EB21F84D9 for ; Tue, 7 Aug 2012 14:25:29 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q77LPR3W021313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Aug 2012 17:25:28 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 7 Aug 2012 17:25:14 -0400 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q77LPCUb004084; Tue, 7 Aug 2012 17:25:12 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Tue, 7 Aug 2012 17:25:11 -0400 From: "Moriarty, Kathleen" To: "Waltermire, David A." , Adam Montville , "sacm@ietf.org" Date: Tue, 7 Aug 2012 17:25:10 -0400 Thread-Topic: Using the Frame of Reference Thread-Index: AQHNdDkTRwSx007YrEGOEBCjcgvwt5dOvU9AgAAOJhCAAA8kcIAAAgUQ 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] Using the Frame of Reference X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 07 Aug 2012 21:25:30 -0000 The configuration check languages are validating after the configurations h= ave been set. Other systems are used to manage configurations that may be = vendor/product dependant. It may be too hard to reach that aspect of confi= guration management through SACM, but I thought it was important to raise t= he point since one would build their program using such systems and hopeful= ly having configurations meet policy requirements. Then the validation via= a configuration checker would be then next layer. Thanks, Kathleen -----Original Message----- From: Waltermire, David A. [mailto:david.waltermire@nist.gov]=20 Sent: Tuesday, August 07, 2012 5:16 PM To: Moriarty, Kathleen; Adam Montville; sacm@ietf.org Subject: RE: Using the Frame of Reference +1 on clearly defining our assumptions. If you don't mind me asking, what = do you mean by "management of configurations"? I am probably being dense. = ;-) Dave > -----Original Message----- > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > Sent: Tuesday, August 07, 2012 4:22 PM > To: Waltermire, David A.; Adam Montville; sacm@ietf.org > Subject: RE: Using the Frame of Reference >=20 > I would put policy, asset management, and configuration management at > the base level before you can move into these areas. Are we making an > assumption that this effort is separate from those? It seems like that > may be the case where assessments of configurations is separate from > the management of configurations. If that assumption is being made, we > should state it clearly. >=20 > Thanks, > Kathleen >=20 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Waltermire, David A. > Sent: Tuesday, August 07, 2012 4:10 PM > To: Adam Montville; sacm@ietf.org > Subject: Re: [sacm] Using the Frame of Reference >=20 > Are your 5 aspects of SCM controls or activities? I would argue more > so that latter. I also like how you have broken down the different > "layers" of information for each of the 5 aspects. In my mind the > initial scope of this effort should focus on the "Observable Model" and > lower which I would interpret as being the data formats that describe > what is to be observed, how to observe it, and how to report those > observations. Things like tasking are the protocol bits to ensure that > the right observations are made and that the results are provided (or > not provided) to specific network components. >=20 > If we wanted to look further, we could then start into the Assessment > and Remediation models. >=20 > I would argue that "Configuration Assessment" might have a > "configuration compliance" model above "assessment" that would be a > peer to "vulnerability". This would put the configuration state in > context within the enterprise, just like the "vulnerability model" > does. >=20 > It is at the scoring/risk layer that we may want to tie-in control > frameworks. But what does this really mean? Does it mean that you are > demonstrating successful implementation of a control through the > collection of supporting data? Does it mean providing data that > indicates that the use of the control is effective in reducing security > exposure or risk? There are many other considerations as well. >=20 > It might be enough for this effort to ensure that the results from the > assessment/remediation model/layer is capable of being associated with > the controls they implement. This could be done through identifier > mapping, content references, or other methods. >=20 > Sincerely, > Dave >=20 >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam Montville > > Sent: Monday, August 06, 2012 9:08 PM > > To: sacm@ietf.org > > Subject: [sacm] Using the Frame of Reference > > > > All: > > > > Here's how I would envision using the frame of reference using > > Security Configuration Management (SCM) as an example. > > > > SCM is really five controls often assisted by technical toolsets > > (depending on who you ask, so this is just one perspective): > > > > 1. Configuration Assessment (password length is set to x) > > 2. Patch and Vulnerability Assessment (software package x is at > > version > > a.b.c) > > 3. Configuration Remediation (set password length to x) > > 4. Patch Remediation (bring software package x to at least version > > a.b.c) > > 5. Rate of Change (how are the files, registry entries, and other > > Settings changing over time > > > > Because asset management is critical to the success of these > controls, > > I assert that we should revisit what we have today in the way of > > models and where we need improvement (gaps or less than ideal > coverage). > > Appropriate asset models are required for each of SCM's constituent > > parts, as listed below. > > > > We might assert the following information model relationships: > > > > o Security Configuration Management is composed of > > o Configuration Assessment, which requires a/an > > - Asset Model (information/characterization) > > - Observable Model, > > - Assessment Model (checklists), > > - Scoring/Risk Model; > > o Patch and Vulnerability Assessment, which requires a/an > > - Asset Model, > > - Observable Model, > > - Assessment Model, > > - Vulnerability Model, > > - Scoring/Risk Model; > > o Configuration Remediation, which requires a/an > > - Asset Model, > > - Observable Model, > > - Remediation Model; > > o Patch Remediation, which requires a/an > > - Asset Model, > > - Observable Model, > > - Remediation Model. > > > > Note that some of the Supporting Concepts would be helpful here as > > well. > > Tasking/Workflow, is one example (consider assessing an endpoint, > > remediating, then reassessing). > > > > The Observable Model should be one that describes that which can be > > technically observed on an endpoint and which is able to provide > > contextual information with respect to that observable (either > > directly or through use of another model). For example, if I'm > > looking at a the Account Lockout Duration setting for a Windows > Server > > 2008 R2 machine Group Policy Object, then we should provide the means > > for content producers to include acceptable values for that > > configuration item, such that implementers using these specifications > > can provide guidance to their users with respect to that particular > setting. > > > > Something that seems lacking here is tying back to control frameworks > > (control in the ISO 27000/NIST 800-53 sense of the term). In the > case > > of SCM, we could use any number of the available control frameworks > to > > guide us. For example, the third SANS Top 20 Critical Control, > > "Secure Configurations for Hardware and Software on Laptops, > > Workstations, and Servers" might require one or more SCM constituents > as defined above. > > > > I'm particularly interested in this because it has been shown that, > to > > date, security automation efforts have been rather shotgun in their > > approach and have not necessarily done a good job ensuring that > > requirements derived from top-level scenarios are being satisfied. > > Also, knowing the exact needs of these controls can help us focus on > > what that which must be done, rather than upon that which could be > > done. > > > > Regards, > > > > Adam > > > > > > > > > > > > > > > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From mrex@sap.com Tue Aug 7 17:46:43 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B7B21F85E6 for ; Tue, 7 Aug 2012 17:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.85 X-Spam-Level: X-Spam-Status: No, score=-10.85 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSPci3eOle7q for ; Tue, 7 Aug 2012 17:46:42 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id EE50721F84CE for ; Tue, 7 Aug 2012 17:46:41 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q780kSFp009632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Aug 2012 02:46:37 +0200 (MEST) In-Reply-To: <00C069FD01E0324C9FFCADF539701DB30B910926@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer Date: Wed, 8 Aug 2012 02:46:27 +0200 (CEST) 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: <20120808004627.F107F1A12E@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "mrex@sap.com" , "sacm@ietf.org" , "anton@chuvakin.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: Wed, 08 Aug 2012 00:46:44 -0000 Michael Hammer wrote: > > In the U.S. so long as the employer explicitly points out to the user that > he is using the employers equipment, and that such use is for business > purposes only, and all other activity is prohibited, and that the employer > will be monitoring to ensure the employer's equipment is used for business > purposes only, it is in line with common business practice to do so. I'm aware of the almost complete lack of privacy protections in the US outside one's home as well as the lack of personality&privacy protections at the workplace. This concept is not universally transferable to legislations with data protection laws. Don't get me wrong here. This type of monitoring is OK and useful for servers and computers/devices with very dedicated purposes. But unconditional constant electronic surveillance of user behaviour and/or user data will be illegal in Germany for a personal computing equipment (workplace PC,Laptop,Tablet,Smartphone,...) that is used for telecommunications and a significant amount of the working time. Notices and orders by your employer can grant you additional rights, but they can not take away or restrict your constitutional rights. This could mean that for some workplaces the employer might have to install/provide two computing environments, one for telecommunications (Email,VoiP,IM,Internet-Browsing) and the other for access to highly sensitive data, which is _not_ used for telecommunications, so that the employer is permitted monitor the latter (but there are still limits, because profiling user behaviour will still be illegal without either formal statute law or probable cause). The seperate computing environments need not be distinct physical devices; depending on how it is set up, virtualization might be sufficient to provide two seperate computing environments, with one of them being completely excluded from unconditional monitoring of any user actions and user data. What many folks (and unfortunately still many labor lawyers and several entry-level labor court judges in Germany) still fail to understand, is that "for business purposes only" does *NOT* remove or restrict the individual's privacy rights for telecommunication *AT ALL*. That's an urban legend in Germany--admittely, one that is quite commonplace, but nevertheless unconstitutional and legally untenable. The German Federal Constitutional Court has decided this over a decade ago, and been repeating it in at least 4 rulings since then. The German Federal Labor Court has confirmed this (and the resulting inadmissibility as evidence) twice for voice telephone calls (that happened to be appealed that far). Other specific scenarios have not been appealed to the GFLC, but the GFCC ruling on which the GFLC decisions were based, are quite explicit that the constitutional protection applies to all non-public telecommunications alike (phone,fax,Email,SMS,IM), everywhere where the person is (the right protects the person), independent of the nature of the content, and independent of whether public or confidential information is communicated, and irrespective of the ownership of the telecommunication equipment that is used. GFCC decision 1 BvR 1611/96 (09-Oct-2002) > > This is just the online version of an employer noticing his employee > spending all his time reading Playboy at work and being on the phone talking > to his girlfriend, and telling him to get back to work. What would be "actionable" here in Germany is *NOT* each individual occurrence of any particular of these activities. What is actionable is when the combined amout of worktime that you spend on other things but working, and for which you still demand pay, exceeds the threshold of what is considered "socially acceptable". There are a number of activities which are not "productive", such as small-talk with colleagues, going to the rest-room, taking a break for smoking, getting some water or a coffee, whathaveyou. The employers control over what an employee does during unpaid overtime or during "socially acceptable" paid non-working time is limited. If an employee would be doing just occasional private online-banking (adding up to less than an hour per month), then it will often not be actionable even when the employer has an explicit policy Internet use for Business purposes only. (I'm aware that some lawyers and a few german entry level labor court have differing opinions, but none of these are based on facts&statutes. If there are two contrary court decisions, then matching them with decisions of the GFCC helps in distinguishing correct, questionable and invalid decisions. The issue at hand is constant electronic surveillance without probable cause. In Germany, that unconditionally requires a sufficiently precise "statutory foundation" by the parliamentarian legislator in order not to be illegal. The situation of employment is special, because the German legislator has placed an explicit obligation onto the employer to respect and protect the personal rights of his employees in Art. 75 (2) BetrVG: http://www.gesetze-im-internet.de/betrvg/__75.html How this applies to unconditional electronic surveillance can be seen in the decision of the German Federal Labour Court (GFLC) 1 ABR 21/03 (29-06-2004) http://lexetius.com/2004,2335#27 So even a loss (alleged/assumed theft) of 300 Letters&Parcels per month is a subsidiary of the postal services can NOT justify constant and unconditional CCTV surveillance at the workplace, even though each such theft is a felony, punishable with up to 5 years prison term. A successor attempt for CCTV surveillance 4 years later was found mostly acceptable by GFLC, because of the many safeguards&limitations that had been added to the procedures. Usage of any collected surveillance data was strictly limited to prosecuting crime, *NOT* for purpose of detecting non-compliance to any policies. > > Don't tell me that is permissible behavior in Germany. You're primarily asking the wrong questions and your reasoning/deduction on this issue is logically flawed. Having the "privilege" to define policies does not imply that there are no limits in the means you are permitted to enforce them. While requiring employees to work naked might be fairly effective in helping to reduce theft by employees. I assume that there are limits to what an employer can rightfully demand, even in the US. http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/10000/2000/800/12808/12808.strip.gif http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/10000/7000/100/17112/17112.strip.sunday.gif http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/20000/0000/900/20906/20906.strip.gif When looking at issues like this: http://blog.alexanderhiggins.com/2012/03/28/congress-decides-employers-demand-facebook-password-107972/ this send shivers down my spine. In Germany, there is no prerequisite of a criminal statute to make this illegal, because it is also unconstitutional. However, the european data protection directive (and its national incarnation in EU members states) will very likely apply, making this directly punishable--not just "cease and desist else get punished"-able. -Martin From mrex@sap.com Tue Aug 7 19:51:30 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F59021F859F for ; Tue, 7 Aug 2012 19:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.165 X-Spam-Level: X-Spam-Status: No, score=-10.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4yuGC5hCHHY for ; Tue, 7 Aug 2012 19:51:29 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7A43221F859A for ; Tue, 7 Aug 2012 19:51:28 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q782pQN4022077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Aug 2012 04:51:27 +0200 (MEST) In-Reply-To: To: Stephen Hanna Date: Wed, 8 Aug 2012 04:51:26 +0200 (CEST) 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: <20120808025126.913441A12E@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "mrex@sap.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: Wed, 08 Aug 2012 02:51:30 -0000 Stephen Hanna wrote: > > I am certainly no expert on European law in this area. And I can comment only on the situation in Germany. > > However, I will note that monitoring and auditing > corporate information systems and networks is common > practice in corporate environments. Generally, the > Acceptable Use Policy includes consent to monitoring > and audits. For example, look at the SANS template for > an Acceptable Use Policy available at > > http://www.sans.org/security-resources/policies/Acceptable_Use_Policy.pdf The monitoring of servers and dedicated devices is OK, the monitoring of data that is _not_ related to user activities/conduct is also OK, but the surveillance of user activities at the workplace of the users telecommunication and the user data resulting from that telecommunication is clearly illegal in Germany. I'm well aware that there is plenty of illegal activity commonplace in many companies in Germany, but that does not make them any less illegal. When the 1 ABR 21/03 (29-Jun-2004) decision about CCTV surveillance at the workplace was appealed to the German Federal Labour Court, the employer argued that were already performing CCTV surveillance in that fashion in 50 other subsidiaries (which for Germany means there have likely been _at_least_100_ labor lawyers involved in those other cases and found it non-objectionable), and two lower courts in this decision, but the German Federal Laber Court tore it to shreds with unprecedented explicit and clear determinations of why this activity was unconstitutional, quoting prior decisions of its own and decisions of the Constitutional Court. Therefore looking at the folklore on the aspect of electronic surveillance is a bad idea, because of the longstanding systemic error, that is evident from the GFLC decision 1 ABR 21/03. For the most part, that mess hasn't been cleaned up yet. Someone living in a jurisdiction based on case law may significantly underestimate the meaning&effect of that GFLC decision. After the Constitutional Court decision about the unconstitutionality of that particular video surveillance technology for traffic, there was a huge flurry of trials and appeals, and those appeals which made it all the way up (two even to the Constitutional Court), were quite obviously by clueless lawyers, who had not cared to actually read and comprehend the 4-page GFCC decision, or they would have immediately realized that their appeal are pointless (waste of time and money), because the two issues to which the GFCC had objected, had been fixed. > > In some environments (universities and libraries), > intellectual freedom may trump security in some cases. It is actually the other way round. In a company setting, the usage of a specific computer is typically not "voluntary" (i.e. you do not have to option to "not" use it, or to use your privately-owned equipment instead, in educational settings, specific pieces of equipment are not assigned to specific individuals over a long period of time, and in the educational setting Art. 75 (2) BetrVG does not apply, that requires employers to respect and protect employees personal rights. > > However, even universities generally include provisions > for monitoring when necessary. For example, here are a > few policies for universities in the USA, UK, and Germany: > > http://www.it.ufl.edu/policies/monitoring.html > http://www.admin.ox.ac.uk/statutes/regulations/196-052.shtml > http://www.cip.bv.tum.de/en/cippools-/termsofuse > > These policies were chosen at random, not deliberately > to support one point of view or another. But they are > remarkably similar in many respects. > > I observe that the Technical University of Munich permits > monitoring of user behavior and forensic analysis under > appropriate circumstances. > > So I conclude that the techniques and technologies for > monitoring user behavior and system configuration are > used around the world. As I said, it is a terrible bad idea to infer what is legal from the folklore, in particular for a jurisdication that is primarily based on statute law, not case law. I'm really glad that the two works councils of these two postal subsidiaries took their video surveillance issue up to the GFLC (1 ABR 21/03, 1 ABR 16/07), because the decisions are quite elaborate and directly applicable to all kinds of electronic surveillance (and that looks _very_ intentional). > > In the SACM group, we're talking about developing > technology that will help corporations to better secure > their computer systems and networks. I believe that there should be a distinction between two types of systems/devices, personal-use systems that may be subject to privacy protection, and backend,server and networking equipment, where this does not apply. > > We should carefully note the importance of maintaining balance > between user privacy and system security and obeying all > relevant laws, rules, and regulations. > However, it would be foolish for us to think that > we can come up with one policy that would apply in > all circumstances. Instead, we should permit system > and network owners to establish and implement their > own policies. At least, that's my point of view. Without the possibility to distinguish these two types of equipment, you will face the situation that products implementing this will not be usable in certain markets (German being one of them) once they are subjected to serious legal review, much like that particular unconstitutional traffic video surveillance equipment had to be updated/replaced all over Germany after the GFCC verdict, with the technical capability to limit surveillance to probable cause. -Martin From mrex@sap.com Tue Aug 7 20:33:57 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 6914E21F8568 for ; Tue, 7 Aug 2012 20:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.166 X-Spam-Level: X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYreC5yn9WTu for ; Tue, 7 Aug 2012 20:33:57 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id A4EB021F8566 for ; Tue, 7 Aug 2012 20:33:56 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q783XmFW008438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Aug 2012 05:33:53 +0200 (MEST) In-Reply-To: <5020F7C0.7020806@yaanatech.com> To: tony@yaanatech.com Date: Wed, 8 Aug 2012 05:33:47 +0200 (CEST) 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: <20120808033347.EF6481A12E@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: mrex@sap.com, sacm@ietf.org, Anton Chuvakin 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: Wed, 08 Aug 2012 03:33:57 -0000 Tony Rutkowski wrote: > > I am a lawyer and very familiar with the subject matter. Great! Simple Task: Tell me the name and article of the German statute that would authorize the constant electronic surveillance of all employees and without probable cause. I'm not aware of such a statute, but according to the legally binding decision of the German Federal Constitutional Court, such a statute is a prerequiste and it must be so clear that this statute applies to this situation that an average human being can understand it (otherwise that statutue would either not be applicable or unconstitutional). Over the past 6 years I've met a few labor lawyers, and whenever I asked them to back up their claims with statute & article, they completely chickened out. -Martin From david.oliva@verizon.net Wed Aug 8 07:22: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 9C0E111E8097 for ; Wed, 8 Aug 2012 07:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.167 X-Spam-Level: X-Spam-Status: No, score=-0.167 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHrdqMRfqzG1 for ; Wed, 8 Aug 2012 07:22:54 -0700 (PDT) Received: from vms173015pub.verizon.net (vms173015pub.verizon.net [206.46.173.15]) by ietfa.amsl.com (Postfix) with ESMTP id A64C821F861F for ; Wed, 8 Aug 2012 07:22:54 -0700 (PDT) Received: from vms170025pub.verizon.net ([unknown] [192.168.1.3]) by vms173015.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M8F000TFX8YSZ20@vms173015.mailsrvcs.net> for sacm@ietf.org; Wed, 08 Aug 2012 09:22:11 -0500 (CDT) Received: from 96.241.55.45 ([96.241.55.45]) by vms170025 (Verizon Webmail) with HTTP; Wed, 08 Aug 2012 09:22:10 -0500 (CDT) Date: Wed, 08 Aug 2012 09:22:10 -0500 (CDT) From: david.oliva@verizon.net To: lnunez@c3isecurity.com, sacm@ietf.org Message-id: <6905825.18402.1344435730391.JavaMail.root@vms170025> 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.55.45] Subject: [sacm] Strategic alignment of security with business in SACM in an international context X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 14:22:56 -0000
&nb= sp;

Luis and all:

Unless we can demonstrate that the technologies and specifications we are = developing align with the security objectives of international compliance m= odels (such as ISO 27001) we cannot demonstrate strategic alignment of busi= ness and security objectives in their context.  

Strategic alig= nment of security objectives with business objectives can be at least parti= ally joined via SACM thru the SP 800-53 to ISO 27001 mapping table.  If this were to happen to SACM then= the validated products will have less appeal and less marketability. The v= alidated products will work fine, but they will work with limited capabilit= y and scope.  For example, cu= rrently validated SCAP 1.0 products do not use the Open Checklist Interacti= ve Language (OCIL).   OC= IL is an open specification (created by the security community for use by a= nybody, any developer, any country) that facilitates non-automated assessme= nt of security processes.  OC= IL would allow an ISO 27001 compliance assessor in Germany to create a ques= tion =E2=80=9CDoes the organization comply ISO/IEC 27001:2005 para 4.2.2 e)= =E2=80=98Does the organization implement a training and awareness programm= e=E2=80=99=E2=80=9D and answer =E2=80=98yes=E2=80=99 or =E2=80=98no=E2=80= =99.  Then the results can be= accessed and read whether the organization uses product X or product Y bec= ause OCIL is an open security specification.  Another example of OCIL is a rather mundane security funct= ion of universal use.  OCIL a= llows an ISO 27001 security compliance officer to answer =E2=80=98yes=E2=80= =99 or =E2=80=98no=E2=80=99 to the question =E2=80=9CIs the door shut?=E2= =80=9D and make the result electronically readable whether he/she uses prod= uct X or product Y.  As for b= usiness, the flexibility of OCIL allows a company to create a question =E2= =80=9CDid the company reach our 7% profit strategic objective over the past= 10 years?=E2=80=9D and able to answer it =E2=80=98yes=E2=80=99 or =E2=80= =98no=E2=80=99 with product X, Y, or Z and ensure interoperability.

 

David = Oliva

 

 

 
 
On 08/07/12, Luis Nunez<lnunez@c3isecurity.= com> wrote:
 
Thanks the comment.  I am glad so= meone agrees with me :)

-ln

On A= ug 7, 2012, at 11:46 AM, david.oliva@verizon.net wrote:

 Luis and all:<= /DIV>
 
You are on target.

SACM i= s not a law enforcement thing, but is a facilitator of legal issues in asso= ciation with the protection of private information and health-related infor= mation.

I think a couple of examples to show = how SACM facilitates legal issues about personal information is in order.

A SACM configuration scanner is able to monito= r the configuration of security controls as specified in ISO/IEC 27001:2005= .  This can be accomplished w= hen tier IV SCAP content is used because the output maps the finding (compl= iance or non-compliance) of the scanner to security control ISO/IEC 27001:2= 005 paragraph A.10.6.2 =E2=80=9CSecurity of Network Services=E2=80=9D.  Thus a SACM scanner is able to a= ssist in international governance compliance about personal information bec= ause SP 800-53 maps to ISO 27001.

A SACM vuln= erability scanner is able to meet compliance with ISO 27001, para A.12.6.1 = =E2=80=9CControl of technical vulnerabilities=E2=80=9D because a SACM scann= er using SCAP tier IV content can map its output to the ISO governance.  SACM Vulnerability scanning can= address aspects of confidentiality of personal information by identifying = software vulnerabilities of the databases that house them, and do it in the= context of an international set of security standards.

&nb= sp;
David = Oliva
 
 
 = ;
= On 08/0= 6/12, Luis Nunez<lnunez@c3isecurity.com> wrote:
 
Looking at it another way I could see security automation as = a way to discover if a system is configured to meet privacy policies . &nbs= p;

Security automation is an enabler for transparency &n= bsp;so that individuals and organizations may understand the complex comput= ing environment.

Thanks for bring up this iss= ue.  As a community we may want to look at building content around pri= vacy controls.

-ln

On Aug = 6, 2012, at 12:42 PM, <Kent_Landfield@McAfee.com>= ; wrote:

None of the efforts we ar= e talking about for SACM are targeted toward PII or individuals. They are t= argeted at the configuration of the platforms deployed in the enterprise to= assure they comply with the site's security policy.  PII is not colle= cted. This is not monitoring of individual or employee actions.  I am = not a lawyer and will not speak as one. We will let the lawyer's decide at = the appropriate time.

Kent Landfield

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

From: Martin Rex <mrex@sap.com>
Reply-To: "mrex@sap.com" <= mrex@sap.com>
Date: = Monday, August 6, 2012 11:32 AM
To: "tony@yaanatech.com" <tony@yaanatech.com>
Cc: "mrex@sap.com= " <mrex@sap.com>, "sacm@ietf.org" <sacm@ietf= .org>
Subject: Re: [sacm= ] Legal aspects of System monitoring

Tony Rutkowski= wrote:
Martin Rex wrote:

In Germany, an employer monitorin= g a company-owned PC that an employee uses
for communication (EMa= il, VoiP, IM) would be unconditionally illegal.

=
Really?

No kidding!
<= DIV>


That is not consistent with comments
I've seen concerning German law.

There is a significant amount of mis-information floating the internet.
And a mindboggling large number of lawyers are making wild guesses= , rather
that doing research.

The decisi= ons of the german federal constitional court (GFCC) have been
qui= te consistent over the past decade about what with respect to
enc= roaching on the general right of personality, informational
self-= determination, freedom of conduct and created a "fundamental right
to the guarantee of the integrity and confidentiality of information
technology systems".  The court has set the minimum require= ments that
are prerequisite to such encroachment, such as the pre= requisite of a
clear formal statute law, which needs to be limite= d to situation where
real facts create probable cause.
=
The original GFCC decision in german language is quite compr= ehensible
(to me, at least), while I'm having some difficulties u= nderstanding
the english translation (and the english translation= is shorter!?).

BVerfG-Entscheidung "1 BvR 370/07 = vom 27.2.2008" Randnummer 196-
english translation of "1 BvR 370/07 vom 27.2.2008"


To be *uncond= itionally* illegal, would
preclude almost any rationally required=
maintenance or threat mitigation.

It is possible to perform maintenance and threat mitigation entirel= y
without "monitoring" systems.

A mere t= hreat is insufficient for monitoring, if that involves collecting
PII data, i.e. data from which a persons conduct can be infered.



It is fair to observe that recent German
Constitutional Court decisions impose
constraints, but the= y certainly are
not "unconditional."

<= /DIV>
One of the prerequisite is a clear formal statute law,
= which currently does not exist for the purposes "sacm" is about.
=
quoting from the above GFCC decision:

  2. The fundamental right to the guarantee of the confidentia= lity and
  integrity of information technology systems = is not unrestricted.
  Encroachments may be justified b= oth for preventive purposes, and for
  criminal prosecu= tion.  The individual must only accept such restrictions
  of his or her right which are based on a statutory foundation= that
  is constitutional.

This currently makes collecting data about peoples conduct "un= conditionally"
illegal for most practical purposes (exempting fro= m prosecution only
individual occasions of justified self-defence= against an imminent
vicious attack based on real facts that crea= te probable cause).

This applies to all surveillan= ce that impairs persons "freedom of conduct".
The majority of pas= t decisions of specific events was about surveillance
with a came= ra, but the GFCC decision makes it crystal clear that
this applie= s to *any* kind of surveillance.  Different to monitoring of
computer systems, there is statutory law for camera surveillance,
that allows optical surveillance under certain conditions
= (Art. 6b BDSG "BundesDatenSchutzGesetz).

The lack = of a formal statutory foundation makes surveillance illegal
and e= ntitles subjects to "cease and desist" rulings and sometimes
dama= ges.

In one more recent (and constitutionally corr= ect) rulings, an employer
had put up a camera that had in view no= t only the entrance door, but
also two workplaces.  The= employees protested against this camera,
but the employer would = not "fix" it, so at least one employee sued,
The court confirmed = that this camera surveillance at the workplace
was illegal due to= its chilling effect alone, and since it had been
installed for a= whole year, the employee was arwarded 4 month of income
as damag= es (for the chilling effect).

Another recent decis= ion was about evidence from a covert video
surveillance showing a= n employee taking a package of cigarettes
on two occasions, where= the German Federal Labour Court
(the supreme court for labor rel= ated issues) remanded the decision
to the trial court because it = had failed to establish whether the
covert video surveillance rea= lly met all constitutional prerequisites
otherwise the video surv= eillance would have been illegal and not
be admissible as evidenc= e in court.

The German Federal Constitional Court neutered numerous laws during= the
last decade due to lack of clarity and/or overbroad encroach= ment of
the personal right of self-determination and the right to= confidentiality
of telecommunications.

= See also the GFCC decision about the scanning of license plates
(= the decision 1 BvR 2074/05 vom 11.3.2008 in german)
http://www.bverfg.de/entscheidungen/rs20080311_1bvr2-07405.html

where it confirmed that data collection requires form= al statue law,
and that the law in question wasn't limited to pro= bable cause and
therefore unconstitutional.

<= DIV>
The only currently existing formal statue law in Germany= , that could be
used in some limited fashion for "Monitoring" is = Art.100 TKG,
but that statue is clearly limited in pu= rpose, it will not allow that data
to be used for automatic surve= illance of "employee conduct" with respect
to "company-defined po= licies".  Employers try hard to avoid TKG for their
net= works (for which they will have to formally register), but that also
<= DIV>means that they do not have a formal statutory law for performing any
kind of surveillance/monitoring as described in Art. 100 TKG for s= ystems
that are used by employees for telecommunications and a si= gnificant part
of their daily activies.

=
-Martin
__________________________________________= _____
sacm mailing list
ht= tps://www.ietf.org/mailman/listinfo/sacm

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



_______________________________________________
sa= cm mailing list
sacm@ietf.org
https://www.iet= f.org/mailman/listinfo/sacm

From tony@yaanatech.com Wed Aug 8 08:11: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 C9B9B11E80DC for ; Wed, 8 Aug 2012 08:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cbsv3WL8lbRE for ; Wed, 8 Aug 2012 08:11:40 -0700 (PDT) Received: from extmail1.prd.yaanatech.com (extmail1.prd.yaanatech.com [205.140.198.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3F64611E80D5 for ; Wed, 8 Aug 2012 08:11:40 -0700 (PDT) Received: from [192.168.0.4] (pool-173-72-150-118.clppva.fios.verizon.net [173.72.150.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extmail1.prd.yaanatech.com (Postfix) with ESMTP id F06CF58081; Wed, 8 Aug 2012 15:11:38 +0000 (UTC) Message-ID: <502281A9.8020800@yaanatech.com> Date: Wed, 08 Aug 2012 11:11:37 -0400 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: david.oliva@verizon.net References: <6905825.18402.1344435730391.JavaMail.root@vms170025> In-Reply-To: <6905825.18402.1344435730391.JavaMail.root@vms170025> Content-Type: multipart/alternative; boundary="------------010701030309050700090109" Cc: lnunez@c3isecurity.com, sacm@ietf.org Subject: Re: [sacm] Strategic alignment of security with business in SACM in an international context 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, 08 Aug 2012 15:11:41 -0000 This is a multi-part message in MIME format. --------------010701030309050700090109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi David, Could you provide a copy of ISO 27001 so we could take a look at it? --tony On 8/8/2012 10:22 AM, david.oliva@verizon.net wrote: > > Luis and all: > > Unless we can demonstrate that the technologies and specifications we > are developing align with the security objectives of international > compliance models (such as ISO 27001) we cannot demonstrate strategic > alignment of business and security objectives in their context. > --------------010701030309050700090109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi David,

Could you provide a copy of ISO 27001 so we could
take a look at it?

--tony

On 8/8/2012 10:22 AM, david.oliva@verizon.net wrote:

Luis and all:

Unless we can demonstrate that the technologies and specifications we are developing align with the security objectives of international compliance models (such as ISO 27001) we cannot demonstrate strategic alignment of business and security objectives in their context.  


--------------010701030309050700090109-- From krmaxwell@gmail.com Wed Aug 1 08:25: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 A51B621F8999; Wed, 1 Aug 2012 08:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YD4njBE0Sf1; Wed, 1 Aug 2012 08:25:47 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 881B521F8998; Wed, 1 Aug 2012 08:25:46 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4750749wgb.13 for ; Wed, 01 Aug 2012 08:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=kiuumhZtuUYkOXQbeWAJKmk2pgdkx/GTTFGj0bqLCJA=; b=OBX5G4xuF8+AmVLWvJahAKR+4Mgqk6wiw9L73mvehixFjJH2+dnEsYQwvn5bQA8Utm 7QFBd6ubpkMENGEcn4xcSaGpXeqawq8C3T6E2Lkj7fw9LmKwyLWJAciQuJZnOBQ2DwxK tCeM73jiUkInBs9RpIBFH3LUKCUrwdKAmu2g1cal0XWerzAH3bLH7vWoWjpMuySzbD4+ FHrIc/c4paVl7PbI/1FpHcjHfX3popkLfQl/FOPlC8wbMtEXjSMgksqZ6u+06RYU8aBB GVKIZd7LDe0DTFUTmIH7KsQyq8M2QHh8ndcwh8loHyN8SE76a62VMVxsQgdQrBq+7+4r 5P2Q== Received: by 10.216.101.1 with SMTP id a1mr8411594weg.216.1343834745434; Wed, 01 Aug 2012 08:25:45 -0700 (PDT) MIME-Version: 1.0 Sender: krmaxwell@gmail.com Received: by 10.194.13.67 with HTTP; Wed, 1 Aug 2012 08:25:25 -0700 (PDT) In-Reply-To: References: From: Kyle Maxwell Date: Wed, 1 Aug 2012 10:25:25 -0500 X-Google-Sender-Auth: 1MFVq97Rwf5EqK0Kz3YMS3X-WVg Message-ID: To: Luis Nunez Content-Type: multipart/alternative; boundary=e0cb4e6ffa29a3717f04c635e882 X-Mailman-Approved-At: Wed, 08 Aug 2012 08:19:57 -0700 Cc: mile@ietf.org, sacm@ietf.org Subject: Re: [sacm] [mile] VERIS X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 01 Aug 2012 15:25:47 -0000 --e0cb4e6ffa29a3717f04c635e882 Content-Type: text/plain; charset=ISO-8859-1 I'm on the VERIS team here at Verizon, so I can help answer any specific questions you might have. In a general sense, I don't believe VERIS and MILE really compete but are complementary to each other. On Wed, Aug 1, 2012 at 10:11 AM, Luis Nunez wrote: > Anyone familiar with Vocabulary for Event Recording and Incident Sharing > (VERIS)? Is this something that competes with MILE? or does it complement, > cooperate with existing efforts? > > Information sharing issues are on the rise and I would like to make sure > we are aware of the various efforts under way. We want to as a community > avoid duplication. > > > http://securityblog.verizonbusiness.com/2012/08/01/announcing-veriscommunity-net/ > > -- > Kyle Maxwell [ > kylem@xwell.org] > http://www.xwell.org > Twitter: @kylemaxwell > > --e0cb4e6ffa29a3717f04c635e882 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm on the VERIS team here at Verizon, so I can help answer any specifi= c questions you might have. In a general sense, I don't believe VERIS a= nd MILE really compete but are complementary to each other.=A0

On Wed, Aug 1, 2012 at 10:11 AM, Luis Nunez <lnunez@c3isecurity.com= > wrote:
Anyone familiar with Vocabulary for Event Recording and Incident Sharing (V= ERIS)? =A0Is this something that competes with MILE? or does it complement,= cooperate with existing efforts?

Information sharing issues are on the rise and I would like to make sure we= are aware of the various efforts under way. =A0We want to as a community a= void duplication.

http://securityblog.verizonbusiness.co= m/2012/08/01/announcing-veriscommunity-net/
--e0cb4e6ffa29a3717f04c635e882-- From solin@farnamhallventures.com Fri Aug 3 19:31:22 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 5C95A21E8037 for ; Fri, 3 Aug 2012 19:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0DMOPQBsRFU for ; Fri, 3 Aug 2012 19:31:21 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF3A21E8034 for ; Fri, 3 Aug 2012 19:31:21 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2190495obb.31 for ; Fri, 03 Aug 2012 19:31:20 -0700 (PDT) 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:content-transfer-encoding :x-gm-message-state; bh=BG+eMZ7P1cO8DaYLFDYdBOdchu1Bg1ffN39egKTMzIQ=; b=jwponN9WrzNQumaCgPqj3F2Q/qTwh6KQrbW5WSF/d8uMGKG0p8pNwva7nJDid3Fn/0 as1wqOYwjVWT2LDwxUn41Sprpeqf/oUauTVFRWLTklxn07feI3PMQMH7kzQmkBqUiTvx deeHsUZvnFosSlJxa8bWrhvGP4WEo6tXBsTQnzN1LpNVSs7PuCgxxQVgiTSbOXbFTDTE nPfFLD+petM6cARG74UBk02Ab5RJIyWKPOXgpgpX27fSwCK5qHv7RFShmdXyRtnBAZBj yqA+XPUvS7V7qXNgXMwjCXqXZhL7aSmCJ95rxQXy2LRDH2t3IvamAdO6z9QTNoKBS4Ao 5HoA== Received: by 10.182.131.73 with SMTP id ok9mr8729756obb.19.1344047480843; Fri, 03 Aug 2012 19:31:20 -0700 (PDT) Received: from [192.168.0.113] (cpe-70-123-137-202.austin.res.rr.com. [70.123.137.202]) by mx.google.com with ESMTPS id l10sm9149790oeb.13.2012.08.03.19.31.19 (version=SSLv3 cipher=OTHER); Fri, 03 Aug 2012 19:31:20 -0700 (PDT) Message-ID: <501C8972.20602@farnamhallventures.com> Date: Fri, 03 Aug 2012 21:31:14 -0500 From: David Solin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sacm@ietf.org References: <20120804021447.174991A119@ld9781.wdf.sap.corp> In-Reply-To: <20120804021447.174991A119@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlprwuwAoV4soybSu64uTgev7brRj7QCsQphs3i53rn7tMc8IaHkCpQmANwa/4ktH0pZOez X-Mailman-Approved-At: Wed, 08 Aug 2012 08:19:57 -0700 Subject: Re: [sacm] Legal aspects of System 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: Sat, 04 Aug 2012 02:31:22 -0000 This is about monitoring in a configuration compliance sense, not monitoring in a keyboard-logging sense. I am quite certain that there are many large companies in Europe that monitor configurations on company-owned machines that employees use for communication, because IBM, BMC, CA, HP, etc. all sell such products, widely, in Europe. Is there a specific regulation, and part of the document that concerns you? Personally, I think the word "monitoring" is a loaded term that, from the perspective of the market, has a meaning quite different from what we're talking about. But it's probably way too late to change it, since it's the "M" in SACM. Regards, --David Solin On 8/3/2012 9:14 PM, Martin Rex wrote: > A message on the DANE WG mailing list mentioned this WG and > the document http://www.ietf.org/id/draft-waltermire-sacm-use-cases-01.txt > > I have made a first read of the document and I'm wondering whether > people on this list are aware of the legal issues such an idea creates. > > In Germany, an employer monitoring a company-owned PC that an employee uses > for communication (EMail, VoiP, IM) would be unconditionally illegal. > > -Martin > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From sturner-rice@tripwire.com Tue Aug 7 08:19: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 BB2CF21F8744 for ; Tue, 7 Aug 2012 08:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dM89SL-aX0Bt for ; Tue, 7 Aug 2012 08:19:46 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id A43A321F8740 for ; Tue, 7 Aug 2012 08:19:46 -0700 (PDT) Received: from mail133-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Tue, 7 Aug 2012 15:19:46 +0000 Received: from mail133-ch1 (localhost [127.0.0.1]) by mail133-ch1-R.bigfish.com (Postfix) with ESMTP id 2630C1002D0; Tue, 7 Aug 2012 15:19:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zz9371I542M4015Izz1202hzz1033IL8275bh8275dh5eeeKz2dh2a8h668h839h944hd25hf0ah107ah) Received: from mail133-ch1 (localhost.localdomain [127.0.0.1]) by mail133-ch1 (MessageSwitch) id 1344352784434870_22216; Tue, 7 Aug 2012 15:19:44 +0000 (UTC) Received: from CH1EHSMHS002.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail133-ch1.bigfish.com (Postfix) with ESMTP id 65EB94001E3; Tue, 7 Aug 2012 15:19:44 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by CH1EHSMHS002.bigfish.com (10.43.70.2) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 7 Aug 2012 15:19:42 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 7 Aug 2012 08:21:42 -0700 Received: from PDXMB01.tripwire.com ([fe80::215f:56b3:8a1f:78ba]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Tue, 7 Aug 2012 08:19:41 -0700 From: Shawna Turner-Rice To: Stephen Hanna , "mrex@sap.com" Thread-Topic: [sacm] Legal aspects of System monitoring Thread-Index: AQHNdE6vmMRYoag7x0aaZ9LAfo4gO5dOqLYA///OwOA= Date: Tue, 7 Aug 2012 15:19:41 +0000 Message-ID: <5FEE9A77CD8E96479CA5D5760B9AA8296D71BC@PDXMB01.tripwire.com> References: <502018FA.20603@yaanatech.com> <20120807034236.D32801A126@ld9781.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.2.55] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com X-Mailman-Approved-At: Wed, 08 Aug 2012 08:19:57 -0700 Cc: "sacm@ietf.org" Subject: Re: [sacm] Legal aspects of System 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, 07 Aug 2012 15:20:40 -0000 +1 on: We should carefully note the importance of maintaining balance betwe= en user privacy and system security and obeying all relevant laws, rules, a= nd regulations. However, it would be foolish for us to think that we can come up with one p= olicy that would apply in all circumstances. Instead, we should permit syst= em and network owners to establish and implement their own policies. -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ste= phen Hanna Sent: Tuesday, August 07, 2012 4:16 AM To: mrex@sap.com Cc: sacm@ietf.org Subject: Re: [sacm] Legal aspects of System monitoring I am certainly no expert on European law in this area. However, I will note that monitoring and auditing corporate information sys= tems and networks is common practice in corporate environments. Generally, = the Acceptable Use Policy includes consent to monitoring and audits. For ex= ample, look at the SANS template for an Acceptable Use Policy available at http://www.sans.org/security-resources/policies/Acceptable_Use_Policy.pdf In some environments (universities and libraries), intellectual freedom may= trump security in some cases. However, even universities generally include provisions for monitoring when= necessary. For example, here are a few policies for universities in the US= A, UK, and Germany: http://www.it.ufl.edu/policies/monitoring.html http://www.admin.ox.ac.uk/statutes/regulations/196-052.shtml http://www.cip.bv.tum.de/en/cippools-/termsofuse These policies were chosen at random, not deliberately to support one point= of view or another. But they are remarkably similar in many respects. I observe that the Technical University of Munich permits monitoring of use= r behavior and forensic analysis under appropriate circumstances. So I conclude that the techniques and technologies for monitoring user beha= vior and system configuration are used around the world. However, there is = a constant balance between user privacy and system security. The nature of = this balance may vary depending on the jurisdiction and on the application = (military networks vs. corporate vs. university vs. home). There's a nice d= iscussion of this balance in the (ISC)2 Guide to the CISSP CBK (Second Edit= ion) on pages 516 and 517. In the SACM group, we're talking about developing technology that will help= corporations to better secure their computer systems and networks. We shou= ld carefully note the importance of maintaining balance between user privac= y and system security and obeying all relevant laws, rules, and regulations= . However, it would be foolish for us to think that we can come up with one p= olicy that would apply in all circumstances. Instead, we should permit syst= em and network owners to establish and implement their own policies. At lea= st, that's my point of view. Thanks, Steve _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From amontville@tripwire.com Wed Aug 8 09:12:01 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4349921F8702 for ; Wed, 8 Aug 2012 09:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.286 X-Spam-Level: X-Spam-Status: No, score=-5.286 tagged_above=-999 required=5 tests=[AWL=1.313, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDp5SeC+n8oI for ; Wed, 8 Aug 2012 09:12:00 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id B451621F8701 for ; Wed, 8 Aug 2012 09:12:00 -0700 (PDT) Received: from mail242-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Wed, 8 Aug 2012 16:12:00 +0000 Received: from mail242-tx2 (localhost [127.0.0.1]) by mail242-tx2-R.bigfish.com (Postfix) with ESMTP id 5180B4001F5; Wed, 8 Aug 2012 16:12:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1202hzz8275ch8275bhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail242-tx2 (localhost.localdomain [127.0.0.1]) by mail242-tx2 (MessageSwitch) id 1344442318595695_31466; Wed, 8 Aug 2012 16:11:58 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.237]) by mail242-tx2.bigfish.com (Postfix) with ESMTP id 7CA8C3A00FA; Wed, 8 Aug 2012 16:11:58 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 8 Aug 2012 16:11:57 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 8 Aug 2012 09:13:56 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Wed, 8 Aug 2012 09:11:56 -0700 From: Adam Montville To: "tony@yaanatech.com" , "david.oliva@verizon.net" Thread-Topic: [sacm] Strategic alignment of security with business in SACM in an international context Thread-Index: AQHNdXFuQ7kczokuL0ey76Mefxnp0JdQequA//+bgQA= Date: Wed, 8 Aug 2012 16:11:55 +0000 Message-ID: In-Reply-To: <502281A9.8020800@yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Cc: "lnunez@c3isecurity.com" , "sacm@ietf.org" Subject: Re: [sacm] Strategic alignment of security with business in SACM in an international context X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:12:01 -0000 On 8/8/12 8:11 AM, "Tony Rutkowski" wrote: >Hi David, > >Could you provide a copy of ISO 27001 so we could >take a look at it? I have a copy, but it's restricted to my use only. I believe most distributions might be that way. > >--tony > >On 8/8/2012 10:22 AM, >david.oliva@verizon.net wrote: > > >Luis and all: >Unless we can demonstrate that the technologies and specifications we are >developing align with the security objectives of international compliance >models (such as ISO 27001) > we cannot demonstrate strategic alignment of business and security >objectives in their context. >=20 > > > > From david.waltermire@nist.gov Wed Aug 8 09:38:01 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E78F21E8034 for ; Wed, 8 Aug 2012 09:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y24V2amalz4K for ; Wed, 8 Aug 2012 09:37:58 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id A85F211E8109 for ; Wed, 8 Aug 2012 09:37:49 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 8 Aug 2012 12:37:10 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 8 Aug 2012 12:36:03 -0400 From: "Waltermire, David A." To: "david.oliva@verizon.net" , "lnunez@c3isecurity.com" , "sacm@ietf.org" Date: Wed, 8 Aug 2012 12:37:25 -0400 Thread-Topic: [sacm] Strategic alignment of security with business in SACM in an international context Thread-Index: Ac11cS43CEhxzk28RF2VTDkwBf113wAEVOaQ Message-ID: References: <6905825.18402.1344435730391.JavaMail.root@vms170025> In-Reply-To: <6905825.18402.1344435730391.JavaMail.root@vms170025> 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_D7A0423E5E193F40BE6E94126930C4930BA00EA975MBCLUSTERxcha_" MIME-Version: 1.0 Subject: Re: [sacm] Strategic alignment of security with business in SACM in an international context X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:38:01 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930BA00EA975MBCLUSTERxcha_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGNoYWxsZW5nZSB3ZSB3aWxsIGxpa2VseSBmYWNlIGluIHNjb3BpbmcgZG93biB0aGUgZWZm b3J0IGlzIHRoYXQgd2UgbWlnaHQgbm90IGJlIGFibGUgdG8gd29yayBvbiB0aGUgZnVsbCBzdGFj ayB0aGF0IHN1cHBvcnRzIGxvdy1sZXZlbCBkYXRhIGNvbGxlY3Rpb24sIGFzIHdlbGwgYXMgaGln aGVyIGxldmVsIHNlY3VyaXR5IHByb2Nlc3NlcyBhbmQgY29udHJvbHMuICBUaGlzIGlzIGJlY2F1 c2Ugd2Ugd2lsbCBsaWtlbHkgbmVlZCB0byBjaGFydGVyIGFyb3VuZCBhIGxvd2VyIGxheWVyIG9m IGZ1bmN0aW9uLiAgVGhpcyBpcyB3aHkgd2UgbmVlZCB0byBzY29wZSBhcyBwYXJ0IG9mIHRoaXMg d29yayBhbiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgdGhhdCBpbGx1c3RyYXRlcyBob3cgdGhlIHNt YWxsZXIgc2NvcGUgb2Ygd29yayBmaXRzIGludG8gdGhlIGxhcmdlciBwaWN0dXJlIHRoYXQgc3Vw cG9ydHMgYWxpZ25tZW50IHdpdGggaW50ZXJuYXRpb25hbCBjb21wbGlhbmNlIG1vZGVscy4NCg0K VG8gc2F5IGl0IGEgZGlmZmVyZW50IHdheSwgd2UgbmVlZCB0byBkZWZpbmUgYSBjb21wcmVoZW5z aXZlIHBpY3R1cmUgb2YgdGhlIOKAnGVuZCBzdGF0ZeKAnSwgZXZlbiB0aG91Z2ggd2UgbWF5IG9u bHkgZ2V0IHBhcnQgd2F5IHRoZXJlIGJhc2VkIG9uIGFuIGluaXRpYWwgU0FDTSBjaGFydGVyLg0K DQpXZSBjYW4gdXNlIGRvY3VtZW50cyBsaWtlIElTTyAyNzAwMSBhcyBndWlkYW5jZSBpbiBwcm9k dWNpbmcgdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCB0byBpbnN1cmUgdGhhdCB0aGUgZW5kIHN0 YXRlIGFsaWducyB3ZWxsIHdpdGggeW91ciBjb25jZXJucyBiZWxvdy4NCg0KU2luY2VyZWx5LA0K RGF2ZQ0KDQpGcm9tOiBzYWNtLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzYWNtLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldA0KU2VudDogV2Vk bmVzZGF5LCBBdWd1c3QgMDgsIDIwMTIgMTA6MjIgQU0NClRvOiBsbnVuZXpAYzNpc2VjdXJpdHku Y29tOyBzYWNtQGlldGYub3JnDQpTdWJqZWN0OiBbc2FjbV0gU3RyYXRlZ2ljIGFsaWdubWVudCBv ZiBzZWN1cml0eSB3aXRoIGJ1c2luZXNzIGluIFNBQ00gaW4gYW4gaW50ZXJuYXRpb25hbCBjb250 ZXh0DQoNCg0KTHVpcyBhbmQgYWxsOg0KVW5sZXNzIHdlIGNhbiBkZW1vbnN0cmF0ZSB0aGF0IHRo ZSB0ZWNobm9sb2dpZXMgYW5kIHNwZWNpZmljYXRpb25zIHdlIGFyZSBkZXZlbG9waW5nIGFsaWdu IHdpdGggdGhlIHNlY3VyaXR5IG9iamVjdGl2ZXMgb2YgaW50ZXJuYXRpb25hbCBjb21wbGlhbmNl IG1vZGVscyAoc3VjaCBhcyBJU08gMjcwMDEpIHdlIGNhbm5vdCBkZW1vbnN0cmF0ZSBzdHJhdGVn aWMgYWxpZ25tZW50IG9mIGJ1c2luZXNzIGFuZCBzZWN1cml0eSBvYmplY3RpdmVzIGluIHRoZWly IGNvbnRleHQuDQpTdHJhdGVnaWMgYWxpZ25tZW50IG9mIHNlY3VyaXR5IG9iamVjdGl2ZXMgd2l0 aCBidXNpbmVzcyBvYmplY3RpdmVzIGNhbiBiZSBhdCBsZWFzdCBwYXJ0aWFsbHkgam9pbmVkIHZp YSBTQUNNIHRocnUgdGhlIFNQIDgwMC01MyB0byBJU08gMjcwMDEgbWFwcGluZyB0YWJsZS4gIElm IHRoaXMgd2VyZSB0byBoYXBwZW4gdG8gU0FDTSB0aGVuIHRoZSB2YWxpZGF0ZWQgcHJvZHVjdHMg d2lsbCBoYXZlIGxlc3MgYXBwZWFsIGFuZCBsZXNzIG1hcmtldGFiaWxpdHkuIFRoZSB2YWxpZGF0 ZWQgcHJvZHVjdHMgd2lsbCB3b3JrIGZpbmUsIGJ1dCB0aGV5IHdpbGwgd29yayB3aXRoIGxpbWl0 ZWQgY2FwYWJpbGl0eSBhbmQgc2NvcGUuICBGb3IgZXhhbXBsZSwgY3VycmVudGx5IHZhbGlkYXRl ZCBTQ0FQIDEuMCBwcm9kdWN0cyBkbyBub3QgdXNlIHRoZSBPcGVuIENoZWNrbGlzdCBJbnRlcmFj dGl2ZSBMYW5ndWFnZSAoT0NJTCkuICAgT0NJTCBpcyBhbiBvcGVuIHNwZWNpZmljYXRpb24gKGNy ZWF0ZWQgYnkgdGhlIHNlY3VyaXR5IGNvbW11bml0eSBmb3IgdXNlIGJ5IGFueWJvZHksIGFueSBk ZXZlbG9wZXIsIGFueSBjb3VudHJ5KSB0aGF0IGZhY2lsaXRhdGVzIG5vbi1hdXRvbWF0ZWQgYXNz ZXNzbWVudCBvZiBzZWN1cml0eSBwcm9jZXNzZXMuICBPQ0lMIHdvdWxkIGFsbG93IGFuIElTTyAy NzAwMSBjb21wbGlhbmNlIGFzc2Vzc29yIGluIEdlcm1hbnkgdG8gY3JlYXRlIGEgcXVlc3Rpb24g 4oCcRG9lcyB0aGUgb3JnYW5pemF0aW9uIGNvbXBseSBJU08vSUVDIDI3MDAxOjIwMDUgcGFyYSA0 LjIuMiBlKSDigJhEb2VzIHRoZSBvcmdhbml6YXRpb24gaW1wbGVtZW50IGEgdHJhaW5pbmcgYW5k IGF3YXJlbmVzcyBwcm9ncmFtbWXigJnigJ0gYW5kIGFuc3dlciDigJh5ZXPigJkgb3Ig4oCYbm/i gJkuICBUaGVuIHRoZSByZXN1bHRzIGNhbiBiZSBhY2Nlc3NlZCBhbmQgcmVhZCB3aGV0aGVyIHRo ZSBvcmdhbml6YXRpb24gdXNlcyBwcm9kdWN0IFggb3IgcHJvZHVjdCBZIGJlY2F1c2UgT0NJTCBp cyBhbiBvcGVuIHNlY3VyaXR5IHNwZWNpZmljYXRpb24uICBBbm90aGVyIGV4YW1wbGUgb2YgT0NJ TCBpcyBhIHJhdGhlciBtdW5kYW5lIHNlY3VyaXR5IGZ1bmN0aW9uIG9mIHVuaXZlcnNhbCB1c2Uu ICBPQ0lMIGFsbG93cyBhbiBJU08gMjcwMDEgc2VjdXJpdHkgY29tcGxpYW5jZSBvZmZpY2VyIHRv IGFuc3dlciDigJh5ZXPigJkgb3Ig4oCYbm/igJkgdG8gdGhlIHF1ZXN0aW9uIOKAnElzIHRoZSBk b29yIHNodXQ/4oCdIGFuZCBtYWtlIHRoZSByZXN1bHQgZWxlY3Ryb25pY2FsbHkgcmVhZGFibGUg d2hldGhlciBoZS9zaGUgdXNlcyBwcm9kdWN0IFggb3IgcHJvZHVjdCBZLiAgQXMgZm9yIGJ1c2lu ZXNzLCB0aGUgZmxleGliaWxpdHkgb2YgT0NJTCBhbGxvd3MgYSBjb21wYW55IHRvIGNyZWF0ZSBh IHF1ZXN0aW9uIOKAnERpZCB0aGUgY29tcGFueSByZWFjaCBvdXIgNyUgcHJvZml0IHN0cmF0ZWdp YyBvYmplY3RpdmUgb3ZlciB0aGUgcGFzdCAxMCB5ZWFycz/igJ0gYW5kIGFibGUgdG8gYW5zd2Vy IGl0IOKAmHllc+KAmSBvciDigJhub+KAmSB3aXRoIHByb2R1Y3QgWCwgWSwgb3IgWiBhbmQgZW5z dXJlIGludGVyb3BlcmFiaWxpdHkuDQoNCkRhdmlkIE9saXZhDQoNCg0KDQpPbiAwOC8wNy8xMiwg THVpcyBOdW5lejxsbnVuZXpAYzNpc2VjdXJpdHkuY29tPG1haWx0bzpsbnVuZXpAYzNpc2VjdXJp dHkuY29tPj4gd3JvdGU6DQoNClRoYW5rcyB0aGUgY29tbWVudC4gIEkgYW0gZ2xhZCBzb21lb25l IGFncmVlcyB3aXRoIG1lIDopDQoNCi1sbg0KDQpPbiBBdWcgNywgMjAxMiwgYXQgMTE6NDYgQU0s IGRhdmlkLm9saXZhQHZlcml6b24ubmV0PG1haWx0bzpkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldD4g d3JvdGU6DQoNCg0KIEx1aXMgYW5kIGFsbDoNCg0KWW91IGFyZSBvbiB0YXJnZXQuDQpTQUNNIGlz IG5vdCBhIGxhdyBlbmZvcmNlbWVudCB0aGluZywgYnV0IGlzIGEgZmFjaWxpdGF0b3Igb2YgbGVn YWwgaXNzdWVzIGluIGFzc29jaWF0aW9uIHdpdGggdGhlIHByb3RlY3Rpb24gb2YgcHJpdmF0ZSBp bmZvcm1hdGlvbiBhbmQgaGVhbHRoLXJlbGF0ZWQgaW5mb3JtYXRpb24uDQpJIHRoaW5rIGEgY291 cGxlIG9mIGV4YW1wbGVzIHRvIHNob3cgaG93IFNBQ00gZmFjaWxpdGF0ZXMgbGVnYWwgaXNzdWVz IGFib3V0IHBlcnNvbmFsIGluZm9ybWF0aW9uIGlzIGluIG9yZGVyLg0KQSBTQUNNIGNvbmZpZ3Vy YXRpb24gc2Nhbm5lciBpcyBhYmxlIHRvIG1vbml0b3IgdGhlIGNvbmZpZ3VyYXRpb24gb2Ygc2Vj dXJpdHkgY29udHJvbHMgYXMgc3BlY2lmaWVkIGluIElTTy9JRUMgMjcwMDE6MjAwNS4gIFRoaXMg Y2FuIGJlIGFjY29tcGxpc2hlZCB3aGVuIHRpZXIgSVYgU0NBUCBjb250ZW50IGlzIHVzZWQgYmVj YXVzZSB0aGUgb3V0cHV0IG1hcHMgdGhlIGZpbmRpbmcgKGNvbXBsaWFuY2Ugb3Igbm9uLWNvbXBs aWFuY2UpIG9mIHRoZSBzY2FubmVyIHRvIHNlY3VyaXR5IGNvbnRyb2wgSVNPL0lFQyAyNzAwMToy MDA1IHBhcmFncmFwaCBBLjEwLjYuMiDigJxTZWN1cml0eSBvZiBOZXR3b3JrIFNlcnZpY2Vz4oCd LiAgVGh1cyBhIFNBQ00gc2Nhbm5lciBpcyBhYmxlIHRvIGFzc2lzdCBpbiBpbnRlcm5hdGlvbmFs IGdvdmVybmFuY2UgY29tcGxpYW5jZSBhYm91dCBwZXJzb25hbCBpbmZvcm1hdGlvbiBiZWNhdXNl IFNQIDgwMC01MyBtYXBzIHRvIElTTyAyNzAwMS4NCkEgU0FDTSB2dWxuZXJhYmlsaXR5IHNjYW5u ZXIgaXMgYWJsZSB0byBtZWV0IGNvbXBsaWFuY2Ugd2l0aCBJU08gMjcwMDEsIHBhcmEgQS4xMi42 LjEg4oCcQ29udHJvbCBvZiB0ZWNobmljYWwgdnVsbmVyYWJpbGl0aWVz4oCdIGJlY2F1c2UgYSBT QUNNIHNjYW5uZXIgdXNpbmcgU0NBUCB0aWVyIElWIGNvbnRlbnQgY2FuIG1hcCBpdHMgb3V0cHV0 IHRvIHRoZSBJU08gZ292ZXJuYW5jZS4gIFNBQ00gVnVsbmVyYWJpbGl0eSBzY2FubmluZyBjYW4g YWRkcmVzcyBhc3BlY3RzIG9mIGNvbmZpZGVudGlhbGl0eSBvZiBwZXJzb25hbCBpbmZvcm1hdGlv biBieSBpZGVudGlmeWluZyBzb2Z0d2FyZSB2dWxuZXJhYmlsaXRpZXMgb2YgdGhlIGRhdGFiYXNl cyB0aGF0IGhvdXNlIHRoZW0sIGFuZCBkbyBpdCBpbiB0aGUgY29udGV4dCBvZiBhbiBpbnRlcm5h dGlvbmFsIHNldCBvZiBzZWN1cml0eSBzdGFuZGFyZHMuDQoNCkRhdmlkIE9saXZhDQoNCg0KDQpP biAwOC8wNi8xMiwgTHVpcyBOdW5lejxsbnVuZXpAYzNpc2VjdXJpdHkuY29tPG1haWx0bzpsbnVu ZXpAYzNpc2VjdXJpdHkuY29tPj4gd3JvdGU6DQoNCkxvb2tpbmcgYXQgaXQgYW5vdGhlciB3YXkg SSBjb3VsZCBzZWUgc2VjdXJpdHkgYXV0b21hdGlvbiBhcyBhIHdheSB0byBkaXNjb3ZlciBpZiBh IHN5c3RlbSBpcyBjb25maWd1cmVkIHRvIG1lZXQgcHJpdmFjeSBwb2xpY2llcyAuDQoNClNlY3Vy aXR5IGF1dG9tYXRpb24gaXMgYW4gZW5hYmxlciBmb3IgdHJhbnNwYXJlbmN5ICBzbyB0aGF0IGlu ZGl2aWR1YWxzIGFuZCBvcmdhbml6YXRpb25zIG1heSB1bmRlcnN0YW5kIHRoZSBjb21wbGV4IGNv bXB1dGluZyBlbnZpcm9ubWVudC4NCg0KVGhhbmtzIGZvciBicmluZyB1cCB0aGlzIGlzc3VlLiAg QXMgYSBjb21tdW5pdHkgd2UgbWF5IHdhbnQgdG8gbG9vayBhdCBidWlsZGluZyBjb250ZW50IGFy b3VuZCBwcml2YWN5IGNvbnRyb2xzLg0KDQotbG4NCg0KT24gQXVnIDYsIDIwMTIsIGF0IDEyOjQy IFBNLCA8S2VudF9MYW5kZmllbGRATWNBZmVlLmNvbTxtYWlsdG86S2VudF9MYW5kZmllbGRATWNB ZmVlLmNvbT4+IHdyb3RlOg0KDQoNCk5vbmUgb2YgdGhlIGVmZm9ydHMgd2UgYXJlIHRhbGtpbmcg YWJvdXQgZm9yIFNBQ00gYXJlIHRhcmdldGVkIHRvd2FyZCBQSUkgb3IgaW5kaXZpZHVhbHMuIFRo ZXkgYXJlIHRhcmdldGVkIGF0IHRoZSBjb25maWd1cmF0aW9uIG9mIHRoZSBwbGF0Zm9ybXMgZGVw bG95ZWQgaW4gdGhlIGVudGVycHJpc2UgdG8gYXNzdXJlIHRoZXkgY29tcGx5IHdpdGggdGhlIHNp dGUncyBzZWN1cml0eSBwb2xpY3kuICBQSUkgaXMgbm90IGNvbGxlY3RlZC4gVGhpcyBpcyBub3Qg bW9uaXRvcmluZyBvZiBpbmRpdmlkdWFsIG9yIGVtcGxveWVlIGFjdGlvbnMuICBJIGFtIG5vdCBh IGxhd3llciBhbmQgd2lsbCBub3Qgc3BlYWsgYXMgb25lLiBXZSB3aWxsIGxldCB0aGUgbGF3eWVy J3MgZGVjaWRlIGF0IHRoZSBhcHByb3ByaWF0ZSB0aW1lLg0KDQpLZW50IExhbmRmaWVsZA0KDQpN Y0FmZWUgfCBBbiBJbnRlbCBDb21wYW55DQpEaXJlY3Q6ICsxLjk3Mi45NjMuNzA5Ng0KTW9iaWxl OiArMS44MTcuNjM3LjgwMjYNCldlYjogd3d3Lm1jYWZlZS5jb208aHR0cDovL3d3dy5tY2FmZWUu Y29tLz4NCg0KRnJvbTogTWFydGluIFJleCA8bXJleEBzYXAuY29tPG1haWx0bzptcmV4QHNhcC5j b20+Pg0KUmVwbHktVG86ICJtcmV4QHNhcC5jb208bWFpbHRvOm1yZXhAc2FwLmNvbT4iIDxtcmV4 QHNhcC5jb208bWFpbHRvOm1yZXhAc2FwLmNvbT4+DQpEYXRlOiBNb25kYXksIEF1Z3VzdCA2LCAy MDEyIDExOjMyIEFNDQpUbzogInRvbnlAeWFhbmF0ZWNoLmNvbTxtYWlsdG86dG9ueUB5YWFuYXRl Y2guY29tPiIgPHRvbnlAeWFhbmF0ZWNoLmNvbTxtYWlsdG86dG9ueUB5YWFuYXRlY2guY29tPj4N CkNjOiAibXJleEBzYXAuY29tPG1haWx0bzptcmV4QHNhcC5jb20+IiA8bXJleEBzYXAuY29tPG1h aWx0bzptcmV4QHNhcC5jb20+PiwgInNhY21AaWV0Zi5vcmc8bWFpbHRvOnNhY21AaWV0Zi5vcmc+ IiA8c2FjbUBpZXRmLm9yZzxtYWlsdG86c2FjbUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3Nh Y21dIExlZ2FsIGFzcGVjdHMgb2YgU3lzdGVtIG1vbml0b3JpbmcNCg0KVG9ueSBSdXRrb3dza2kg d3JvdGU6DQpNYXJ0aW4gUmV4IHdyb3RlOg0KDQpJbiBHZXJtYW55LCBhbiBlbXBsb3llciBtb25p dG9yaW5nIGEgY29tcGFueS1vd25lZCBQQyB0aGF0IGFuIGVtcGxveWVlIHVzZXMNCmZvciBjb21t dW5pY2F0aW9uIChFTWFpbCwgVm9pUCwgSU0pIHdvdWxkIGJlIHVuY29uZGl0aW9uYWxseSBpbGxl Z2FsLg0KDQpSZWFsbHk/DQoNCk5vIGtpZGRpbmchDQoNCg0KDQpUaGF0IGlzIG5vdCBjb25zaXN0 ZW50IHdpdGggY29tbWVudHMNCkkndmUgc2VlbiBjb25jZXJuaW5nIEdlcm1hbiBsYXcuDQoNClRo ZXJlIGlzIGEgc2lnbmlmaWNhbnQgYW1vdW50IG9mIG1pcy1pbmZvcm1hdGlvbiBmbG9hdGluZyB0 aGUgaW50ZXJuZXQuDQpBbmQgYSBtaW5kYm9nZ2xpbmcgbGFyZ2UgbnVtYmVyIG9mIGxhd3llcnMg YXJlIG1ha2luZyB3aWxkIGd1ZXNzZXMsIHJhdGhlcg0KdGhhdCBkb2luZyByZXNlYXJjaC4NCg0K VGhlIGRlY2lzaW9ucyBvZiB0aGUgZ2VybWFuIGZlZGVyYWwgY29uc3RpdGlvbmFsIGNvdXJ0IChH RkNDKSBoYXZlIGJlZW4NCnF1aXRlIGNvbnNpc3RlbnQgb3ZlciB0aGUgcGFzdCBkZWNhZGUgYWJv dXQgd2hhdCB3aXRoIHJlc3BlY3QgdG8NCmVuY3JvYWNoaW5nIG9uIHRoZSBnZW5lcmFsIHJpZ2h0 IG9mIHBlcnNvbmFsaXR5LCBpbmZvcm1hdGlvbmFsDQpzZWxmLWRldGVybWluYXRpb24sIGZyZWVk b20gb2YgY29uZHVjdCBhbmQgY3JlYXRlZCBhICJmdW5kYW1lbnRhbCByaWdodA0KdG8gdGhlIGd1 YXJhbnRlZSBvZiB0aGUgaW50ZWdyaXR5IGFuZCBjb25maWRlbnRpYWxpdHkgb2YgaW5mb3JtYXRp b24NCnRlY2hub2xvZ3kgc3lzdGVtcyIuICBUaGUgY291cnQgaGFzIHNldCB0aGUgbWluaW11bSBy ZXF1aXJlbWVudHMgdGhhdA0KYXJlIHByZXJlcXVpc2l0ZSB0byBzdWNoIGVuY3JvYWNobWVudCwg c3VjaCBhcyB0aGUgcHJlcmVxdWlzaXRlIG9mIGENCmNsZWFyIGZvcm1hbCBzdGF0dXRlIGxhdywg d2hpY2ggbmVlZHMgdG8gYmUgbGltaXRlZCB0byBzaXR1YXRpb24gd2hlcmUNCnJlYWwgZmFjdHMg Y3JlYXRlIHByb2JhYmxlIGNhdXNlLg0KDQpUaGUgb3JpZ2luYWwgR0ZDQyBkZWNpc2lvbiBpbiBn ZXJtYW4gbGFuZ3VhZ2UgaXMgcXVpdGUgY29tcHJlaGVuc2libGUNCih0byBtZSwgYXQgbGVhc3Qp LCB3aGlsZSBJJ20gaGF2aW5nIHNvbWUgZGlmZmljdWx0aWVzIHVuZGVyc3RhbmRpbmcNCnRoZSBl bmdsaXNoIHRyYW5zbGF0aW9uIChhbmQgdGhlIGVuZ2xpc2ggdHJhbnNsYXRpb24gaXMgc2hvcnRl ciE/KS4NCg0KQlZlcmZHLUVudHNjaGVpZHVuZyAiMSBCdlIgMzcwLzA3IHZvbSAyNy4yLjIwMDgi IFJhbmRudW1tZXIgMTk2LQ0KaHR0cDovL3d3dy5idmVyZmcuZGUvZW50c2NoZWlkdW5nZW4vcnMy MDA4MDIyN18xYnZyMDM3MDA3Lmh0bWwjYWJzMTk2DQoNCmVuZ2xpc2ggdHJhbnNsYXRpb24gb2Yg IjEgQnZSIDM3MC8wNyB2b20gMjcuMi4yMDA4Ig0KaHR0cDovL3d3dy5idmVyZmcuZGUvZW50c2No ZWlkdW5nZW4vcnMyMDA4MDIyN18xYnZyMDM3MDA3ZW4uaHRtbCNhYnMxMzANCg0KDQpUbyBiZSAq dW5jb25kaXRpb25hbGx5KiBpbGxlZ2FsLCB3b3VsZA0KcHJlY2x1ZGUgYWxtb3N0IGFueSByYXRp b25hbGx5IHJlcXVpcmVkDQptYWludGVuYW5jZSBvciB0aHJlYXQgbWl0aWdhdGlvbi4NCg0KSXQg aXMgcG9zc2libGUgdG8gcGVyZm9ybSBtYWludGVuYW5jZSBhbmQgdGhyZWF0IG1pdGlnYXRpb24g ZW50aXJlbHkNCndpdGhvdXQgIm1vbml0b3JpbmciIHN5c3RlbXMuDQoNCkEgbWVyZSB0aHJlYXQg aXMgaW5zdWZmaWNpZW50IGZvciBtb25pdG9yaW5nLCBpZiB0aGF0IGludm9sdmVzIGNvbGxlY3Rp bmcNClBJSSBkYXRhLCBpLmUuIGRhdGEgZnJvbSB3aGljaCBhIHBlcnNvbnMgY29uZHVjdCBjYW4g YmUgaW5mZXJlZC4NCg0KDQoNCkl0IGlzIGZhaXIgdG8gb2JzZXJ2ZSB0aGF0IHJlY2VudCBHZXJt YW4NCkNvbnN0aXR1dGlvbmFsIENvdXJ0IGRlY2lzaW9ucyBpbXBvc2UNCmNvbnN0cmFpbnRzLCBi dXQgdGhleSBjZXJ0YWlubHkgYXJlDQpub3QgInVuY29uZGl0aW9uYWwuIg0KDQpPbmUgb2YgdGhl IHByZXJlcXVpc2l0ZSBpcyBhIGNsZWFyIGZvcm1hbCBzdGF0dXRlIGxhdywNCndoaWNoIGN1cnJl bnRseSBkb2VzIG5vdCBleGlzdCBmb3IgdGhlIHB1cnBvc2VzICJzYWNtIiBpcyBhYm91dC4NCg0K cXVvdGluZyBmcm9tIHRoZSBhYm92ZSBHRkNDIGRlY2lzaW9uOg0KDQogIDIuIFRoZSBmdW5kYW1l bnRhbCByaWdodCB0byB0aGUgZ3VhcmFudGVlIG9mIHRoZSBjb25maWRlbnRpYWxpdHkgYW5kDQog IGludGVncml0eSBvZiBpbmZvcm1hdGlvbiB0ZWNobm9sb2d5IHN5c3RlbXMgaXMgbm90IHVucmVz dHJpY3RlZC4NCiAgRW5jcm9hY2htZW50cyBtYXkgYmUganVzdGlmaWVkIGJvdGggZm9yIHByZXZl bnRpdmUgcHVycG9zZXMsIGFuZCBmb3INCiAgY3JpbWluYWwgcHJvc2VjdXRpb24uICBUaGUgaW5k aXZpZHVhbCBtdXN0IG9ubHkgYWNjZXB0IHN1Y2ggcmVzdHJpY3Rpb25zDQogIG9mIGhpcyBvciBo ZXIgcmlnaHQgd2hpY2ggYXJlIGJhc2VkIG9uIGEgc3RhdHV0b3J5IGZvdW5kYXRpb24gdGhhdA0K ICBpcyBjb25zdGl0dXRpb25hbC4NCg0KDQpUaGlzIGN1cnJlbnRseSBtYWtlcyBjb2xsZWN0aW5n IGRhdGEgYWJvdXQgcGVvcGxlcyBjb25kdWN0ICJ1bmNvbmRpdGlvbmFsbHkiDQppbGxlZ2FsIGZv ciBtb3N0IHByYWN0aWNhbCBwdXJwb3NlcyAoZXhlbXB0aW5nIGZyb20gcHJvc2VjdXRpb24gb25s eQ0KaW5kaXZpZHVhbCBvY2Nhc2lvbnMgb2YganVzdGlmaWVkIHNlbGYtZGVmZW5jZSBhZ2FpbnN0 IGFuIGltbWluZW50DQp2aWNpb3VzIGF0dGFjayBiYXNlZCBvbiByZWFsIGZhY3RzIHRoYXQgY3Jl YXRlIHByb2JhYmxlIGNhdXNlKS4NCg0KVGhpcyBhcHBsaWVzIHRvIGFsbCBzdXJ2ZWlsbGFuY2Ug dGhhdCBpbXBhaXJzIHBlcnNvbnMgImZyZWVkb20gb2YgY29uZHVjdCIuDQpUaGUgbWFqb3JpdHkg b2YgcGFzdCBkZWNpc2lvbnMgb2Ygc3BlY2lmaWMgZXZlbnRzIHdhcyBhYm91dCBzdXJ2ZWlsbGFu Y2UNCndpdGggYSBjYW1lcmEsIGJ1dCB0aGUgR0ZDQyBkZWNpc2lvbiBtYWtlcyBpdCBjcnlzdGFs IGNsZWFyIHRoYXQNCnRoaXMgYXBwbGllcyB0byAqYW55KiBraW5kIG9mIHN1cnZlaWxsYW5jZS4g IERpZmZlcmVudCB0byBtb25pdG9yaW5nIG9mDQpjb21wdXRlciBzeXN0ZW1zLCB0aGVyZSBpcyBz dGF0dXRvcnkgbGF3IGZvciBjYW1lcmEgc3VydmVpbGxhbmNlLA0KdGhhdCBhbGxvd3Mgb3B0aWNh bCBzdXJ2ZWlsbGFuY2UgdW5kZXIgY2VydGFpbiBjb25kaXRpb25zDQooQXJ0LiA2YiBCRFNHICJC dW5kZXNEYXRlblNjaHV0ekdlc2V0eikuDQoNClRoZSBsYWNrIG9mIGEgZm9ybWFsIHN0YXR1dG9y eSBmb3VuZGF0aW9uIG1ha2VzIHN1cnZlaWxsYW5jZSBpbGxlZ2FsDQphbmQgZW50aXRsZXMgc3Vi amVjdHMgdG8gImNlYXNlIGFuZCBkZXNpc3QiIHJ1bGluZ3MgYW5kIHNvbWV0aW1lcw0KZGFtYWdl cy4NCg0KSW4gb25lIG1vcmUgcmVjZW50IChhbmQgY29uc3RpdHV0aW9uYWxseSBjb3JyZWN0KSBy dWxpbmdzLCBhbiBlbXBsb3llcg0KaGFkIHB1dCB1cCBhIGNhbWVyYSB0aGF0IGhhZCBpbiB2aWV3 IG5vdCBvbmx5IHRoZSBlbnRyYW5jZSBkb29yLCBidXQNCmFsc28gdHdvIHdvcmtwbGFjZXMuICBU aGUgZW1wbG95ZWVzIHByb3Rlc3RlZCBhZ2FpbnN0IHRoaXMgY2FtZXJhLA0KYnV0IHRoZSBlbXBs b3llciB3b3VsZCBub3QgImZpeCIgaXQsIHNvIGF0IGxlYXN0IG9uZSBlbXBsb3llZSBzdWVkLA0K VGhlIGNvdXJ0IGNvbmZpcm1lZCB0aGF0IHRoaXMgY2FtZXJhIHN1cnZlaWxsYW5jZSBhdCB0aGUg d29ya3BsYWNlDQp3YXMgaWxsZWdhbCBkdWUgdG8gaXRzIGNoaWxsaW5nIGVmZmVjdCBhbG9uZSwg YW5kIHNpbmNlIGl0IGhhZCBiZWVuDQppbnN0YWxsZWQgZm9yIGEgd2hvbGUgeWVhciwgdGhlIGVt cGxveWVlIHdhcyBhcndhcmRlZCA0IG1vbnRoIG9mIGluY29tZQ0KYXMgZGFtYWdlcyAoZm9yIHRo ZSBjaGlsbGluZyBlZmZlY3QpLg0KDQpBbm90aGVyIHJlY2VudCBkZWNpc2lvbiB3YXMgYWJvdXQg ZXZpZGVuY2UgZnJvbSBhIGNvdmVydCB2aWRlbw0Kc3VydmVpbGxhbmNlIHNob3dpbmcgYW4gZW1w bG95ZWUgdGFraW5nIGEgcGFja2FnZSBvZiBjaWdhcmV0dGVzDQpvbiB0d28gb2NjYXNpb25zLCB3 aGVyZSB0aGUgR2VybWFuIEZlZGVyYWwgTGFib3VyIENvdXJ0DQoodGhlIHN1cHJlbWUgY291cnQg Zm9yIGxhYm9yIHJlbGF0ZWQgaXNzdWVzKSByZW1hbmRlZCB0aGUgZGVjaXNpb24NCnRvIHRoZSB0 cmlhbCBjb3VydCBiZWNhdXNlIGl0IGhhZCBmYWlsZWQgdG8gZXN0YWJsaXNoIHdoZXRoZXIgdGhl DQpjb3ZlcnQgdmlkZW8gc3VydmVpbGxhbmNlIHJlYWxseSBtZXQgYWxsIGNvbnN0aXR1dGlvbmFs IHByZXJlcXVpc2l0ZXMNCm90aGVyd2lzZSB0aGUgdmlkZW8gc3VydmVpbGxhbmNlIHdvdWxkIGhh dmUgYmVlbiBpbGxlZ2FsIGFuZCBub3QNCmJlIGFkbWlzc2libGUgYXMgZXZpZGVuY2UgaW4gY291 cnQuDQooR2VybWFuIGRlY2lzaW9uOiBodHRwOi8vbGV4ZXRpdXMuY29tLzIwMTIsMjM1MSkNCg0K VGhlIEdlcm1hbiBGZWRlcmFsIENvbnN0aXRpb25hbCBDb3VydCBuZXV0ZXJlZCBudW1lcm91cyBs YXdzIGR1cmluZyB0aGUNCmxhc3QgZGVjYWRlIGR1ZSB0byBsYWNrIG9mIGNsYXJpdHkgYW5kL29y IG92ZXJicm9hZCBlbmNyb2FjaG1lbnQgb2YNCnRoZSBwZXJzb25hbCByaWdodCBvZiBzZWxmLWRl dGVybWluYXRpb24gYW5kIHRoZSByaWdodCB0byBjb25maWRlbnRpYWxpdHkNCm9mIHRlbGVjb21t dW5pY2F0aW9ucy4NCg0KU2VlIGFsc28gdGhlIEdGQ0MgZGVjaXNpb24gYWJvdXQgdGhlIHNjYW5u aW5nIG9mIGxpY2Vuc2UgcGxhdGVzDQoodGhlIGRlY2lzaW9uIDEgQnZSIDIwNzQvMDUgdm9tIDEx LjMuMjAwOCBpbiBnZXJtYW4pDQpodHRwOi8vd3d3LmJ2ZXJmZy5kZS9lbnRzY2hlaWR1bmdlbi9y czIwMDgwMzExXzFidnIyLTA3NDA1Lmh0bWwNCg0Kd2hlcmUgaXQgY29uZmlybWVkIHRoYXQgZGF0 YSBjb2xsZWN0aW9uIHJlcXVpcmVzIGZvcm1hbCBzdGF0dWUgbGF3LA0KYW5kIHRoYXQgdGhlIGxh dyBpbiBxdWVzdGlvbiB3YXNuJ3QgbGltaXRlZCB0byBwcm9iYWJsZSBjYXVzZSBhbmQNCnRoZXJl Zm9yZSB1bmNvbnN0aXR1dGlvbmFsLg0KDQoNClRoZSBvbmx5IGN1cnJlbnRseSBleGlzdGluZyBm b3JtYWwgc3RhdHVlIGxhdyBpbiBHZXJtYW55LCB0aGF0IGNvdWxkIGJlDQp1c2VkIGluIHNvbWUg bGltaXRlZCBmYXNoaW9uIGZvciAiTW9uaXRvcmluZyIgaXMgQXJ0LjEwMCBUS0csDQogIGh0dHA6 Ly93d3cuZ2VzZXR6ZS1pbS1pbnRlcm5ldC5kZS90a2dfMjAwNC9fXzEwMC5odG1sDQpidXQgdGhh dCBzdGF0dWUgaXMgY2xlYXJseSBsaW1pdGVkIGluIHB1cnBvc2UsIGl0IHdpbGwgbm90IGFsbG93 IHRoYXQgZGF0YQ0KdG8gYmUgdXNlZCBmb3IgYXV0b21hdGljIHN1cnZlaWxsYW5jZSBvZiAiZW1w bG95ZWUgY29uZHVjdCIgd2l0aCByZXNwZWN0DQp0byAiY29tcGFueS1kZWZpbmVkIHBvbGljaWVz Ii4gIEVtcGxveWVycyB0cnkgaGFyZCB0byBhdm9pZCBUS0cgZm9yIHRoZWlyDQpuZXR3b3JrcyAo Zm9yIHdoaWNoIHRoZXkgd2lsbCBoYXZlIHRvIGZvcm1hbGx5IHJlZ2lzdGVyKSwgYnV0IHRoYXQg YWxzbw0KbWVhbnMgdGhhdCB0aGV5IGRvIG5vdCBoYXZlIGEgZm9ybWFsIHN0YXR1dG9yeSBsYXcg Zm9yIHBlcmZvcm1pbmcgYW55DQpraW5kIG9mIHN1cnZlaWxsYW5jZS9tb25pdG9yaW5nIGFzIGRl c2NyaWJlZCBpbiBBcnQuIDEwMCBUS0cgZm9yIHN5c3RlbXMNCnRoYXQgYXJlIHVzZWQgYnkgZW1w bG95ZWVzIGZvciB0ZWxlY29tbXVuaWNhdGlvbnMgYW5kIGEgc2lnbmlmaWNhbnQgcGFydA0Kb2Yg dGhlaXIgZGFpbHkgYWN0aXZpZXMuDQoNCg0KLU1hcnRpbg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnNhY20gbWFpbGluZyBsaXN0DQpzYWNtQGlldGYu b3JnPG1haWx0bzpzYWNtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zYWNtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpzYWNtIG1haWxpbmcgbGlzdA0Kc2FjbUBpZXRmLm9yZzxtYWlsdG86c2FjbUBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbQ0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpzYWNtIG1haWxpbmcgbGlzdA0Kc2FjbUBpZXRmLm9y ZzxtYWlsdG86c2FjbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2FjbQ0KDQo= --_000_D7A0423E5E193F40BE6E94126930C4930BA00EA975MBCLUSTERxcha_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJ e21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJw bGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+VGhlIGNoYWxsZW5nZSB3ZSB3aWxsIGxpa2VseSBmYWNlIGluIHNjb3Bpbmcg ZG93biB0aGUgZWZmb3J0IGlzIHRoYXQgd2UgbWlnaHQgbm90IGJlIGFibGUgdG8gd29yayBvbiB0 aGUgZnVsbCBzdGFjayB0aGF0IHN1cHBvcnRzIGxvdy1sZXZlbCBkYXRhIGNvbGxlY3Rpb24sIGFz IHdlbGwgYXMgaGlnaGVyIGxldmVsIHNlY3VyaXR5IHByb2Nlc3NlcyBhbmQgY29udHJvbHMuwqAg VGhpcyBpcyBiZWNhdXNlIHdlIHdpbGwgbGlrZWx5IG5lZWQgdG8gY2hhcnRlciBhcm91bmQgYSBs b3dlciBsYXllciBvZiBmdW5jdGlvbi7CoCBUaGlzIGlzIHdoeSB3ZSBuZWVkIHRvIHNjb3BlIGFz IHBhcnQgb2YgdGhpcyB3b3JrIGFuIGFyY2hpdGVjdHVyZSBkb2N1bWVudCB0aGF0IGlsbHVzdHJh dGVzIGhvdyB0aGUgc21hbGxlciBzY29wZSBvZiB3b3JrIGZpdHMgaW50byB0aGUgbGFyZ2VyIHBp Y3R1cmUgdGhhdCBzdXBwb3J0cyBhbGlnbm1lbnQgd2l0aCBpbnRlcm5hdGlvbmFsIGNvbXBsaWFu Y2UgbW9kZWxzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VG8gc2F5IGl0IGEgZGlmZmVyZW50IHdheSwg d2UgbmVlZCB0byBkZWZpbmUgYSBjb21wcmVoZW5zaXZlIHBpY3R1cmUgb2YgdGhlIOKAnGVuZCBz dGF0ZeKAnSwgZXZlbiB0aG91Z2ggd2UgbWF5IG9ubHkgZ2V0IHBhcnQgd2F5IHRoZXJlIGJhc2Vk IG9uIGFuIGluaXRpYWwgU0FDTSBjaGFydGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2UgY2FuIHVz ZSBkb2N1bWVudHMgbGlrZSBJU08gMjcwMDEgYXMgZ3VpZGFuY2UgaW4gcHJvZHVjaW5nIHRoZSBh cmNoaXRlY3R1cmUgZG9jdW1lbnQgdG8gaW5zdXJlIHRoYXQgdGhlIGVuZCBzdGF0ZSBhbGlnbnMg d2VsbCB3aXRoIHlvdXIgY29uY2VybnMgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5TaW5jZXJl bHksPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkRhdmU8L3NwYW4+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9 TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IHNhY20tYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9m IDwvYj5kYXZpZC5vbGl2YUB2ZXJpem9uLm5ldDxicj48Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBB dWd1c3QgMDgsIDIwMTIgMTA6MjIgQU08YnI+PGI+VG86PC9iPiBsbnVuZXpAYzNpc2VjdXJpdHku Y29tOyBzYWNtQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBbc2FjbV0gU3RyYXRlZ2ljIGFs aWdubWVudCBvZiBzZWN1cml0eSB3aXRoIGJ1c2luZXNzIGluIFNBQ00gaW4gYW4gaW50ZXJuYXRp b25hbCBjb250ZXh0PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTAuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+THVpcyBhbmQgYWxsOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0 b206MTAuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjpibGFjayc+VW5sZXNzIHdlIGNhbiBkZW1vbnN0cmF0ZSB0aGF0IHRoZSB0ZWNobm9s b2dpZXMgYW5kIHNwZWNpZmljYXRpb25zIHdlIGFyZSBkZXZlbG9waW5nIGFsaWduIHdpdGggdGhl IHNlY3VyaXR5IG9iamVjdGl2ZXMgb2YgaW50ZXJuYXRpb25hbCBjb21wbGlhbmNlIG1vZGVscyAo c3VjaCBhcyBJU08gMjcwMDEpIHdlIGNhbm5vdCBkZW1vbnN0cmF0ZSBzdHJhdGVnaWMgYWxpZ25t ZW50IG9mIGJ1c2luZXNzIGFuZCBzZWN1cml0eSBvYmplY3RpdmVzIGluIHRoZWlyIGNvbnRleHQu wqAgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWJvdHRvbToxMC4wcHQnPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOmJsYWNrJz5TdHJhdGVnaWMgYWxpZ25tZW50IG9mIHNlY3VyaXR5IG9iamVj dGl2ZXMgd2l0aCBidXNpbmVzcyBvYmplY3RpdmVzIGNhbiBiZSBhdCBsZWFzdCBwYXJ0aWFsbHkg am9pbmVkIHZpYSBTQUNNIHRocnUgdGhlIFNQIDgwMC01MyB0byBJU08gMjcwMDEgbWFwcGluZyB0 YWJsZS7CoCBJZiB0aGlzIHdlcmUgdG8gaGFwcGVuIHRvIFNBQ00gdGhlbiB0aGUgdmFsaWRhdGVk IHByb2R1Y3RzIHdpbGwgaGF2ZSBsZXNzIGFwcGVhbCBhbmQgbGVzcyBtYXJrZXRhYmlsaXR5LiBU aGUgdmFsaWRhdGVkIHByb2R1Y3RzIHdpbGwgd29yayBmaW5lLCBidXQgdGhleSB3aWxsIHdvcmsg d2l0aCBsaW1pdGVkIGNhcGFiaWxpdHkgYW5kIHNjb3BlLsKgIEZvciBleGFtcGxlLCBjdXJyZW50 bHkgdmFsaWRhdGVkIFNDQVAgMS4wIHByb2R1Y3RzIGRvIG5vdCB1c2UgdGhlIE9wZW4gQ2hlY2ts aXN0IEludGVyYWN0aXZlIExhbmd1YWdlIChPQ0lMKS7CoMKgIE9DSUwgaXMgYW4gb3BlbiBzcGVj aWZpY2F0aW9uIChjcmVhdGVkIGJ5IHRoZSBzZWN1cml0eSBjb21tdW5pdHkgZm9yIHVzZSBieSBh bnlib2R5LCBhbnkgZGV2ZWxvcGVyLCBhbnkgY291bnRyeSkgdGhhdCBmYWNpbGl0YXRlcyBub24t YXV0b21hdGVkIGFzc2Vzc21lbnQgb2Ygc2VjdXJpdHkgcHJvY2Vzc2VzLsKgIE9DSUwgd291bGQg YWxsb3cgYW4gSVNPIDI3MDAxIGNvbXBsaWFuY2UgYXNzZXNzb3IgaW4gR2VybWFueSB0byBjcmVh dGUgYSBxdWVzdGlvbiDigJxEb2VzIHRoZSBvcmdhbml6YXRpb24gY29tcGx5IElTTy9JRUMgMjcw MDE6MjAwNSBwYXJhIDQuMi4yIGUpIOKAmERvZXMgdGhlIG9yZ2FuaXphdGlvbiBpbXBsZW1lbnQg YSB0cmFpbmluZyBhbmQgYXdhcmVuZXNzIHByb2dyYW1tZeKAmeKAnSBhbmQgYW5zd2VyIOKAmHll c+KAmSBvciDigJhub+KAmS7CoCBUaGVuIHRoZSByZXN1bHRzIGNhbiBiZSBhY2Nlc3NlZCBhbmQg cmVhZCB3aGV0aGVyIHRoZSBvcmdhbml6YXRpb24gdXNlcyBwcm9kdWN0IFggb3IgcHJvZHVjdCBZ IGJlY2F1c2UgT0NJTCBpcyBhbiBvcGVuIHNlY3VyaXR5IHNwZWNpZmljYXRpb24uwqAgQW5vdGhl ciBleGFtcGxlIG9mIE9DSUwgaXMgYSByYXRoZXIgbXVuZGFuZSBzZWN1cml0eSBmdW5jdGlvbiBv ZiB1bml2ZXJzYWwgdXNlLsKgIE9DSUwgYWxsb3dzIGFuIElTTyAyNzAwMSBzZWN1cml0eSBjb21w bGlhbmNlIG9mZmljZXIgdG8gYW5zd2VyIOKAmHllc+KAmSBvciDigJhub+KAmSB0byB0aGUgcXVl c3Rpb24g4oCcSXMgdGhlIGRvb3Igc2h1dD/igJ0gYW5kIG1ha2UgdGhlIHJlc3VsdCBlbGVjdHJv bmljYWxseSByZWFkYWJsZSB3aGV0aGVyIGhlL3NoZSB1c2VzIHByb2R1Y3QgWCBvciBwcm9kdWN0 IFkuwqAgQXMgZm9yIGJ1c2luZXNzLCB0aGUgZmxleGliaWxpdHkgb2YgT0NJTCBhbGxvd3MgYSBj b21wYW55IHRvIGNyZWF0ZSBhIHF1ZXN0aW9uIOKAnERpZCB0aGUgY29tcGFueSByZWFjaCBvdXIg NyUgcHJvZml0IHN0cmF0ZWdpYyBvYmplY3RpdmUgb3ZlciB0aGUgcGFzdCAxMCB5ZWFycz/igJ0g YW5kIGFibGUgdG8gYW5zd2VyIGl0IOKAmHllc+KAmSBvciDigJhub+KAmSB3aXRoIHByb2R1Y3Qg WCwgWSwgb3IgWiBhbmQgZW5zdXJlIGludGVyb3BlcmFiaWxpdHkuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMC4wcHQnPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMC4wcHQnPjxzcGFuIHN0eWxlPSdmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5EYXZpZCBPbGl2YTxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0 b206MTAuMHB0Jz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTAuMHB0Jz48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFj ayc+IDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5PbiAwOC8wNy8xMiwgTHVpcyBOdW5leiZsdDs8YSBo cmVmPSJtYWlsdG86bG51bmV6QGMzaXNlY3VyaXR5LmNvbSI+bG51bmV6QGMzaXNlY3VyaXR5LmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+VGhhbmtzIHRoZSBjb21t ZW50LiAmbmJzcDtJIGFtIGdsYWQgc29tZW9uZSBhZ3JlZXMgd2l0aCBtZSA6KTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjpibGFjayc+LWxuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPk9uIEF1ZyA3 LCAyMDEyLCBhdCAxMTo0NiBBTSwgPGEgaHJlZj0ibWFpbHRvOmRhdmlkLm9saXZhQHZlcml6b24u bmV0IiB0YXJnZXQ9Il9ibGFuayI+ZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ8L2E+IHdyb3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpi bGFjayc+PGJyPjxicj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDtMdWlzIGFuZCBhbGw6PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2sn PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOmJsYWNrJz5Zb3UgYXJlIG9uIHRhcmdldC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTAu MHB0Jz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjpibGFjayc+U0FDTSBpcyBub3QgYSBsYXcgZW5mb3JjZW1lbnQgdGhpbmcsIGJ1dCBpcyBhIGZh Y2lsaXRhdG9yIG9mIGxlZ2FsIGlzc3VlcyBpbiBhc3NvY2lhdGlvbiB3aXRoIHRoZSBwcm90ZWN0 aW9uIG9mIHByaXZhdGUgaW5mb3JtYXRpb24gYW5kIGhlYWx0aC1yZWxhdGVkIGluZm9ybWF0aW9u Ljwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTAuMHB0Jz48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+SSB0aGlu ayBhIGNvdXBsZSBvZiBleGFtcGxlcyB0byBzaG93IGhvdyBTQUNNIGZhY2lsaXRhdGVzIGxlZ2Fs IGlzc3VlcyBhYm91dCBwZXJzb25hbCBpbmZvcm1hdGlvbiBpcyBpbiBvcmRlci48L3NwYW4+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEwLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkEgU0FDTSBjb25maWd1cmF0 aW9uIHNjYW5uZXIgaXMgYWJsZSB0byBtb25pdG9yIHRoZSBjb25maWd1cmF0aW9uIG9mIHNlY3Vy aXR5IGNvbnRyb2xzIGFzIHNwZWNpZmllZCBpbiBJU08vSUVDIDI3MDAxOjIwMDUuwqAgVGhpcyBj YW4gYmUgYWNjb21wbGlzaGVkIHdoZW4gdGllciBJViBTQ0FQIGNvbnRlbnQgaXMgdXNlZCBiZWNh dXNlIHRoZSBvdXRwdXQgbWFwcyB0aGUgZmluZGluZyAoY29tcGxpYW5jZSBvciBub24tY29tcGxp YW5jZSkgb2YgdGhlIHNjYW5uZXIgdG8gc2VjdXJpdHkgY29udHJvbCBJU08vSUVDIDI3MDAxOjIw MDUgcGFyYWdyYXBoIEEuMTAuNi4yIOKAnFNlY3VyaXR5IG9mIE5ldHdvcmsgU2VydmljZXPigJ0u wqAgVGh1cyBhIFNBQ00gc2Nhbm5lciBpcyBhYmxlIHRvIGFzc2lzdCBpbiBpbnRlcm5hdGlvbmFs IGdvdmVybmFuY2UgY29tcGxpYW5jZSBhYm91dCBwZXJzb25hbCBpbmZvcm1hdGlvbiBiZWNhdXNl IFNQIDgwMC01MyBtYXBzIHRvIElTTyAyNzAwMS48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tYm90dG9tOjEwLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6YmxhY2snPkEgU0FDTSB2dWxuZXJhYmlsaXR5IHNjYW5uZXIgaXMgYWJs ZSB0byBtZWV0IGNvbXBsaWFuY2Ugd2l0aCBJU08gMjcwMDEsIHBhcmEgQS4xMi42LjEg4oCcQ29u dHJvbCBvZiB0ZWNobmljYWwgdnVsbmVyYWJpbGl0aWVz4oCdIGJlY2F1c2UgYSBTQUNNIHNjYW5u ZXIgdXNpbmcgU0NBUCB0aWVyIElWIGNvbnRlbnQgY2FuIG1hcCBpdHMgb3V0cHV0IHRvIHRoZSBJ U08gZ292ZXJuYW5jZS7CoCBTQUNNIFZ1bG5lcmFiaWxpdHkgc2Nhbm5pbmcgY2FuIGFkZHJlc3Mg YXNwZWN0cyBvZiBjb25maWRlbnRpYWxpdHkgb2YgcGVyc29uYWwgaW5mb3JtYXRpb24gYnkgaWRl bnRpZnlpbmcgc29mdHdhcmUgdnVsbmVyYWJpbGl0aWVzIG9mIHRoZSBkYXRhYmFzZXMgdGhhdCBo b3VzZSB0aGVtLCBhbmQgZG8gaXQgaW4gdGhlIGNvbnRleHQgb2YgYW4gaW50ZXJuYXRpb25hbCBz ZXQgb2Ygc2VjdXJpdHkgc3RhbmRhcmRzLjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y OmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6YmxhY2snPkRhdmlkIE9saXZhPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpi bGFjayc+T24gMDgvMDYvMTIsIEx1aXMgTnVuZXombHQ7PGEgaHJlZj0ibWFpbHRvOmxudW5lekBj M2lzZWN1cml0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5sbnVuZXpAYzNpc2VjdXJpdHkuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Mb29raW5nIGF0IGl0IGFub3Ro ZXIgd2F5IEkgY291bGQgc2VlIHNlY3VyaXR5IGF1dG9tYXRpb24gYXMgYSB3YXkgdG8gZGlzY292 ZXIgaWYgYSBzeXN0ZW0gaXMgY29uZmlndXJlZCB0byBtZWV0IHByaXZhY3kgcG9saWNpZXMgLiAm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPlNlY3VyaXR5IGF1dG9tYXRpb24gaXMgYW4g ZW5hYmxlciBmb3IgdHJhbnNwYXJlbmN5ICZuYnNwO3NvIHRoYXQgaW5kaXZpZHVhbHMgYW5kIG9y Z2FuaXphdGlvbnMgbWF5IHVuZGVyc3RhbmQgdGhlIGNvbXBsZXggY29tcHV0aW5nIGVudmlyb25t ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5UaGFua3MgZm9yIGJyaW5n IHVwIHRoaXMgaXNzdWUuICZuYnNwO0FzIGEgY29tbXVuaXR5IHdlIG1heSB3YW50IHRvIGxvb2sg YXQgYnVpbGRpbmcgY29udGVudCBhcm91bmQgcHJpdmFjeSBjb250cm9scy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6YmxhY2snPi1sbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5PbiBB dWcgNiwgMjAxMiwgYXQgMTI6NDIgUE0sICZsdDs8YSBocmVmPSJtYWlsdG86S2VudF9MYW5kZmll bGRATWNBZmVlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPktlbnRfTGFuZGZpZWxkQE1jQWZlZS5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7Y29sb3I6YmxhY2snPjxicj48YnI+PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+ PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Tm9uZSBvZiB0aGUgZWZmb3J0cyB3ZSBhcmUgdGFsa2luZyBhYm91dCBmb3IgU0FDTSBhcmUg dGFyZ2V0ZWQgdG93YXJkIFBJSSBvciBpbmRpdmlkdWFscy4gVGhleSBhcmUgdGFyZ2V0ZWQgYXQg dGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIHBsYXRmb3JtcyBkZXBsb3llZCBpbiB0aGUgZW50ZXJw cmlzZSB0byBhc3N1cmUgdGhleSBjb21wbHkgd2l0aCB0aGUgc2l0ZSdzIHNlY3VyaXR5IHBvbGlj eS4gJm5ic3A7UElJIGlzIG5vdCBjb2xsZWN0ZWQuIFRoaXMgaXMgbm90IG1vbml0b3Jpbmcgb2Yg aW5kaXZpZHVhbCBvciBlbXBsb3llZSBhY3Rpb25zLiAmbmJzcDtJIGFtIG5vdCBhIGxhd3llciBh bmQgd2lsbCBub3Qgc3BlYWsgYXMgb25lLiBXZSB3aWxsIGxldCB0aGUgbGF3eWVyJ3MgZGVjaWRl IGF0IHRoZSBhcHByb3ByaWF0ZSB0aW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzdHJv bmc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjojNjA2QTcxJz5LZW50IExhbmRmaWVsZDwvc3Bhbj48L3N0cm9uZz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOiM2MDZBNzEnPjxicj48YnI+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiInPk1jQWZlZSB8IEFuIEludGVsIENvbXBhbnk8L3NwYW4+PC9z dHJvbmc+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+RGlyZWN0OiArMS45NzIuOTYz LjcwOTYmbmJzcDs8L3NwYW4+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+TW9iaWxl OiArMS44MTcuNjM3LjgwMjY8L3NwYW4+PGJyPjxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5XZWI6Jm5ic3A7PC9zcGFuPjwvc3Ryb25nPjxzcGFu IGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5tY2FmZWUuY29tLyIg dGFyZ2V0PSJfYmxhbmsiPnd3dy5tY2FmZWUuY29tPC9hPjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4n PjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Gcm9tOiA8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPk1hcnRpbiBSZXggJmx0OzxhIGhyZWY9Im1haWx0bzpt cmV4QHNhcC5jb20iIHRhcmdldD0iX2JsYW5rIj5tcmV4QHNhcC5jb208L2E+Jmd0Ozxicj48Yj5S ZXBseS1UbzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzptcmV4QHNhcC5jb20iIHRhcmdldD0i X2JsYW5rIj5tcmV4QHNhcC5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bXJleEBz YXAuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXJleEBzYXAuY29tPC9hPiZndDs8YnI+PGI+RGF0ZTog PC9iPk1vbmRheSwgQXVndXN0IDYsIDIwMTIgMTE6MzIgQU08YnI+PGI+VG86IDwvYj4mcXVvdDs8 YSBocmVmPSJtYWlsdG86dG9ueUB5YWFuYXRlY2guY29tIiB0YXJnZXQ9Il9ibGFuayI+dG9ueUB5 YWFuYXRlY2guY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnlAeWFhbmF0ZWNo LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRvbnlAeWFhbmF0ZWNoLmNvbTwvYT4mZ3Q7PGJyPjxiPkNj OiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1yZXhAc2FwLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pm1yZXhAc2FwLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptcmV4QHNhcC5jb20i IHRhcmdldD0iX2JsYW5rIj5tcmV4QHNhcC5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFp bHRvOnNhY21AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zYWNtQGlldGYub3JnPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zYWNt QGlldGYub3JnPC9hPiZndDs8YnI+PGI+U3ViamVjdDogPC9iPlJlOiBbc2FjbV0gTGVnYWwgYXNw ZWN0cyBvZiBTeXN0ZW0gbW9uaXRvcmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21h cmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluJyBpZD0iTUFDX09VVExPT0tfQVRUUklC VVRJT05fQkxPQ0tRVU9URSI+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+VG9ueSBSdXRrb3dza2kgd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6 My43NXB0O21hcmdpbi1yaWdodDowaW4nIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9D S1FVT1RFIj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn Pk1hcnRpbiBSZXggd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1b3Rl IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowaW4n IGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPkluIEdlcm1hbnksIGFuIGVtcGxveWVyIG1vbml0b3JpbmcgYSBjb21wYW55LW93bmVkIFBD IHRoYXQgYW4gZW1wbG95ZWUgdXNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPmZvciBjb21tdW5pY2F0 aW9uIChFTWFpbCwgVm9pUCwgSU0pIHdvdWxkIGJlIHVuY29uZGl0aW9uYWxseSBpbGxlZ2FsLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz5SZWFsbHk/PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPk5vIGtpZGRpbmchPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1 b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDow aW4nIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPlRoYXQgaXMgbm90IGNvbnNpc3RlbnQgd2l0aCBjb21tZW50czxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPkkndmUgc2VlbiBjb25jZXJuaW5nIEdlcm1hbiBsYXcuPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlRoZXJlIGlzIGEgc2ln bmlmaWNhbnQgYW1vdW50IG9mIG1pcy1pbmZvcm1hdGlvbiBmbG9hdGluZyB0aGUgaW50ZXJuZXQu PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+QW5kIGEgbWluZGJvZ2dsaW5nIGxhcmdlIG51bWJlciBvZiBs YXd5ZXJzIGFyZSBtYWtpbmcgd2lsZCBndWVzc2VzLCByYXRoZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz50aGF0IGRvaW5nIHJlc2VhcmNoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPlRoZSBkZWNpc2lvbnMgb2YgdGhlIGdlcm1hbiBmZWRlcmFsIGNvbnN0aXRp b25hbCBjb3VydCAoR0ZDQykgaGF2ZSBiZWVuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+cXVpdGUgY29u c2lzdGVudCBvdmVyIHRoZSBwYXN0IGRlY2FkZSBhYm91dCB3aGF0IHdpdGggcmVzcGVjdCB0bzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPmVuY3JvYWNoaW5nIG9uIHRoZSBnZW5lcmFsIHJpZ2h0IG9mIHBl cnNvbmFsaXR5LCBpbmZvcm1hdGlvbmFsPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+c2VsZi1kZXRlcm1p bmF0aW9uLCBmcmVlZG9tIG9mIGNvbmR1Y3QgYW5kIGNyZWF0ZWQgYSAmcXVvdDtmdW5kYW1lbnRh bCByaWdodDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPnRvIHRoZSBndWFyYW50ZWUgb2YgdGhlIGludGVn cml0eSBhbmQgY29uZmlkZW50aWFsaXR5IG9mIGluZm9ybWF0aW9uPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+dGVjaG5vbG9neSBzeXN0ZW1zJnF1b3Q7LiZuYnNwOyZuYnNwO1RoZSBjb3VydCBoYXMgc2V0 IHRoZSBtaW5pbXVtIHJlcXVpcmVtZW50cyB0aGF0PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+YXJlIHBy ZXJlcXVpc2l0ZSB0byBzdWNoIGVuY3JvYWNobWVudCwgc3VjaCBhcyB0aGUgcHJlcmVxdWlzaXRl IG9mIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5jbGVhciBmb3JtYWwgc3RhdHV0ZSBsYXcsIHdoaWNo IG5lZWRzIHRvIGJlIGxpbWl0ZWQgdG8gc2l0dWF0aW9uIHdoZXJlPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+cmVhbCBmYWN0cyBjcmVhdGUgcHJvYmFibGUgY2F1c2UuPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+VGhlIG9yaWdpbmFsIEdGQ0MgZGVjaXNpb24gaW4g Z2VybWFuIGxhbmd1YWdlIGlzIHF1aXRlIGNvbXByZWhlbnNpYmxlPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+KHRvIG1lLCBhdCBsZWFzdCksIHdoaWxlIEknbSBoYXZpbmcgc29tZSBkaWZmaWN1bHRpZXMg dW5kZXJzdGFuZGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPnRoZSBlbmdsaXNoIHRyYW5zbGF0aW9u IChhbmQgdGhlIGVuZ2xpc2ggdHJhbnNsYXRpb24gaXMgc2hvcnRlciE/KS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5CVmVyZkctRW50c2NoZWlkdW5nICZx dW90OzEgQnZSIDM3MC8wNyB2b20gMjcuMi4yMDA4JnF1b3Q7IFJhbmRudW1tZXIgMTk2LTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxhIGhyZWY9Imh0dHA6Ly93d3cuYnZlcmZnLmRlL2VudHNjaGVpZHVu Z2VuL3JzMjAwODAyMjdfMWJ2cjAzNzAwNy5odG1sI2FiczE5NiIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHA6Ly93d3cuYnZlcmZnLmRlL2VudHNjaGVpZHVuZ2VuL3JzMjAwODAyMjdfMWJ2cjAzNzAwNy5o dG1sI2FiczE5NjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz5lbmdsaXNoIHRyYW5zbGF0aW9uIG9mICZxdW90OzEgQnZSIDM3MC8wNyB2b20gMjcuMi4y MDA4JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PGEgaHJlZj0iaHR0cDovL3d3dy5idmVyZmcu ZGUvZW50c2NoZWlkdW5nZW4vcnMyMDA4MDIyN18xYnZyMDM3MDA3ZW4uaHRtbCNhYnMxMzAiIHRh cmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmJ2ZXJmZy5kZS9lbnRzY2hlaWR1bmdlbi9yczIwMDgw MjI3XzFidnIwMzcwMDdlbi5odG1sI2FiczEzMDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYg NC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2lu LXJpZ2h0OjBpbicgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+VG8gYmUgKnVuY29u ZGl0aW9uYWxseSogaWxsZWdhbCwgd291bGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5wcmVjbHVkZSBh bG1vc3QgYW55IHJhdGlvbmFsbHkgcmVxdWlyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5tYWludGVu YW5jZSBvciB0aHJlYXQgbWl0aWdhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9i bG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+SXQgaXMgcG9zc2libGUgdG8gcGVyZm9ybSBt YWludGVuYW5jZSBhbmQgdGhyZWF0IG1pdGlnYXRpb24gZW50aXJlbHk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz53aXRob3V0ICZxdW90O21vbml0b3JpbmcmcXVvdDsgc3lzdGVtcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5BIG1lcmUgdGhyZWF0IGlzIGluc3Vm ZmljaWVudCBmb3IgbW9uaXRvcmluZywgaWYgdGhhdCBpbnZvbHZlcyBjb2xsZWN0aW5nPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+UElJIGRhdGEsIGkuZS4gZGF0YSBmcm9tIHdoaWNoIGEgcGVyc29ucyBj b25kdWN0IGNhbiBiZSBpbmZlcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48YmxvY2txdW90 ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGlu JyBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz5JdCBpcyBmYWlyIHRvIG9ic2VydmUgdGhhdCByZWNlbnQgR2VybWFuPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Q29uc3RpdHV0aW9uYWwgQ291cnQgZGVjaXNpb25zIGltcG9zZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPmNvbnN0cmFpbnRzLCBidXQgdGhleSBjZXJ0YWlubHkgYXJlPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+bm90ICZxdW90O3VuY29uZGl0aW9uYWwuJnF1b3Q7PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPk9uZSBvZiB0aGUgcHJl cmVxdWlzaXRlIGlzIGEgY2xlYXIgZm9ybWFsIHN0YXR1dGUgbGF3LDxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPndoaWNoIGN1cnJlbnRseSBkb2VzIG5vdCBleGlzdCBmb3IgdGhlIHB1cnBvc2VzICZxdW90 O3NhY20mcXVvdDsgaXMgYWJvdXQuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+cXVvdGluZyBmcm9tIHRoZSBhYm92ZSBHRkNDIGRlY2lzaW9uOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOzIuIFRo ZSBmdW5kYW1lbnRhbCByaWdodCB0byB0aGUgZ3VhcmFudGVlIG9mIHRoZSBjb25maWRlbnRpYWxp dHkgYW5kPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7aW50ZWdyaXR5IG9mIGluZm9y bWF0aW9uIHRlY2hub2xvZ3kgc3lzdGVtcyBpcyBub3QgdW5yZXN0cmljdGVkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPiZuYnNwOyZuYnNwO0VuY3JvYWNobWVudHMgbWF5IGJlIGp1c3RpZmllZCBib3Ro IGZvciBwcmV2ZW50aXZlIHB1cnBvc2VzLCBhbmQgZm9yPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5i c3A7Jm5ic3A7Y3JpbWluYWwgcHJvc2VjdXRpb24uJm5ic3A7Jm5ic3A7VGhlIGluZGl2aWR1YWwg bXVzdCBvbmx5IGFjY2VwdCBzdWNoIHJlc3RyaWN0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOyZuYnNwO29mIGhpcyBvciBoZXIgcmlnaHQgd2hpY2ggYXJlIGJhc2VkIG9uIGEgc3RhdHV0 b3J5IGZvdW5kYXRpb24gdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwO2lzIGNv bnN0aXR1dGlvbmFsLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UaGlzIGN1cnJlbnRseSBtYWtlcyBjb2xs ZWN0aW5nIGRhdGEgYWJvdXQgcGVvcGxlcyBjb25kdWN0ICZxdW90O3VuY29uZGl0aW9uYWxseSZx dW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPmlsbGVnYWwgZm9yIG1vc3QgcHJhY3RpY2FsIHB1cnBv c2VzIChleGVtcHRpbmcgZnJvbSBwcm9zZWN1dGlvbiBvbmx5PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ aW5kaXZpZHVhbCBvY2Nhc2lvbnMgb2YganVzdGlmaWVkIHNlbGYtZGVmZW5jZSBhZ2FpbnN0IGFu IGltbWluZW50PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+dmljaW91cyBhdHRhY2sgYmFzZWQgb24gcmVh bCBmYWN0cyB0aGF0IGNyZWF0ZSBwcm9iYWJsZSBjYXVzZSkuPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+VGhpcyBhcHBsaWVzIHRvIGFsbCBzdXJ2ZWlsbGFu Y2UgdGhhdCBpbXBhaXJzIHBlcnNvbnMgJnF1b3Q7ZnJlZWRvbSBvZiBjb25kdWN0JnF1b3Q7Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPlRoZSBtYWpvcml0eSBvZiBwYXN0IGRlY2lzaW9ucyBvZiBzcGVj aWZpYyBldmVudHMgd2FzIGFib3V0IHN1cnZlaWxsYW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPndp dGggYSBjYW1lcmEsIGJ1dCB0aGUgR0ZDQyBkZWNpc2lvbiBtYWtlcyBpdCBjcnlzdGFsIGNsZWFy IHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz50aGlzIGFwcGxpZXMgdG8gKmFueSoga2luZCBvZiBz dXJ2ZWlsbGFuY2UuJm5ic3A7Jm5ic3A7RGlmZmVyZW50IHRvIG1vbml0b3Jpbmcgb2Y8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz5jb21wdXRlciBzeXN0ZW1zLCB0aGVyZSBpcyBzdGF0dXRvcnkgbGF3IGZv ciBjYW1lcmEgc3VydmVpbGxhbmNlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPnRoYXQgYWxsb3dzIG9w dGljYWwgc3VydmVpbGxhbmNlIHVuZGVyIGNlcnRhaW4gY29uZGl0aW9uczxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPihBcnQuIDZiIEJEU0cgJnF1b3Q7QnVuZGVzRGF0ZW5TY2h1dHpHZXNldHopLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlRoZSBsYWNrIG9mIGEg Zm9ybWFsIHN0YXR1dG9yeSBmb3VuZGF0aW9uIG1ha2VzIHN1cnZlaWxsYW5jZSBpbGxlZ2FsPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+YW5kIGVudGl0bGVzIHN1YmplY3RzIHRvICZxdW90O2NlYXNlIGFu ZCBkZXNpc3QmcXVvdDsgcnVsaW5ncyBhbmQgc29tZXRpbWVzPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ ZGFtYWdlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5J biBvbmUgbW9yZSByZWNlbnQgKGFuZCBjb25zdGl0dXRpb25hbGx5IGNvcnJlY3QpIHJ1bGluZ3Ms IGFuIGVtcGxveWVyPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+aGFkIHB1dCB1cCBhIGNhbWVyYSB0aGF0 IGhhZCBpbiB2aWV3IG5vdCBvbmx5IHRoZSBlbnRyYW5jZSBkb29yLCBidXQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz5hbHNvIHR3byB3b3JrcGxhY2VzLiZuYnNwOyZuYnNwO1RoZSBlbXBsb3llZXMgcHJv dGVzdGVkIGFnYWluc3QgdGhpcyBjYW1lcmEsPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+YnV0IHRoZSBl bXBsb3llciB3b3VsZCBub3QgJnF1b3Q7Zml4JnF1b3Q7IGl0LCBzbyBhdCBsZWFzdCBvbmUgZW1w bG95ZWUgc3VlZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UaGUgY291cnQgY29uZmlybWVkIHRoYXQg dGhpcyBjYW1lcmEgc3VydmVpbGxhbmNlIGF0IHRoZSB3b3JrcGxhY2U8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz53YXMgaWxsZWdhbCBkdWUgdG8gaXRzIGNoaWxsaW5nIGVmZmVjdCBhbG9uZSwgYW5kIHNp bmNlIGl0IGhhZCBiZWVuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+aW5zdGFsbGVkIGZvciBhIHdob2xl IHllYXIsIHRoZSBlbXBsb3llZSB3YXMgYXJ3YXJkZWQgNCBtb250aCBvZiBpbmNvbWU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz5hcyBkYW1hZ2VzIChmb3IgdGhlIGNoaWxsaW5nIGVmZmVjdCkuPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+QW5vdGhlciByZWNlbnQg ZGVjaXNpb24gd2FzIGFib3V0IGV2aWRlbmNlIGZyb20gYSBjb3ZlcnQgdmlkZW88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz5zdXJ2ZWlsbGFuY2Ugc2hvd2luZyBhbiBlbXBsb3llZSB0YWtpbmcgYSBwYWNr YWdlIG9mIGNpZ2FyZXR0ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5vbiB0d28gb2NjYXNpb25zLCB3 aGVyZSB0aGUgR2VybWFuIEZlZGVyYWwgTGFib3VyIENvdXJ0PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ KHRoZSBzdXByZW1lIGNvdXJ0IGZvciBsYWJvciByZWxhdGVkIGlzc3VlcykgcmVtYW5kZWQgdGhl IGRlY2lzaW9uPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+dG8gdGhlIHRyaWFsIGNvdXJ0IGJlY2F1c2Ug aXQgaGFkIGZhaWxlZCB0byBlc3RhYmxpc2ggd2hldGhlciB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz5jb3ZlcnQgdmlkZW8gc3VydmVpbGxhbmNlIHJlYWxseSBtZXQgYWxsIGNvbnN0aXR1dGlvbmFs IHByZXJlcXVpc2l0ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5vdGhlcndpc2UgdGhlIHZpZGVvIHN1 cnZlaWxsYW5jZSB3b3VsZCBoYXZlIGJlZW4gaWxsZWdhbCBhbmQgbm90PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+YmUgYWRtaXNzaWJsZSBhcyBldmlkZW5jZSBpbiBjb3VydC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4oR2VybWFuIGRlY2lzaW9uOiA8YSBocmVmPSJodHRwOi8vbGV4ZXRpdXMuY29tLzIwMTIs MjM1MSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9sZXhldGl1cy5jb20vMjAxMiwyMzUxPC9hPik8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UaGUgR2VybWFu IEZlZGVyYWwgQ29uc3RpdGlvbmFsIENvdXJ0IG5ldXRlcmVkIG51bWVyb3VzIGxhd3MgZHVyaW5n IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPmxhc3QgZGVjYWRlIGR1ZSB0byBsYWNrIG9mIGNsYXJp dHkgYW5kL29yIG92ZXJicm9hZCBlbmNyb2FjaG1lbnQgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz50 aGUgcGVyc29uYWwgcmlnaHQgb2Ygc2VsZi1kZXRlcm1pbmF0aW9uIGFuZCB0aGUgcmlnaHQgdG8g Y29uZmlkZW50aWFsaXR5PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+b2YgdGVsZWNvbW11bmljYXRpb25z LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlNlZSBhbHNv IHRoZSBHRkNDIGRlY2lzaW9uIGFib3V0IHRoZSBzY2FubmluZyBvZiBsaWNlbnNlIHBsYXRlczxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPih0aGUgZGVjaXNpb24gMSBCdlIgMjA3NC8wNSB2b20gMTEuMy4y MDA4IGluIGdlcm1hbik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48YSBocmVmPSJodHRwOi8vd3d3LmJ2 ZXJmZy5kZS9lbnRzY2hlaWR1bmdlbi9yczIwMDgwMzExXzFidnIyLTA3NDA1Lmh0bWwiIHRhcmdl dD0iX2JsYW5rIj5odHRwOi8vd3d3LmJ2ZXJmZy5kZS9lbnRzY2hlaWR1bmdlbi9yczIwMDgwMzEx XzFidnIyLTA3NDA1Lmh0bWw8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+d2hlcmUgaXQgY29uZmlybWVkIHRoYXQgZGF0YSBjb2xsZWN0aW9uIHJlcXVp cmVzIGZvcm1hbCBzdGF0dWUgbGF3LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPmFuZCB0aGF0IHRoZSBs YXcgaW4gcXVlc3Rpb24gd2Fzbid0IGxpbWl0ZWQgdG8gcHJvYmFibGUgY2F1c2UgYW5kPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+dGhlcmVmb3JlIHVuY29uc3RpdHV0aW9uYWwuPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+VGhlIG9ubHkgY3VycmVudGx5IGV4aXN0aW5nIGZvcm1hbCBzdGF0dWUgbGF3IGluIEdlcm1h bnksIHRoYXQgY291bGQgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz51c2VkIGluIHNvbWUgbGltaXRl ZCBmYXNoaW9uIGZvciAmcXVvdDtNb25pdG9yaW5nJnF1b3Q7IGlzIEFydC4xMDAgVEtHLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cuZ2VzZXR6ZS1p bS1pbnRlcm5ldC5kZS90a2dfMjAwNC9fXzEwMC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDov L3d3dy5nZXNldHplLWltLWludGVybmV0LmRlL3RrZ18yMDA0L19fMTAwLmh0bWw8L2E+PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+YnV0IHRoYXQgc3RhdHVlIGlzIGNsZWFybHkgbGltaXRlZCBpbiBwdXJw b3NlLCBpdCB3aWxsIG5vdCBhbGxvdyB0aGF0IGRhdGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz50byBi ZSB1c2VkIGZvciBhdXRvbWF0aWMgc3VydmVpbGxhbmNlIG9mICZxdW90O2VtcGxveWVlIGNvbmR1 Y3QmcXVvdDsgd2l0aCByZXNwZWN0PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+dG8gJnF1b3Q7Y29tcGFu eS1kZWZpbmVkIHBvbGljaWVzJnF1b3Q7LiZuYnNwOyZuYnNwO0VtcGxveWVycyB0cnkgaGFyZCB0 byBhdm9pZCBUS0cgZm9yIHRoZWlyPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+bmV0d29ya3MgKGZvciB3 aGljaCB0aGV5IHdpbGwgaGF2ZSB0byBmb3JtYWxseSByZWdpc3RlciksIGJ1dCB0aGF0IGFsc288 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz5tZWFucyB0aGF0IHRoZXkgZG8gbm90IGhhdmUgYSBmb3JtYWwg c3RhdHV0b3J5IGxhdyBmb3IgcGVyZm9ybWluZyBhbnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5raW5k IG9mIHN1cnZlaWxsYW5jZS9tb25pdG9yaW5nIGFzIGRlc2NyaWJlZCBpbiBBcnQuIDEwMCBUS0cg Zm9yIHN5c3RlbXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz50aGF0IGFyZSB1c2VkIGJ5IGVtcGxveWVl cyBmb3IgdGVsZWNvbW11bmljYXRpb25zIGFuZCBhIHNpZ25pZmljYW50IHBhcnQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz5vZiB0aGVpciBkYWlseSBhY3Rpdmllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4tTWFy dGluPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5zYWNtIG1haWxpbmcgbGlzdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+c2FjbUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20iIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY208L2E+PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2Pjwv YmxvY2txdW90ZT48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+c2FjbSBtYWls aW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5zYWNtQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NhY20iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NhY208L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIg c3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48aHIgc2l6ZT0xIHdp ZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXI+PC9zcGFuPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOmJsYWNrJz48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+c2FjbSBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOnNhY21A aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zYWNtQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20iIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY208L2E+PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_D7A0423E5E193F40BE6E94126930C4930BA00EA975MBCLUSTERxcha_-- From lnunez@c3isecurity.com Wed Aug 8 09:51: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 6D1E821F8763 for ; Wed, 8 Aug 2012 09:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.657 X-Spam-Level: X-Spam-Status: No, score=-3.657 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJRbaxTaW9oM for ; Wed, 8 Aug 2012 09:51:05 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD5D821F874C for ; Wed, 8 Aug 2012 09:51:04 -0700 (PDT) Received: by yenm5 with SMTP id m5so1093961yen.31 for ; Wed, 08 Aug 2012 09:51:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=iG82yUYXif8bcl/98r2pROl06e0ARzP7h1klHW+tbY8=; b=SJvjaejDqxUpi3ns4In7Wqai86J1vrL8an5g+P9lJg3FvUt650OHXubUS7e66t6Iw0 WjKriBuzv6IYwBnPGeNH7Uv7F9y3rDflrXxVweQM4mMr9qryTlP9hsbHbFngwx4sP3O4 FkVNSZDmXqf4rqJrB0VY2q/0tHQLfyzqsM2FrXtAdB0mXLVh2bD8fSz8+CGJHPQR80fo oroFxV7u1LZQkjCDFtUL7flMkyHxYf4UKr8NkMaDVUu6vrEQXi1vxZawqNdV4O/tAZQs h39EK+C1TXAuAr6SLS7kVYFTrVWjmokysy2B5YqSmlFFxEak4Ed3RtLFRPE8hFVZbxou 23EA== Received: by 10.236.197.69 with SMTP id s45mr726074yhn.74.1344444664231; Wed, 08 Aug 2012 09:51:04 -0700 (PDT) Received: from [192.168.1.40] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id w5sm20682654anl.10.2012.08.08.09.51.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Aug 2012 09:51:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_1B1AB343-8765-4616-A0D2-96CADBEF1F60" From: Luis Nunez In-Reply-To: Date: Wed, 8 Aug 2012 12:50:59 -0400 Message-Id: References: <6905825.18402.1344435730391.JavaMail.root@vms170025> To: "Waltermire, David A." X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQm0qtjsTSKfCqAbLv4gUPwl2zN8aH1FQOLSW5gCu0Fx3muUVxm9wfzJhWbRjQUPxEuGTbVT Cc: Ruben Oliva , mile@ietf.org, sacm@ietf.org Subject: Re: [sacm] Strategic alignment of security with business in SACM in an international context X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:51:09 -0000 --Apple-Mail=_1B1AB343-8765-4616-A0D2-96CADBEF1F60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I had mention the Cloud Security Matrix (Cloud Security Alliance) in = another thread. 1. is this something we can use as basis for mapping the various = regulations to a common id? 2. Is this SACM or MILE GRC related work? thanks. -ln On Aug 8, 2012, at 12:37 PM, Waltermire, David A. wrote: > The challenge we will likely face in scoping down the effort is that = we might not be able to work on the full stack that supports low-level = data collection, as well as higher level security processes and = controls. This is because we will likely need to charter around a lower = layer of function. This is why we need to scope as part of this work an = architecture document that illustrates how the smaller scope of work = fits into the larger picture that supports alignment with international = compliance models. > =20 > To say it a different way, we need to define a comprehensive picture = of the =93end state=94, even though we may only get part way there based = on an initial SACM charter. > =20 > We can use documents like ISO 27001 as guidance in producing the = architecture document to insure that the end state aligns well with your = concerns below. > =20 > Sincerely, > Dave > =20 > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of david.oliva@verizon.net > Sent: Wednesday, August 08, 2012 10:22 AM > To: lnunez@c3isecurity.com; sacm@ietf.org > Subject: [sacm] Strategic alignment of security with business in SACM = in an international context > =20 > =20 > Luis and all: >=20 > Unless we can demonstrate that the technologies and specifications we = are developing align with the security objectives of international = compliance models (such as ISO 27001) we cannot demonstrate strategic = alignment of business and security objectives in their context.=20 >=20 > Strategic alignment of security objectives with business objectives = can be at least partially joined via SACM thru the SP 800-53 to ISO = 27001 mapping table. If this were to happen to SACM then the validated = products will have less appeal and less marketability. The validated = products will work fine, but they will work with limited capability and = scope. For example, currently validated SCAP 1.0 products do not use = the Open Checklist Interactive Language (OCIL). OCIL is an open = specification (created by the security community for use by anybody, any = developer, any country) that facilitates non-automated assessment of = security processes. OCIL would allow an ISO 27001 compliance assessor = in Germany to create a question =93Does the organization comply ISO/IEC = 27001:2005 para 4.2.2 e) =91Does the organization implement a training = and awareness programme=92=94 and answer =91yes=92 or =91no=92. Then = the results can be accessed and read whether the organization uses = product X or product Y because OCIL is an open security specification. = Another example of OCIL is a rather mundane security function of = universal use. OCIL allows an ISO 27001 security compliance officer to = answer =91yes=92 or =91no=92 to the question =93Is the door shut?=94 and = make the result electronically readable whether he/she uses product X or = product Y. As for business, the flexibility of OCIL allows a company to = create a question =93Did the company reach our 7% profit strategic = objective over the past 10 years?=94 and able to answer it =91yes=92 or = =91no=92 with product X, Y, or Z and ensure interoperability. >=20 > =20 >=20 > David Oliva >=20 > =20 >=20 >=20 > =20 > =20 > On 08/07/12, Luis Nunez wrote: > =20 > Thanks the comment. I am glad someone agrees with me :) > =20 > -ln > =20 > On Aug 7, 2012, at 11:46 AM, david.oliva@verizon.net wrote: >=20 >=20 > Luis and all: > =20 > You are on target. > SACM is not a law enforcement thing, but is a facilitator of legal = issues in association with the protection of private information and = health-related information. >=20 > I think a couple of examples to show how SACM facilitates legal issues = about personal information is in order. >=20 > A SACM configuration scanner is able to monitor the configuration of = security controls as specified in ISO/IEC 27001:2005. This can be = accomplished when tier IV SCAP content is used because the output maps = the finding (compliance or non-compliance) of the scanner to security = control ISO/IEC 27001:2005 paragraph A.10.6.2 =93Security of Network = Services=94. Thus a SACM scanner is able to assist in international = governance compliance about personal information because SP 800-53 maps = to ISO 27001. >=20 > A SACM vulnerability scanner is able to meet compliance with ISO = 27001, para A.12.6.1 =93Control of technical vulnerabilities=94 because = a SACM scanner using SCAP tier IV content can map its output to the ISO = governance. SACM Vulnerability scanning can address aspects of = confidentiality of personal information by identifying software = vulnerabilities of the databases that house them, and do it in the = context of an international set of security standards. >=20 > =20 > David Oliva > =20 > =20 > =20 > On 08/06/12, Luis Nunez wrote: > =20 > Looking at it another way I could see security automation as a way to = discover if a system is configured to meet privacy policies . =20 > =20 > Security automation is an enabler for transparency so that = individuals and organizations may understand the complex computing = environment. > =20 > Thanks for bring up this issue. As a community we may want to look at = building content around privacy controls. > =20 > -ln > =20 > On Aug 6, 2012, at 12:42 PM, wrote: >=20 >=20 > None of the efforts we are talking about for SACM are targeted toward = PII or individuals. They are targeted at the configuration of the = platforms deployed in the enterprise to assure they comply with the = site's security policy. PII is not collected. This is not monitoring of = individual or employee actions. I am not a lawyer and will not speak as = one. We will let the lawyer's decide at the appropriate time. > =20 > Kent Landfield >=20 > McAfee | An Intel Company > Direct: +1.972.963.7096=20 > Mobile: +1.817.637.8026 > Web: www.mcafee.com > =20 > From: Martin Rex > Reply-To: "mrex@sap.com" > Date: Monday, August 6, 2012 11:32 AM > To: "tony@yaanatech.com" > Cc: "mrex@sap.com" , "sacm@ietf.org" > Subject: Re: [sacm] Legal aspects of System monitoring > =20 > Tony Rutkowski wrote: > Martin Rex wrote: > =20 > In Germany, an employer monitoring a company-owned PC that an employee = uses > for communication (EMail, VoiP, IM) would be unconditionally illegal. > =20 > Really? > =20 > No kidding! > =20 > =20 > =20 > That is not consistent with comments > I've seen concerning German law. > =20 > There is a significant amount of mis-information floating the = internet. > And a mindboggling large number of lawyers are making wild guesses, = rather > that doing research. > =20 > The decisions of the german federal constitional court (GFCC) have = been > quite consistent over the past decade about what with respect to > encroaching on the general right of personality, informational > self-determination, freedom of conduct and created a "fundamental = right > to the guarantee of the integrity and confidentiality of information > technology systems". The court has set the minimum requirements that > are prerequisite to such encroachment, such as the prerequisite of a > clear formal statute law, which needs to be limited to situation where > real facts create probable cause. > =20 > The original GFCC decision in german language is quite comprehensible > (to me, at least), while I'm having some difficulties understanding > the english translation (and the english translation is shorter!?). > =20 > BVerfG-Entscheidung "1 BvR 370/07 vom 27.2.2008" Randnummer 196- > http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007.html#abs196 > =20 > english translation of "1 BvR 370/07 vom 27.2.2008" > = http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007en.html#abs130 > =20 > =20 > To be *unconditionally* illegal, would > preclude almost any rationally required > maintenance or threat mitigation. > =20 > It is possible to perform maintenance and threat mitigation entirely > without "monitoring" systems. > =20 > A mere threat is insufficient for monitoring, if that involves = collecting > PII data, i.e. data from which a persons conduct can be infered. > =20 > =20 > =20 > It is fair to observe that recent German > Constitutional Court decisions impose > constraints, but they certainly are > not "unconditional." > =20 > One of the prerequisite is a clear formal statute law, > which currently does not exist for the purposes "sacm" is about. > =20 > quoting from the above GFCC decision: > =20 > 2. The fundamental right to the guarantee of the confidentiality and > integrity of information technology systems is not unrestricted. > Encroachments may be justified both for preventive purposes, and for > criminal prosecution. The individual must only accept such = restrictions > of his or her right which are based on a statutory foundation that > is constitutional. > =20 > =20 > This currently makes collecting data about peoples conduct = "unconditionally" > illegal for most practical purposes (exempting from prosecution only > individual occasions of justified self-defence against an imminent > vicious attack based on real facts that create probable cause). > =20 > This applies to all surveillance that impairs persons "freedom of = conduct". > The majority of past decisions of specific events was about = surveillance > with a camera, but the GFCC decision makes it crystal clear that > this applies to *any* kind of surveillance. Different to monitoring = of > computer systems, there is statutory law for camera surveillance, > that allows optical surveillance under certain conditions > (Art. 6b BDSG "BundesDatenSchutzGesetz). > =20 > The lack of a formal statutory foundation makes surveillance illegal > and entitles subjects to "cease and desist" rulings and sometimes > damages. > =20 > In one more recent (and constitutionally correct) rulings, an employer > had put up a camera that had in view not only the entrance door, but > also two workplaces. The employees protested against this camera, > but the employer would not "fix" it, so at least one employee sued, > The court confirmed that this camera surveillance at the workplace > was illegal due to its chilling effect alone, and since it had been > installed for a whole year, the employee was arwarded 4 month of = income > as damages (for the chilling effect). > =20 > Another recent decision was about evidence from a covert video > surveillance showing an employee taking a package of cigarettes > on two occasions, where the German Federal Labour Court > (the supreme court for labor related issues) remanded the decision > to the trial court because it had failed to establish whether the > covert video surveillance really met all constitutional prerequisites > otherwise the video surveillance would have been illegal and not > be admissible as evidence in court. > (German decision: http://lexetius.com/2012,2351) > =20 > The German Federal Constitional Court neutered numerous laws during = the > last decade due to lack of clarity and/or overbroad encroachment of > the personal right of self-determination and the right to = confidentiality > of telecommunications. > =20 > See also the GFCC decision about the scanning of license plates > (the decision 1 BvR 2074/05 vom 11.3.2008 in german) > http://www.bverfg.de/entscheidungen/rs20080311_1bvr2-07405.html > =20 > where it confirmed that data collection requires formal statue law, > and that the law in question wasn't limited to probable cause and > therefore unconstitutional. > =20 > =20 > The only currently existing formal statue law in Germany, that could = be > used in some limited fashion for "Monitoring" is Art.100 TKG, > http://www.gesetze-im-internet.de/tkg_2004/__100.html > but that statue is clearly limited in purpose, it will not allow that = data > to be used for automatic surveillance of "employee conduct" with = respect > to "company-defined policies". Employers try hard to avoid TKG for = their > networks (for which they will have to formally register), but that = also > means that they do not have a formal statutory law for performing any > kind of surveillance/monitoring as described in Art. 100 TKG for = systems > that are used by employees for telecommunications and a significant = part > of their daily activies. > =20 > =20 > -Martin > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > =20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > =20 > =20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --Apple-Mail=_1B1AB343-8765-4616-A0D2-96CADBEF1F60 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I had mention the Cloud Security Matrix (Cloud = Security Alliance) in another thread.
1. is this something we can = use as basis for mapping the various regulations to a common = id?
2. Is this SACM or MILE GRC related = work?

thanks.
-ln

On Aug 8, 2012, at 12:37 PM, Waltermire, David A. wrote:

The = challenge we will likely face in scoping down the effort is that we = might not be able to work on the full stack that supports low-level data = collection, as well as higher level security processes and = controls.  This is because we will likely need to charter around a = lower layer of function.  This is why we need to scope as part of = this work an architecture document that illustrates how the smaller = scope of work fits into the larger picture that supports alignment with = international compliance models.
To = say it a different way, we need to define a comprehensive picture of the = =93end state=94, even though we may only get part way there based on an = initial SACM charter.
 
We can use documents like ISO = 27001 as guidance in producing the architecture document to insure that = the end state aligns well with your concerns = below.
Dave
 
From: sacm-bounces@ietf.org = [mailto:sacm-bounces@ietf.org] On Behalf Of david.oliva@verizon.net
= Sent: Wednesday, = August 08, 2012 10:22 AM
To: lnunez@c3isecurity.com; = sacm@ietf.org
Subject: [sacm] Strategic alignment = of security with business in SACM in an international = context
 

David Oliva

On 08/07/12, Luis = Nunez<lnunez@c3isecurity.com> = wrote:
On Aug 7, 2012, at = 11:46 AM, david.oliva@verizon.net wrote:
SACM is not a law enforcement thing, but is = a facilitator of legal issues in association with the protection of = private information and health-related information.

A SACM = configuration scanner is able to monitor the configuration of security = controls as specified in ISO/IEC 27001:2005.  This can be = accomplished when tier IV SCAP content is used because the output maps = the finding (compliance or non-compliance) of the scanner to security = control ISO/IEC 27001:2005 paragraph A.10.6.2 =93Security of Network = Services=94.  Thus a SACM scanner is able to assist in = international governance compliance about personal information because = SP 800-53 maps to ISO 27001.A SACM vulnerability scanner is = able to meet compliance with ISO 27001, para A.12.6.1 =93Control of = technical vulnerabilities=94 because a SACM scanner using SCAP tier IV = content can map its output to the ISO governance.  SACM = Vulnerability scanning can address aspects of confidentiality of = personal information by identifying software vulnerabilities of the = databases that house them, and do it in the context of an international = set of security standards.David = OlivaOn 08/06/12, Luis = Nunez<On Aug 6, 2012, at = 12:42 PM, <None of the efforts we = are talking about for SACM are targeted toward PII or individuals. They = are targeted at the configuration of the platforms deployed in the = enterprise to assure they comply with the site's security policy. =  PII is not collected. This is not monitoring of individual or = employee actions.  I am not a lawyer and will not speak as one. We = will let the lawyer's decide at the appropriate = time.

Tony Rutkowski = wrote:
Martin Rex = wrote:
In Germany, an employer monitoring a = company-owned PC that an employee = uses
for communication (EMail, VoiP, IM) would be unconditionally = illegal.
No = kidding!
 
That is not consistent with = comments
I've seen concerning German = law.
There is a significant amount of = mis-information floating the = internet.
And a mindboggling large number of lawyers are = making wild guesses, rather
that doing = research.
 
The decisions of the = german federal constitional court (GFCC) have = been
quite consistent over the past decade about what with respect = to
encroaching on the general right of personality, = informational
self-determination, freedom of conduct and = created a "fundamental right
to the guarantee of the = integrity and confidentiality of = information
technology systems".  The court has = set the minimum requirements that
are prerequisite to such = encroachment, such as the prerequisite of = a
clear formal statute law, which needs to be limited to = situation where
real facts create = probable cause.
The original GFCC decision in german language = is quite comprehensible
(to me, at least), while = I'm having some difficulties = understanding
the english translation (and the english = translation is shorter!?).
BVerfG-Entscheidung "1 BvR 370/07 vom = 27.2.2008" Randnummer 196-
sacm@ietf.org
, "david.oliva@verizon.net" , "lnunez@c3isecurity.com" , "sacm@ietf.org" Thread-Topic: [sacm] Strategic alignment of security with business in SACM in an international context Thread-Index: AQHNdXFuQ7kczokuL0ey76Mefxnp0JdQkqSA//+XM4A= Date: Wed, 8 Aug 2012 17:22:19 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.16.97.202] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] Strategic alignment of security with business in SACM in an international context X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 17:22:26 -0000 On 8/8/12 9:37 AM, "Waltermire, David A." wrote: >=20 >We can use documents like ISO 27001 as guidance in producing the >architecture document to insure that the end state aligns well with your >concerns below. >=20 This is one way we can leverage the frame of reference information I sent previously. I think we could agree that the control objectives mentioned in a control framework, such as NIST 800-53 or ISO 27002 are generally supported by the processes and procedures used to implement concepts such as "security configuration management." I would argue that any of the low-level controls, or "activities" as some might prefer, can be mapped back to a given control framework quite easily, and without getting into the specific process/procedure details that will differ from organization to organization. >From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] >On Behalf Of david.oliva@verizon.net >Sent: Wednesday, August 08, 2012 10:22 AM >To: lnunez@c3isecurity.com; sacm@ietf.org >Subject: [sacm] Strategic alignment of security with business in SACM in >an international context > >Strategic alignment of security objectives with business objectives can >be at least partially joined via SACM thru the SP 800-53 to ISO 27001 >mapping > table. =20 I don't see how SACM would join SP 800-53 and ISO 27001. Instead, I see that SACM would support each, as mentioned above. Joining frameworks and similar guidance is more along the lines of what UCF does, and is not what I understand this effort to accomplish. Rather, I see the SACM effort as the start to providing a comprehensive set of automation and monitoring capabilities that can be leveraged by organizations seeking to substantiate the particular control objectives detailed by a given framework.=20 That said, I believe it is critical to ensure that the work we are doing does, in fact, lead to such substantiation. Therefore, I believe it's necessary to have a solid frame of reference that ties back to one or more widely accepted control frameworks. It's great to work from the bottom-up, but if we're not meeting the top-down view somewhere in the middle, we're failing. From tonynad@microsoft.com Wed Aug 8 10:27: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 CB64A21F851E for ; Wed, 8 Aug 2012 10:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naWH7KKlz8We for ; Wed, 8 Aug 2012 10:27:37 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id 5D57A21F853A for ; Wed, 8 Aug 2012 10:27:36 -0700 (PDT) Received: from mail36-db3-R.bigfish.com (10.3.81.225) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 8 Aug 2012 17:27:35 +0000 Received: from mail36-db3 (localhost [127.0.0.1]) by mail36-db3-R.bigfish.com (Postfix) with ESMTP id 58CE1340589 for ; Wed, 8 Aug 2012 17:27:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VS-20(zzbb2dI98dI9371Ic85fhzz1202h1082kzz8275ch1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah107ah) Received-SPF: pass (mail36-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail36-db3 (localhost.localdomain [127.0.0.1]) by mail36-db3 (MessageSwitch) id 1344446853363125_9178; Wed, 8 Aug 2012 17:27:33 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.227]) by mail36-db3.bigfish.com (Postfix) with ESMTP id 54BF64800BE for ; Wed, 8 Aug 2012 17:27:33 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 8 Aug 2012 17:27:32 +0000 Received: from db3outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 8 Aug 2012 17:27:30 +0000 Received: from mail41-db3-R.bigfish.com (10.3.81.242) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 8 Aug 2012 17:26:28 +0000 Received: from mail41-db3 (localhost [127.0.0.1]) by mail41-db3-R.bigfish.com (Postfix) with ESMTP id 9657D100389 for ; Wed, 8 Aug 2012 17:26:28 +0000 (UTC) Received: from mail41-db3 (localhost.localdomain [127.0.0.1]) by mail41-db3 (MessageSwitch) id 1344446787135086_13510; Wed, 8 Aug 2012 17:26:27 +0000 (UTC) Received: from DB3EHSMHS013.bigfish.com (unknown [10.3.81.254]) by mail41-db3.bigfish.com (Postfix) with ESMTP id 1DDD04C0061; Wed, 8 Aug 2012 17:26:27 +0000 (UTC) Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by DB3EHSMHS013.bigfish.com (10.3.87.113) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 8 Aug 2012 17:26:26 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.203]) by BL2PRD0310HT003.namprd03.prod.outlook.com ([10.255.97.38]) with mapi id 14.16.0175.005; Wed, 8 Aug 2012 17:26:26 +0000 From: Anthony Nadalin To: "tony@yaanatech.com" , "david.oliva@verizon.net" Thread-Topic: [sacm] Strategic alignment of security with business in SACM in an international context Thread-Index: AQHNdXGDJvQIIfv10UWU4c8m6OyXg5dQBVKAgAAlBtA= Date: Wed, 8 Aug 2012 17:26:25 +0000 Message-ID: References: <6905825.18402.1344435730391.JavaMail.root@vms170025> <502281A9.8020800@yaanatech.com> In-Reply-To: <502281A9.8020800@yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.56] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9D8081BL2PRD0310MB362_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT003.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%YAANATECH.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VERIZON.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%C3ISECURITY.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "lnunez@c3isecurity.com" , "sacm@ietf.org" Subject: Re: [sacm] Strategic alignment of security with business in SACM in an international context X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 17:27:37 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9D8081BL2PRD0310MB362_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To avoid distribution restrictions you may purchase a copy at http://www.is= o.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=3D42103 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ton= y Rutkowski Sent: Wednesday, August 08, 2012 8:12 AM To: david.oliva@verizon.net Cc: lnunez@c3isecurity.com; sacm@ietf.org Subject: Re: [sacm] Strategic alignment of security with business in SACM i= n an international context Hi David, Could you provide a copy of ISO 27001 so we could take a look at it? --tony On 8/8/2012 10:22 AM, david.oliva@verizon.net wrote: Luis and all: Unless we can demonstrate that the technologies and specifications we are d= eveloping align with the security objectives of international compliance mo= dels (such as ISO 27001) we cannot demonstrate strategic alignment of busin= ess and security objectives in their context. --_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9D8081BL2PRD0310MB362_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To avoid distribution res= trictions you may purchase a copy at http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumbe= r=3D42103

 <= /p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.o= rg] On Behalf Of Tony Rutkowski
Sent: Wednesday, August 08, 2012 8:12 AM
To: david.oliva@verizon.net
Cc: lnunez@c3isecurity.com; sacm@ietf.org
Subject: Re: [sacm] Strategic alignment of security with business in= SACM in an international context

 

Hi David,

Could you provide a copy of ISO 27001 so we could
take a look at it?

--tony

On 8/8/2012 10:22 AM, david.oliv= a@verizon.net wrote:

Luis and all:=

Unless we can demonstrate= that the technologies and specifications we are developing align with the = security objectives of international compliance models (such as ISO 27001) we cannot demonstrate strategic alignment of business and se= curity objectives in their context.  

 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9D8081BL2PRD0310MB362_-- From tony@yaanatech.com Wed Aug 8 11:09: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 349AC21F8600 for ; Wed, 8 Aug 2012 11:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJBlWSn4Ysf3 for ; Wed, 8 Aug 2012 11:09:32 -0700 (PDT) Received: from extmail1.prd.yaanatech.com (extmail1.prd.yaanatech.com [205.140.198.37]) by ietfa.amsl.com (Postfix) with ESMTP id 51C9121F8605 for ; Wed, 8 Aug 2012 11:09:32 -0700 (PDT) Received: from [192.168.0.4] (pool-173-72-150-118.clppva.fios.verizon.net [173.72.150.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extmail1.prd.yaanatech.com (Postfix) with ESMTP id 16CE458081; Wed, 8 Aug 2012 18:09:30 +0000 (UTC) Message-ID: <5022AB5A.60407@yaanatech.com> Date: Wed, 08 Aug 2012 14:09:30 -0400 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: Anthony Nadalin References: <6905825.18402.1344435730391.JavaMail.root@vms170025> <502281A9.8020800@yaanatech.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010302040302040705080801" Cc: "david.oliva@verizon.net" , "lnunez@c3isecurity.com" , "sacm@ietf.org" Subject: Re: [sacm] Strategic alignment of security with business in SACM in an international context 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, 08 Aug 2012 18:09:33 -0000 This is a multi-part message in MIME format. --------------010302040302040705080801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Wow, only CHF 134 to take a peek! Doesn't seem to comport with IETF practices. On 8/8/2012 1:26 PM, Anthony Nadalin wrote: > > To avoid distribution restrictions you may purchase a copy at > http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=42103 > > --------------010302040302040705080801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Wow, only CHF 134 to take a peek!
Doesn't seem to comport with IETF practices.

On 8/8/2012 1:26 PM, Anthony Nadalin wrote:

To avoid distribution restrictions you may purchase a copy at http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=42103


--------------010302040302040705080801-- From tonynad@microsoft.com Wed Aug 8 11:14:37 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819E821F8668 for ; Wed, 8 Aug 2012 11:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.662 X-Spam-Level: X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id othph2lvlp42 for ; Wed, 8 Aug 2012 11:14:36 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id CB15021F8647 for ; Wed, 8 Aug 2012 11:14:35 -0700 (PDT) Received: from mail191-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Wed, 8 Aug 2012 18:14:35 +0000 Received: from mail191-ch1 (localhost [127.0.0.1]) by mail191-ch1-R.bigfish.com (Postfix) with ESMTP id E7541E0092 for ; Wed, 8 Aug 2012 18:14:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VS-20(zzbb2dI98dI9371Ic85fhzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah107ah) Received-SPF: pass (mail191-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail191-ch1 (localhost.localdomain [127.0.0.1]) by mail191-ch1 (MessageSwitch) id 1344449672706460_26218; Wed, 8 Aug 2012 18:14:32 +0000 (UTC) Received: from CH1EHSMHS019.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.245]) by mail191-ch1.bigfish.com (Postfix) with ESMTP id AAE3C4200E2 for ; Wed, 8 Aug 2012 18:14:32 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 8 Aug 2012 18:14:30 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.298.5; Wed, 8 Aug 2012 18:14:26 +0000 Received: from mail59-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Wed, 8 Aug 2012 18:14:13 +0000 Received: from mail59-ch1 (localhost [127.0.0.1]) by mail59-ch1-R.bigfish.com (Postfix) with ESMTP id 891601601E9 for ; Wed, 8 Aug 2012 18:14:13 +0000 (UTC) Received: from mail59-ch1 (localhost.localdomain [127.0.0.1]) by mail59-ch1 (MessageSwitch) id 1344449652235688_14573; Wed, 8 Aug 2012 18:14:12 +0000 (UTC) Received: from CH1EHSMHS003.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail59-ch1.bigfish.com (Postfix) with ESMTP id 378221A0057; Wed, 8 Aug 2012 18:14:12 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 8 Aug 2012 18:14:10 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.203]) by BL2PRD0310HT001.namprd03.prod.outlook.com ([10.255.97.36]) with mapi id 14.16.0175.005; Wed, 8 Aug 2012 18:14:10 +0000 From: Anthony Nadalin To: "tony@yaanatech.com" Thread-Topic: [sacm] Strategic alignment of security with business in SACM in an international context Thread-Index: AQHNdXGDJvQIIfv10UWU4c8m6OyXg5dQBVKAgAAlBtCAAAytAIAAAL4g Date: Wed, 8 Aug 2012 18:14:09 +0000 Message-ID: References: <6905825.18402.1344435730391.JavaMail.root@vms170025> <502281A9.8020800@yaanatech.com> <5022AB5A.60407@yaanatech.com> In-Reply-To: <5022AB5A.60407@yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.56] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9D814BBL2PRD0310MB362_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%YAANATECH.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VERIZON.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%C3ISECURITY.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "david.oliva@verizon.net" , "lnunez@c3isecurity.com" , "sacm@ietf.org" Subject: Re: [sacm] Strategic alignment of security with business in SACM in an international context X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 18:14:37 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9D814BBL2PRD0310MB362_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Take that up with ISO, I'm sure they would be interested in your views and= suggestions on how to improve the standards world From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ton= y Rutkowski Sent: Wednesday, August 08, 2012 11:10 AM To: Anthony Nadalin Cc: david.oliva@verizon.net; lnunez@c3isecurity.com; sacm@ietf.org Subject: Re: [sacm] Strategic alignment of security with business in SACM i= n an international context Wow, only CHF 134 to take a peek! Doesn't seem to comport with IETF practices. On 8/8/2012 1:26 PM, Anthony Nadalin wrote: To avoid distribution restrictions you may purchase a copy at http://www.is= o.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=3D42103 --_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9D814BBL2PRD0310MB362_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Take that up with ISO, I&= #8217;m sure they would be  interested in your views and suggestions o= n how to improve the standards world

 <= /p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.o= rg] On Behalf Of Tony Rutkowski
Sent: Wednesday, August 08, 2012 11:10 AM
To: Anthony Nadalin
Cc: david.oliva@verizon.net; lnunez@c3isecurity.com; sacm@ietf.org Subject: Re: [sacm] Strategic alignment of security with business in= SACM in an international context

 

Wow, only CHF 134 to take a peek!
Doesn't seem to comport with IETF practices.

On 8/8/2012 1:26 PM, Anthony Nadalin wrote:

To avoid distribution restrictions you = may purchase a copy at http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumbe= r=3D42103

 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9D814BBL2PRD0310MB362_-- From amontville@tripwire.com Wed Aug 8 11:24: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 D7DDF21F8661 for ; Wed, 8 Aug 2012 11:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.317 X-Spam-Level: X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=-0.718, BAYES_00=-2.599, J_BACKHAIR_53=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yflqXUOaxGgL for ; Wed, 8 Aug 2012 11:24:51 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6177721F86EA for ; Wed, 8 Aug 2012 11:24:51 -0700 (PDT) Received: from mail118-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 8 Aug 2012 18:24:45 +0000 Received: from mail118-va3 (localhost [127.0.0.1]) by mail118-va3-R.bigfish.com (Postfix) with ESMTP id D5CAB4C03BE; Wed, 8 Aug 2012 18:24:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zzbb2dI98dI9371I601O604Tzz1202hzz8275bh8275dhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail118-va3 (localhost.localdomain [127.0.0.1]) by mail118-va3 (MessageSwitch) id 1344450283509384_19364; Wed, 8 Aug 2012 18:24:43 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.252]) by mail118-va3.bigfish.com (Postfix) with ESMTP id 6F017300043; Wed, 8 Aug 2012 18:24:43 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 8 Aug 2012 18:24:42 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 8 Aug 2012 11:26:40 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Wed, 8 Aug 2012 11:24:40 -0700 From: Adam Montville To: "tony@yaanatech.com" , Anthony Nadalin Thread-Topic: [sacm] Strategic alignment of security with business in SACM in an international context Thread-Index: AQHNdXFuQ7kczokuL0ey76Mefxnp0JdQequAgAAlqoCAAAwJAP//juQA Date: Wed, 8 Aug 2012 18:24:39 +0000 Message-ID: In-Reply-To: <5022AB5A.60407@yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.16.97.202] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <5A7057EF0D6E3143987AB143B0D25C80@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Cc: "david.oliva@verizon.net" , "lnunez@c3isecurity.com" , "sacm@ietf.org" Subject: Re: [sacm] Strategic alignment of security with business in SACM in an international context X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 18:24:54 -0000 On 8/8/12 11:09 AM, "Tony Rutkowski" wrote: >Wow, only CHF 134 to take a peek! >Doesn't seem to comport with IETF practices. There are a variety of sources to look at without buying or borrowing a copy. Here are a few. If you google for "iso 27001 appendix A" you'll get information about the same major section headings detailed in ISO 27002. http://blog.iso27001standard.com/2010/10/20/iso-27001-annex-a-controls/ http://en.wikipedia.org/wiki/ISO/IEC_27002 A book:=20 http://www.amazon.com/IT-Governance-Managers-Guide-Security/dp/0749452714/r ef=3Dsr_1_1?ie=3DUTF8&qid=3D1344449747&sr=3D8-1&keywords=3Diso27002 ISACA has some information about COBIT<-->ISO 27001 mapping for non members, and more for members. http://www.isaca.org/Knowledge-Center/Research/Documents/Aligning-COBIT,ITI LV3,ISO27002-Bus-Benefit-12Nov08-Research.pdf All that available, and here's the rough structure of 27002: * Security Policy * Organization of Information Security * Asset Management * Human Resources Security * Physical Security * Communications and Ops Management * Access Control * Information Systems Acquisition, Development, Maintenance * Information Security Incident management * Business Continuity * Compliance And, I just found a full table of contents here: http://www.praxiom.com/iso-security-toc.htm It would certainly be a useful exercise to map the capabilities provided by multiple working groups, not just sacm, into a framework such as this. I can see IODEF and mile being mapped into several sections, as well as nea, and perhaps some of the opsec stuff as well. Adam Adam From dcougias@netfrontiers.com Wed Aug 8 11:55:18 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4A221F86C7 for ; Wed, 8 Aug 2012 11:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.002 X-Spam-Level: X-Spam-Status: No, score=-3.002 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE+v4oZpdNlO for ; Wed, 8 Aug 2012 11:55:18 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D7F4E21F8658 for ; Wed, 8 Aug 2012 11:55:17 -0700 (PDT) Received: by yenm5 with SMTP id m5so1250129yen.31 for ; Wed, 08 Aug 2012 11:55:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:reply-to:to:cc:message-id:references:subject:mime-version :content-type:user-agent:x-mailer:x-gm-message-state; bh=amD2SPWYi4u47AbVjstM9FlSele0ftgEquah/afZfKo=; b=c9yZJfn/X5ME95QnpoAikfYgp4IxxU7LBsXXtWvBer3i60bJdrbs5V5F7Dr8ZZviOR JZR9QPLQNZlrJycjqvTk5sHo+IXlMOmrKqUj9OLlgPWXaQGkrYs9RFG91KveYEBh6nDB Ih4FsQ2dUfFpUhc54zEPdgzzGCN+97U1ekSqLTSQ8I91si9VCeuqA/GpPW0U0NtL4fWW Rh95To0JLFeAlPKitPtOtNNM8MAOxgjJsMnYF1pc2OlgvKYKFF5Dr6dsui4VEQiJ4yjO ul0mmefjdyQKXhY6vzWBjScQFiJiZRDCEJqm4ppZv2PvAi4bWMhqbPWRGB1nENTo/cXl 7bnQ== Received: by 10.66.76.170 with SMTP id l10mr2649030paw.57.1344452117090; Wed, 08 Aug 2012 11:55:17 -0700 (PDT) Received: from sender1.zohomail.com (sender1.zohomail.com. [72.5.230.103]) by mx.google.com with ESMTPS id mu8sm940751pbc.49.2012.08.08.11.55.16 (version=SSLv3 cipher=OTHER); Wed, 08 Aug 2012 11:55:16 -0700 (PDT) Date: Wed, 08 Aug 2012 11:55:15 -0700 From: Dorian Cougias To: Message-ID: <13907973c00.7901413989719813492.-7814053128682371062@netfrontiers.com> References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_41137_666322672.1344452115455" User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Gm-Message-State: ALoCoQlzvv9mKaO32Mxu4ggvWRF3rSkvjoSDCjXM0jngskZh/slMAcIJBYctR8GgT/5z5Tjl1Ph0 Cc: Ruben Oliva , mile@ietf.org, "David A." , sacm@ietf.org Subject: Re: [sacm] =?utf-8?q?Strategic_alignment_of_security_with_business_in?= =?utf-8?q?_SACM_in=C2=A0=C2=A0=C2=A0=C2=A0an_international_context?= X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcougias@netfrontiers.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, 08 Aug 2012 18:55:18 -0000 ------=_Part_41137_666322672.1344452115455 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit ------=_Part_41137_666322672.1344452115455 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit The UCF will provide a common mapping for you, with unique and persistent IDs.

I can provide UCF spreadsheets to those of you who need them.



Dorian J. Cougias
Compliance Scientist
Unified Compliance Framework

------=_Part_41137_666322672.1344452115455-- From michael.hammer@yaanatech.com Wed Aug 8 13: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 21B7E21F8585 for ; Wed, 8 Aug 2012 13:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.255 X-Spam-Level: X-Spam-Status: No, score=-3.255 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_26=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVeG6GSS3GzR for ; Wed, 8 Aug 2012 13:14:21 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7D921F857D for ; Wed, 8 Aug 2012 13:14:21 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 8 Aug 2012 13:14:20 -0700 From: Michael Hammer To: "mrex@sap.com" Thread-Topic: [sacm] Legal aspects of System monitoring Thread-Index: AQHNcebv9wpWqLOXkkW1HGuGxo9Hw5dKJ8AAgANL5YCAAAL0gIAACqqAgAAKjYCAAA8AAIAAB8sAgACMTgCAABRugIAAHNCA///9L9CAATKwgIAA0BQw Date: Wed, 8 Aug 2012 20:14:15 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB30B911353@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB30B910926@EX2K10MB1.corp.yaanatech.com> <20120808004627.F107F1A12E@ld9781.wdf.sap.corp> In-Reply-To: <20120808004627.F107F1A12E@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.50.59] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0075_01CD7580.D85B05C0" MIME-Version: 1.0 Cc: "sacm@ietf.org" , "anton@chuvakin.org" Subject: Re: [sacm] Legal aspects of System 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, 08 Aug 2012 20:14:23 -0000 ------=_NextPart_000_0075_01CD7580.D85B05C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Martin, Your conflating two distinct things, what is done outside of work (facebook passwords) and what occurs during work just confuses the issues. Second, we are not talking personal equipment here, but company equipment and systems. I guess you are saying that theft and misappropriation of service and property of the employer is not protected in Germany. Mike -----Original Message----- From: Martin Rex [mailto:mrex@sap.com] Sent: Tuesday, August 07, 2012 8:46 PM To: Michael Hammer Cc: mrex@sap.com; anton@chuvakin.org; sacm@ietf.org Subject: Re: [sacm] Legal aspects of System monitoring Michael Hammer wrote: > > In the U.S. so long as the employer explicitly points out to the user > that he is using the employers equipment, and that such use is for > business purposes only, and all other activity is prohibited, and that > the employer will be monitoring to ensure the employer's equipment is > used for business purposes only, it is in line with common business practice to do so. I'm aware of the almost complete lack of privacy protections in the US outside one's home as well as the lack of personality&privacy protections at the workplace. This concept is not universally transferable to legislations with data protection laws. Don't get me wrong here. This type of monitoring is OK and useful for servers and computers/devices with very dedicated purposes. But unconditional constant electronic surveillance of user behaviour and/or user data will be illegal in Germany for a personal computing equipment (workplace PC,Laptop,Tablet,Smartphone,...) that is used for telecommunications and a significant amount of the working time. Notices and orders by your employer can grant you additional rights, but they can not take away or restrict your constitutional rights. This could mean that for some workplaces the employer might have to install/provide two computing environments, one for telecommunications (Email,VoiP,IM,Internet-Browsing) and the other for access to highly sensitive data, which is _not_ used for telecommunications, so that the employer is permitted monitor the latter (but there are still limits, because profiling user behaviour will still be illegal without either formal statute law or probable cause). The seperate computing environments need not be distinct physical devices; depending on how it is set up, virtualization might be sufficient to provide two seperate computing environments, with one of them being completely excluded from unconditional monitoring of any user actions and user data. What many folks (and unfortunately still many labor lawyers and several entry-level labor court judges in Germany) still fail to understand, is that "for business purposes only" does *NOT* remove or restrict the individual's privacy rights for telecommunication *AT ALL*. That's an urban legend in Germany--admittely, one that is quite commonplace, but nevertheless unconstitutional and legally untenable. The German Federal Constitutional Court has decided this over a decade ago, and been repeating it in at least 4 rulings since then. The German Federal Labor Court has confirmed this (and the resulting inadmissibility as evidence) twice for voice telephone calls (that happened to be appealed that far). Other specific scenarios have not been appealed to the GFLC, but the GFCC ruling on which the GFLC decisions were based, are quite explicit that the constitutional protection applies to all non-public telecommunications alike (phone,fax,Email,SMS,IM), everywhere where the person is (the right protects the person), independent of the nature of the content, and independent of whether public or confidential information is communicated, and irrespective of the ownership of the telecommunication equipment that is used. GFCC decision 1 BvR 1611/96 (09-Oct-2002) > > This is just the online version of an employer noticing his employee > spending all his time reading Playboy at work and being on the phone > talking to his girlfriend, and telling him to get back to work. What would be "actionable" here in Germany is *NOT* each individual occurrence of any particular of these activities. What is actionable is when the combined amout of worktime that you spend on other things but working, and for which you still demand pay, exceeds the threshold of what is considered "socially acceptable". There are a number of activities which are not "productive", such as small-talk with colleagues, going to the rest-room, taking a break for smoking, getting some water or a coffee, whathaveyou. The employers control over what an employee does during unpaid overtime or during "socially acceptable" paid non-working time is limited. If an employee would be doing just occasional private online-banking (adding up to less than an hour per month), then it will often not be actionable even when the employer has an explicit policy Internet use for Business purposes only. (I'm aware that some lawyers and a few german entry level labor court have differing opinions, but none of these are based on facts&statutes. If there are two contrary court decisions, then matching them with decisions of the GFCC helps in distinguishing correct, questionable and invalid decisions. The issue at hand is constant electronic surveillance without probable cause. In Germany, that unconditionally requires a sufficiently precise "statutory foundation" by the parliamentarian legislator in order not to be illegal. The situation of employment is special, because the German legislator has placed an explicit obligation onto the employer to respect and protect the personal rights of his employees in Art. 75 (2) BetrVG: http://www.gesetze-im-internet.de/betrvg/__75.html How this applies to unconditional electronic surveillance can be seen in the decision of the German Federal Labour Court (GFLC) 1 ABR 21/03 (29-06-2004) http://lexetius.com/2004,2335#27 So even a loss (alleged/assumed theft) of 300 Letters&Parcels per month is a subsidiary of the postal services can NOT justify constant and unconditional CCTV surveillance at the workplace, even though each such theft is a felony, punishable with up to 5 years prison term. A successor attempt for CCTV surveillance 4 years later was found mostly acceptable by GFLC, because of the many safeguards&limitations that had been added to the procedures. Usage of any collected surveillance data was strictly limited to prosecuting crime, *NOT* for purpose of detecting non-compliance to any policies. > > Don't tell me that is permissible behavior in Germany. You're primarily asking the wrong questions and your reasoning/deduction on this issue is logically flawed. Having the "privilege" to define policies does not imply that there are no limits in the means you are permitted to enforce them. While requiring employees to work naked might be fairly effective in helping to reduce theft by employees. I assume that there are limits to what an employer can rightfully demand, even in the US. http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/10000/200 0/800/12808/12808.strip.gif http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/10000/700 0/100/17112/17112.strip.sunday.gif http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/20000/000 0/900/20906/20906.strip.gif When looking at issues like this: http://blog.alexanderhiggins.com/2012/03/28/congress-decides-employers-deman d-facebook-password-107972/ this send shivers down my spine. In Germany, there is no prerequisite of a criminal statute to make this illegal, because it is also unconstitutional. However, the european data protection directive (and its national incarnation in EU members states) will very likely apply, making this directly punishable--not just "cease and desist else get punished"-able. -Martin ------=_NextPart_000_0075_01CD7580.D85B05C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgw ODIwMTQxMFowIwYJKoZIhvcNAQkEMRYEFIMI3/AzitjAB2vYg4p4KPa9jvAIMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGABa5wda9dA8BsUuEaoggwoefVVo3H+UNjVP1uWqGNIE68 RDaq8l6XZXmn+U0YY0jsIUwNg3IH7++4zWynPqyaWWvWV/rc460L7oQJTPK4MIM41O51LLy7+Fkn a9nda72Wbd1naTDA3RA3Q6IQE5S92wc/G+xa58zxB+UkV3PWan4AAAAAAAA= ------=_NextPart_000_0075_01CD7580.D85B05C0-- From michael.hammer@yaanatech.com Wed Aug 8 13:18: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 7543121F85D0 for ; Wed, 8 Aug 2012 13:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YItUiar6uSL for ; Wed, 8 Aug 2012 13:18:55 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 563E621F853A for ; Wed, 8 Aug 2012 13:18:55 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 8 Aug 2012 13:18:55 -0700 From: Michael Hammer To: "mrex@sap.com" , "shanna@juniper.net" Thread-Topic: [sacm] Legal aspects of System monitoring Thread-Index: AQHNcebv9wpWqLOXkkW1HGuGxo9Hw5dKJ8AAgANL5YCAAAL0gIAACqqAgAAKjYCAAA8AAIAAB8sAgACMTgCAAH6dAIABBWwAgACuZ0A= Date: Wed, 8 Aug 2012 20:18:52 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB30B911367@EX2K10MB1.corp.yaanatech.com> References: <20120808025126.913441A12E@ld9781.wdf.sap.corp> In-Reply-To: <20120808025126.913441A12E@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.50.59] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_007A_01CD7581.7D10DAE0" MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Legal aspects of System 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, 08 Aug 2012 20:18:58 -0000 ------=_NextPart_000_007A_01CD7581.7D10DAE0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit This totally ignores the reality of how systems, services, and particularly Cloud works today. Makes me wonder if those lawyers ever used Gmail. So, I guess you are saying that as long as all the data and processing occurs on a company server (aka in a Cloud), then it is ok to monitor all they want. :) Problem solved. Mike -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Martin Rex Sent: Tuesday, August 07, 2012 10:51 PM To: Stephen Hanna Cc: mrex@sap.com; sacm@ietf.org Subject: Re: [sacm] Legal aspects of System monitoring Stephen Hanna wrote: > > I am certainly no expert on European law in this area. And I can comment only on the situation in Germany. > > However, I will note that monitoring and auditing corporate > information systems and networks is common practice in corporate > environments. Generally, the Acceptable Use Policy includes consent to > monitoring and audits. For example, look at the SANS template for an > Acceptable Use Policy available at > > http://www.sans.org/security-resources/policies/Acceptable_Use_Policy. > pdf The monitoring of servers and dedicated devices is OK, the monitoring of data that is _not_ related to user activities/conduct is also OK, but the surveillance of user activities at the workplace of the users telecommunication and the user data resulting from that telecommunication is clearly illegal in Germany. I'm well aware that there is plenty of illegal activity commonplace in many companies in Germany, but that does not make them any less illegal. When the 1 ABR 21/03 (29-Jun-2004) decision about CCTV surveillance at the workplace was appealed to the German Federal Labour Court, the employer argued that were already performing CCTV surveillance in that fashion in 50 other subsidiaries (which for Germany means there have likely been _at_least_100_ labor lawyers involved in those other cases and found it non-objectionable), and two lower courts in this decision, but the German Federal Laber Court tore it to shreds with unprecedented explicit and clear determinations of why this activity was unconstitutional, quoting prior decisions of its own and decisions of the Constitutional Court. Therefore looking at the folklore on the aspect of electronic surveillance is a bad idea, because of the longstanding systemic error, that is evident from the GFLC decision 1 ABR 21/03. For the most part, that mess hasn't been cleaned up yet. Someone living in a jurisdiction based on case law may significantly underestimate the meaning&effect of that GFLC decision. After the Constitutional Court decision about the unconstitutionality of that particular video surveillance technology for traffic, there was a huge flurry of trials and appeals, and those appeals which made it all the way up (two even to the Constitutional Court), were quite obviously by clueless lawyers, who had not cared to actually read and comprehend the 4-page GFCC decision, or they would have immediately realized that their appeal are pointless (waste of time and money), because the two issues to which the GFCC had objected, had been fixed. > > In some environments (universities and libraries), intellectual > freedom may trump security in some cases. It is actually the other way round. In a company setting, the usage of a specific computer is typically not "voluntary" (i.e. you do not have to option to "not" use it, or to use your privately-owned equipment instead, in educational settings, specific pieces of equipment are not assigned to specific individuals over a long period of time, and in the educational setting Art. 75 (2) BetrVG does not apply, that requires employers to respect and protect employees personal rights. > > However, even universities generally include provisions for monitoring > when necessary. For example, here are a few policies for universities > in the USA, UK, and Germany: > > http://www.it.ufl.edu/policies/monitoring.html > http://www.admin.ox.ac.uk/statutes/regulations/196-052.shtml > http://www.cip.bv.tum.de/en/cippools-/termsofuse > > These policies were chosen at random, not deliberately to support one > point of view or another. But they are remarkably similar in many > respects. > > I observe that the Technical University of Munich permits monitoring > of user behavior and forensic analysis under appropriate > circumstances. > > So I conclude that the techniques and technologies for monitoring user > behavior and system configuration are used around the world. As I said, it is a terrible bad idea to infer what is legal from the folklore, in particular for a jurisdication that is primarily based on statute law, not case law. I'm really glad that the two works councils of these two postal subsidiaries took their video surveillance issue up to the GFLC (1 ABR 21/03, 1 ABR 16/07), because the decisions are quite elaborate and directly applicable to all kinds of electronic surveillance (and that looks _very_ intentional). > > In the SACM group, we're talking about developing technology that will > help corporations to better secure their computer systems and > networks. I believe that there should be a distinction between two types of systems/devices, personal-use systems that may be subject to privacy protection, and backend,server and networking equipment, where this does not apply. > > We should carefully note the importance of maintaining balance between > user privacy and system security and obeying all relevant laws, rules, > and regulations. > However, it would be foolish for us to think that we can come up with > one policy that would apply in all circumstances. Instead, we should > permit system and network owners to establish and implement their own > policies. At least, that's my point of view. Without the possibility to distinguish these two types of equipment, you will face the situation that products implementing this will not be usable in certain markets (German being one of them) once they are subjected to serious legal review, much like that particular unconstitutional traffic video surveillance equipment had to be updated/replaced all over Germany after the GFCC verdict, with the technical capability to limit surveillance to probable cause. -Martin _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_000_007A_01CD7581.7D10DAE0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgw ODIwMTg0N1owIwYJKoZIhvcNAQkEMRYEFDe/TPW5O+SGt7q/3I7/G515PWLBMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGA2XUOyWpujOlB7FTpUCGOPsdwSmQlJwv5LbcCXVUqGUp9 lPJzMPscSoccd2OCNyomUeaWC69zbuPy5xOFAQhjlPG1GaNaDiI/lxwWFZ+aDSs+5DXkZvO+kFBf XpmXwbPVK8tLRYhcNezM8bQpdNqOa3t8axL6xvvoUlgPu5gQfEMAAAAAAAA= ------=_NextPart_000_007A_01CD7581.7D10DAE0-- From lnunez@c3isecurity.com Wed Aug 8 14:48:10 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9564121F85D0 for ; Wed, 8 Aug 2012 14:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5H0aNtuL3Za for ; Wed, 8 Aug 2012 14:48:10 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E2EBC21F85C5 for ; Wed, 8 Aug 2012 14:48:09 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1458530ghb.31 for ; Wed, 08 Aug 2012 14:48:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=fhTMlV3SsJYiGbiczayCj3TpHl/mml4uzC37aq/6tZI=; b=HjNUP7v72bPo/NxanqVnD0V8XnSdMlVXM5MOxUhkoxdq+CRV7WKbCFHqnlFIkvBCZ/ 6oG/PX/RgNq3KqC/kAIrFvh0j6jd8r+KMsVJFXqX3xKdmH7jo5sHKI71jst8DD4MIfzV wq3iNeCBXe2pJG0kvjeYapoINywkxs3X7eRtvR09fOmkzTRjMdJjRQ6bMGGcYGw9v0lp XlFkq6xQ7LrgTxWBnZLRAPL58hJAhIKAm4jeWqoO4T0/45w2PW7Z2SfbTTzSqIHZl1cM mIayG5eBQIqwLnTyoNZca0aaw6vqwTrWyLgiGqMjLaX/CrXqqOqt9inBkgoTvXwXH5mK 2gxw== Received: by 10.236.155.234 with SMTP id j70mr18158309yhk.124.1344462489439; Wed, 08 Aug 2012 14:48:09 -0700 (PDT) Received: from [192.168.1.46] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id d66sm44285757yhe.1.2012.08.08.14.48.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Aug 2012 14:48:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Luis Nunez In-Reply-To: <13907973c00.7901413989719813492.-7814053128682371062@netfrontiers.com> Date: Wed, 8 Aug 2012 17:48:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5AB51D51-9781-4056-BAA9-86332F30D22E@c3isecurity.com> References: <13907973c00.7901413989719813492.-7814053128682371062@netfrontiers.com> To: dcougias@netfrontiers.com X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnOrGl3dpIUyyc0+UgGUi+UDHVsoje7HNkPc5b6cmZD04wZsn7SDRsgjq/827sSMF+BI63+ Cc: Ruben Oliva , mile@ietf.org, "David A." , sacm@ietf.org Subject: Re: [sacm] =?iso-8859-1?q?Strategic_alignment_of_security_with_busine?= =?iso-8859-1?q?ss_in_SACM_in=A0=A0=A0=A0an_international_context?= X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 21:48:10 -0000 I would be interested in reviewing a copy. BTW are there any IPR attached to the UCF document. Thanks dorian. -ln On Aug 8, 2012, at 2:55 PM, Dorian Cougias wrote: > The UCF will provide a common mapping for you, with unique and = persistent IDs. >=20 > I can provide UCF spreadsheets to those of you who need them. >=20 >=20 >=20 > Dorian J. Cougias > Compliance Scientist > Unified Compliance Framework >=20 From mrex@sap.com Wed Aug 8 18:04:00 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16AB11E814B for ; Wed, 8 Aug 2012 18:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.17 X-Spam-Level: X-Spam-Status: No, score=-10.17 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oqwWeAyPQDo for ; Wed, 8 Aug 2012 18:03:58 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 89E6811E811A for ; Wed, 8 Aug 2012 18:03:58 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q7913uQa005525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Aug 2012 03:03:56 +0200 (MEST) In-Reply-To: <00C069FD01E0324C9FFCADF539701DB30B911367@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer Date: Thu, 9 Aug 2012 03:03:55 +0200 (CEST) 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: <20120809010355.615F41A144@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "shanna@juniper.net" , "mrex@sap.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: Thu, 09 Aug 2012 01:04:01 -0000 Michael Hammer wrote: > This totally ignores the reality of how systems, services, > and particularly Cloud works today. Nope. Some of the cloud services seem to be ignorant of the legal setting in which some of their (alleged) target customers operate, probably because of a lack of legal protections&requirements in the countries where the cloud providers themselves operate. >From the business perspective of cloud providers this might be perfectly resonable conduct in _their_ jurisdiction. > > Makes me wonder if those lawyers ever used Gmail. I'm not talking about unsubstantiated laywer opionions here, I'm talking about real, applicable statutes and past decisions of the German Federal Courts and the Federal Constitutional Court, i.e our highest appellate courts. > > So, I guess you are saying that as long as all the data and processing > occurs on a company server (aka in a Cloud), then it is ok to monitor all > they want. :) When user behaviour/conduct and user data is not monitored, then the constitutional protections do not apply, independent of where the server is located. Cloud or local server is a completely irrelevant technical implementation detail for deciding which PII can be legally monitored (collected, processed and used by someone else than the data subject and for which purposes) and which information can not. This is why it will be illegal to outsource storage&processing of data, that is subject to data protection law (respectively the european data protection directive) to cloud offerings that are operating outside of a jurisdiction with comparable strict data protection statutes as in the EU, unless each individual data subject that is affected voluntarily agrees. For data that an employer collects about its employees in Germany, Art. 75 (2) BetrVG requires that the principle of proportionality is satisfied even when all affected employees would voluntarily agree. There seems to be a thorough misunderstanding of how the constitutional protections of fundamental rights in German Basic Law work. These constitutional protections are provided in an abstract fashion, and require a _white-listing_ with statutes from a parlamentarian legislator (federal or state) that must narrowly define which encroachments of the fundamental rights are to be legal under which preconditions, PLUS, when it is about collecting PII, the statute must list the exact purposes for which the information may be legally used. Criminal statutes are a _black-listing_ approach (and need to be, that is a requirement in most constitutions and the european human rights convention). The problem with black-listing is, that it can often be evaded / worked around. When a legislater wants to provide a reliable protection of rights, then a sensible statue will contain a very broad "this is illegal unless explictly permitted by some other statute" provision (=the basis for white-listing) along with several narrow definitions of puishable crimes (black_listing). The reason is obvious: legal weasels will find ways to evade the black-listing. This is where the white-listing requirement comes in as backup. While not permitting any direct punishment, a broad "this is illegal unless..." white-listing requirement provides sufficient grounds for temporary and permanent injunctions (which themselves can be backed by punishments). When a customer of a large German ISP with a flatrate DSL subscription realized that the ISP was keeping records of the DHCP assignments of the temporary IPv4 address on the external interface of the DSL customers router for several months, he demanded from the ISP to delete this information in a timely fashion when it is no longer used, because it is PII, and holding on to this information is not explicitly permitted by the exemptions of the TKG (german federal telecommunications act) unless it is necessary for billing. Billing a flatrate subscription does not require that assignment. The ISP denied the request and the customer sued. The court ordered an injunction that the ISP must delete the data in a timely fashion (14 days). The ISP appealed, the appeal was rejected, and the injuction was backed with a two-stage punishment for further non-compliance, a fine of Euro 100k and if that doesn't work. a 6 month prison term for the active CEO. http://www.heise.de/newsticker/meldung/T-Online-darf-nur-fuer-Rechnung-noetige-Verbindungsdaten-speichern-168803.html The Federal Court of Justice rejected the second appeal by the ISP (on formal grounds). http://www.kein1984.de/bgh-entscheidung.pdf There is no doubt that criminal statutes are a better deterrent, but that doesn't mean that the "this is illegal, unless ..." provisions would not work. Injunctions can be backed by convincing punishments, where necessary. I assume that these can be quite effective motivators for corporate entities to comply. Though it can sometimes be a tedious process to get a decision and hopefully an injunction. For comparison, the criminal proceedings of an illegal surveillance (monitoring of phone records of ~60 individuals) trying to find an information leak, as summarized on Wikipedia, resulted in one manager getting a 3.5 year prison term. Several of the (technical) folks, who were involved in actually monitoring the phone records, had to pay fines in the Eur 5k-10k range, on the premise that they were just following order and not aware to be actively commiting crimes. Two Ex-CEOs made a settlement with the company, paying Eur 600.000 each. http://de.wikipedia.org/wiki/%C3%9Cberwachungsaff%C3%A4re_der_Deutschen_Telekom -Martin From michael.hammer@yaanatech.com Wed Aug 8 18:55:25 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C7611E815B for ; Wed, 8 Aug 2012 18:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-0mlLd8NvSw for ; Wed, 8 Aug 2012 18:55:24 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id DDFD011E8150 for ; Wed, 8 Aug 2012 18:55:23 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 8 Aug 2012 18:55:23 -0700 From: Michael Hammer To: "mrex@sap.com" Thread-Topic: [sacm] Legal aspects of System monitoring Thread-Index: AQHNcebv9wpWqLOXkkW1HGuGxo9Hw5dKJ8AAgANL5YCAAAL0gIAACqqAgAAKjYCAAA8AAIAAB8sAgACMTgCAAH6dAIABBWwAgACuZ0CAAMXkgP//lrpQ Date: Thu, 9 Aug 2012 01:55:21 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB30B9179FC@ex2k10mb2.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB30B911367@EX2K10MB1.corp.yaanatech.com> <20120809010355.615F41A144@ld9781.wdf.sap.corp> In-Reply-To: <20120809010355.615F41A144@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.50.59] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01A4_01CD75B0.813D6230" MIME-Version: 1.0 Cc: "shanna@juniper.net" , "sacm@ietf.org" Subject: Re: [sacm] Legal aspects of System 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, 09 Aug 2012 01:55:25 -0000 ------=_NextPart_000_01A4_01CD75B0.813D6230 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Martin, What you state below was also expressed by what a German friend of mine clarified for me many years ago: In Germany, everything is forbidden unless a law says it is allowed. (whitelist) In the USA, everything is allowed unless a law says it is forbidden. (blacklist) I guess we feel we have a fundamental human right to freedom that is natural and not by government fiat. There is also a disconnect over when a company tells an employee not to put any PII on the system owned by the company, and the employee proceeds to do so anyway, it is somehow the company's fault if they detect that PII. Lastly, you are stating that Germany's laws apply globally and over-ride any other country's laws. I beg to differ. Cheers, Mike -----Original Message----- From: Martin Rex [mailto:mrex@sap.com] Sent: Wednesday, August 08, 2012 9:04 PM To: Michael Hammer Cc: mrex@sap.com; shanna@juniper.net; sacm@ietf.org Subject: Re: [sacm] Legal aspects of System monitoring Michael Hammer wrote: > This totally ignores the reality of how systems, services, and > particularly Cloud works today. Nope. Some of the cloud services seem to be ignorant of the legal setting in which some of their (alleged) target customers operate, probably because of a lack of legal protections&requirements in the countries where the cloud providers themselves operate. >From the business perspective of cloud providers this might be perfectly resonable conduct in _their_ jurisdiction. > > Makes me wonder if those lawyers ever used Gmail. I'm not talking about unsubstantiated laywer opionions here, I'm talking about real, applicable statutes and past decisions of the German Federal Courts and the Federal Constitutional Court, i.e our highest appellate courts. > > So, I guess you are saying that as long as all the data and processing > occurs on a company server (aka in a Cloud), then it is ok to monitor > all they want. :) When user behaviour/conduct and user data is not monitored, then the constitutional protections do not apply, independent of where the server is located. Cloud or local server is a completely irrelevant technical implementation detail for deciding which PII can be legally monitored (collected, processed and used by someone else than the data subject and for which purposes) and which information can not. This is why it will be illegal to outsource storage&processing of data, that is subject to data protection law (respectively the european data protection directive) to cloud offerings that are operating outside of a jurisdiction with comparable strict data protection statutes as in the EU, unless each individual data subject that is affected voluntarily agrees. For data that an employer collects about its employees in Germany, Art. 75 (2) BetrVG requires that the principle of proportionality is satisfied even when all affected employees would voluntarily agree. There seems to be a thorough misunderstanding of how the constitutional protections of fundamental rights in German Basic Law work. These constitutional protections are provided in an abstract fashion, and require a _white-listing_ with statutes from a parlamentarian legislator (federal or state) that must narrowly define which encroachments of the fundamental rights are to be legal under which preconditions, PLUS, when it is about collecting PII, the statute must list the exact purposes for which the information may be legally used. Criminal statutes are a _black-listing_ approach (and need to be, that is a requirement in most constitutions and the european human rights convention). The problem with black-listing is, that it can often be evaded / worked around. When a legislater wants to provide a reliable protection of rights, then a sensible statue will contain a very broad "this is illegal unless explictly permitted by some other statute" provision (=the basis for white-listing) along with several narrow definitions of puishable crimes (black_listing). The reason is obvious: legal weasels will find ways to evade the black-listing. This is where the white-listing requirement comes in as backup. While not permitting any direct punishment, a broad "this is illegal unless..." white-listing requirement provides sufficient grounds for temporary and permanent injunctions (which themselves can be backed by punishments). When a customer of a large German ISP with a flatrate DSL subscription realized that the ISP was keeping records of the DHCP assignments of the temporary IPv4 address on the external interface of the DSL customers router for several months, he demanded from the ISP to delete this information in a timely fashion when it is no longer used, because it is PII, and holding on to this information is not explicitly permitted by the exemptions of the TKG (german federal telecommunications act) unless it is necessary for billing. Billing a flatrate subscription does not require that assignment. The ISP denied the request and the customer sued. The court ordered an injunction that the ISP must delete the data in a timely fashion (14 days). The ISP appealed, the appeal was rejected, and the injuction was backed with a two-stage punishment for further non-compliance, a fine of Euro 100k and if that doesn't work. a 6 month prison term for the active CEO. http://www.heise.de/newsticker/meldung/T-Online-darf-nur-fuer-Rechnung-noeti ge-Verbindungsdaten-speichern-168803.html The Federal Court of Justice rejected the second appeal by the ISP (on formal grounds). http://www.kein1984.de/bgh-entscheidung.pdf There is no doubt that criminal statutes are a better deterrent, but that doesn't mean that the "this is illegal, unless ..." provisions would not work. Injunctions can be backed by convincing punishments, where necessary. I assume that these can be quite effective motivators for corporate entities to comply. Though it can sometimes be a tedious process to get a decision and hopefully an injunction. For comparison, the criminal proceedings of an illegal surveillance (monitoring of phone records of ~60 individuals) trying to find an information leak, as summarized on Wikipedia, resulted in one manager getting a 3.5 year prison term. Several of the (technical) folks, who were involved in actually monitoring the phone records, had to pay fines in the Eur 5k-10k range, on the premise that they were just following order and not aware to be actively commiting crimes. Two Ex-CEOs made a settlement with the company, paying Eur 600.000 each. http://de.wikipedia.org/wiki/%C3%9Cberwachungsaff%C3%A4re_der_Deutschen_Tele kom -Martin ------=_NextPart_000_01A4_01CD75B0.813D6230 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgw OTAxNTUyMFowIwYJKoZIhvcNAQkEMRYEFKH6jdckrYD8Pp+PFIiX9Yz8vDeaMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGA5fNSU5OsxmFeCa27Y800goTvIDAgg6LrNrtu/+dpsgSe 4Id7ckKjkB6x5zUlc5juwQrBWn9N7tStZZcw/aIsbHhmTYpishkaABqukp2PpLZTRhbV2EID9h8k AdaR9iO4mRvU/LCe7ZOnrysuabR5/KvOkxHLTWEuPyyOI1x7lRYAAAAAAAA= ------=_NextPart_000_01A4_01CD75B0.813D6230-- From mrex@sap.com Wed Aug 8 21:01:57 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 A745221F854D for ; Wed, 8 Aug 2012 21:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.172 X-Spam-Level: X-Spam-Status: No, score=-10.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVULr84z6Dyg for ; Wed, 8 Aug 2012 21:01:56 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2737C21F854A for ; Wed, 8 Aug 2012 21:01:55 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q7941prr007035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Aug 2012 06:01:52 +0200 (MEST) In-Reply-To: <00C069FD01E0324C9FFCADF539701DB30B911353@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer Date: Thu, 9 Aug 2012 06:01:50 +0200 (CEST) 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: <20120809040150.C09981A144@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "mrex@sap.com" , "sacm@ietf.org" , "anton@chuvakin.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: Thu, 09 Aug 2012 04:01:57 -0000 Michael Hammer wrote: > > Your conflating two distinct things, Nope, but you're still ignoring the differences between the US legal system and the German legal system. > > what is done outside of work and what occurs > during work just confuses the issues. Nope. In Germany, dignity and personality rights are fundamental basic human rights, inseperable from the individual. You do not have to deposit them in a jar and leave it with the security guard at the entrance when you come to work, to pick it back up when you leave. > > Second, we are not talking > personal equipment here, but company equipment and systems. Nope, we are talking about collecting and processing PII data. Who owns which parts of the computing equipments that are involved in collecting the PII data is almost completely irrelevant (in Germany!). You're still wandering in the black-listing forest. PII is kind of an intangible asset to be owned and controlled by the data subject. Other intangible assets, for example copyrighted works, also do not change ownership as an implicit side effect of being copied to a physical media that does not belong to the copyright owner. But then, the US notion of copyright also lacks the concept of the author/creator personality rights, in particular the Art12 UrhG privilege, which is an integral part of the German copyright, and non-transferable except by inheritance after death, so elaborating on the copyright analogy might easily lead down the same rathole if one is stuck to the US copyright concept. http://www.gesetze-im-internet.de/urhg/BJNR012730965.html#BJNR012730965BJNG000701377 ISPs, mobile phone, landline, VoiP, Mailhoster and an employer supplying telecommunication equipment to employees are all subject to the telecommunication confidentiality protection from Article 10.1 of the Basic Law (Grundgesetz). They obtain no rights to the information that traverses their systems or in stored on them, whether it is Voice Mailbox, SMS, Email, fax, whatever, when they're subject to German jurisdiction. What these entities may legally do with the data while it is stored on or traversing their equipment, and what actions are criminal offences, is largely described in the German telecommunications act (TKG), Art. 88ff. http://www.gesetze-im-internet.de/tkg_2004/BJNR119000004.html#BJNR119000004BJNG001800000 -Martin From dcougias@netfrontiers.com Wed Aug 8 22:20: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 86FE221E8053 for ; Wed, 8 Aug 2012 22:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Wthc9EAw0Dn for ; Wed, 8 Aug 2012 22:20:33 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD27111E8196 for ; Wed, 8 Aug 2012 22:20:33 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so294953pbb.31 for ; Wed, 08 Aug 2012 22:20:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:reply-to:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:user-agent:x-mailer:x-gm-message-state; bh=cjdTylvRZ76zB/JsMoblBxre+yJMYqVZTmSyK3nGhqA=; b=fnn54bL7DZeFcrJzpPw50RzLt5MGZJ7ZPt0nE4qcOfg9DYL/fgpLSvEQeCyhPLGdyv S6fmlUPZ4q0sjj2K7+3TDbkJmKqJn+5eCW3NiRxaCvMqSrw8uYrlTTrtZABWYw27dDMH mEeZsYQL/91b4lsUyS9swbUzDy9E9vlASoEuyf/ucCKiM9Vj/EiOehIDZbVYqnzqH/33 0lu+flBXWY3FpwITmEB1B5svtexBMyIWMIQVgi9o+Na3GmErt7ntfVzNk6Ubi/oJBWh2 GngmRDWIwg1pMENRRo/nWLGWO7zz5ESdE2LN2PqXiGsuhWB5zYFrItr9BK5+SxSN7R+9 hi2Q== Received: by 10.68.216.130 with SMTP id oq2mr1070941pbc.128.1344489632350; Wed, 08 Aug 2012 22:20:32 -0700 (PDT) Received: from sender1.zohomail.com (sender1.zohomail.com. [72.5.230.103]) by mx.google.com with ESMTPS id ro7sm403005pbc.8.2012.08.08.22.20.31 (version=SSLv3 cipher=OTHER); Wed, 08 Aug 2012 22:20:31 -0700 (PDT) Date: Wed, 08 Aug 2012 22:20:30 -0700 From: Dorian Cougias To: Message-ID: <13909d3ab47.-5115805132147148239.9049257756692791623@netfrontiers.com> In-Reply-To: <5AB51D51-9781-4056-BAA9-86332F30D22E@c3isecurity.com> References: <5AB51D51-9781-4056-BAA9-86332F30D22E@c3isecurity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_49826_1053857104.1344489630534" User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Gm-Message-State: ALoCoQk9+XmuZvuEmWdETWyEkYlwvaKe/j/31vIFlw7HuLraFt9W64rHqo6oWKnKmouKIXfmMJTq Cc: Ruben Oliva , mile@ietf.org, dcougias@netfrontiers.com, "David A." , sacm@ietf.org Subject: Re: [sacm] =?utf-8?q?Strategic_alignment_of_security_with_business_in?= =?utf-8?q?_SACM_in=C2=A0=C2=A0=C2=A0=C2=A0an_international_context?= X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcougias@netfrontiers.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, 09 Aug 2012 05:20:35 -0000 ------=_Part_49826_1053857104.1344489630534 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit ------=_Part_49826_1053857104.1344489630534 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Yes, the UCF is fully copyrighted. However, we make specific wr= itten allowances.



Dorian J. Cou= gias
Compliance Scientist
Unified Compliance Framework<= /div>

---- On Wed, 08 Aug 2012 14:48:07 -0700 lnunez@c3isecurity.com wrote -= ---
I would be interested in reviewing a copy.



BTW = are there any IPR attached to the UCF document.



Thanks d= orian.



-ln

On Aug 8, 2012, at 2:55 PM, Dorian C= ougias wrote:



> The UCF will provide a common mapping= for you, with unique and persistent IDs.

>

> I ca= n provide UCF spreadsheets to those of you who need them.

>
>

>

> Dorian J. Cougias

> C= ompliance Scientist

> Unified Compliance Framework

>= ;



------=_Part_49826_1053857104.1344489630534-- From dcougias@netfrontiers.com Wed Aug 8 22:20:39 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A3621E8054 for ; Wed, 8 Aug 2012 22:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYTHiMhcgd8J for ; Wed, 8 Aug 2012 22:20:39 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2994521E8048 for ; Wed, 8 Aug 2012 22:20:39 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id rr4so294953pbb.31 for ; Wed, 08 Aug 2012 22:20:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:reply-to:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:user-agent:x-mailer:x-gm-message-state; bh=DmS5q0L3WsxqeCdkF8GoOWkIs0fxkBk2BT2tH79fm4w=; b=EcmWX3gWjkHiwGt/P/bECQITkb2SxxTPg1gAq9sv/liUoXtVQqfeeqrkgp/8RlTzhi hf2mpSEoNR4E1hvJsYhxz4D5pFx/NesHA8HtbHhvAyOviAArmB6BbMXY0Ph3Wj3whzfL EFHZaoXiBV0yT15fsd4PapUfocQ7hTxfBgKn/BVGs5TZNdFpsimfn0bigZFw8ffGy2wO wmKcySjPtE5fbG8ZiahutKY/LKeamWRcFCIfWTyXArPxOlna4FoSNMkXLvdrzxnx5lXz Oh6Wlahbn1eLhFOgoLiHVjNLrNppSndaFTYjODst3FEouu5mePpSGYSMLY5iuGGcaDOU tGkw== Received: by 10.66.88.198 with SMTP id bi6mr39110793pab.23.1344489639001; Wed, 08 Aug 2012 22:20:39 -0700 (PDT) Received: from sender1.zohomail.com (sender1.zohomail.com. [72.5.230.103]) by mx.google.com with ESMTPS id os2sm400910pbc.16.2012.08.08.22.20.38 (version=SSLv3 cipher=OTHER); Wed, 08 Aug 2012 22:20:38 -0700 (PDT) Date: Wed, 08 Aug 2012 22:20:37 -0700 From: Dorian Cougias To: Message-ID: <13909d3c6f5.6849302158992868120.-1337740793655790815@netfrontiers.com> In-Reply-To: <5AB51D51-9781-4056-BAA9-86332F30D22E@c3isecurity.com> References: <5AB51D51-9781-4056-BAA9-86332F30D22E@c3isecurity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_50636_1477024047.1344489637620" User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Gm-Message-State: ALoCoQlyfnswYi5uSP3RsloFqwOL334Sx7z98mLWmDLBs5TAD5iTXSxSp+v5/lpLylTbgPUvpJ8V Cc: Ruben Oliva , mile@ietf.org, dcougias@netfrontiers.com, "David A." , sacm@ietf.org Subject: Re: [sacm] =?utf-8?q?Strategic_alignment_of_security_with_business_in?= =?utf-8?q?_SACM_in=C2=A0=C2=A0=C2=A0=C2=A0an_international_context?= X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcougias@netfrontiers.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, 09 Aug 2012 05:20:40 -0000 ------=_Part_50636_1477024047.1344489637620 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit ------=_Part_50636_1477024047.1344489637620 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Yes, the UCF is fully copyrighted. However, we make specific wr= itten allowances.



Dorian J. Cou= gias
Compliance Scientist
Unified Compliance Framework<= /div>

---- On Wed, 08 Aug 2012 14:48:07 -0700 lnunez@c3isecurity.com wrote -= ---
I would be interested in reviewing a copy.



BTW = are there any IPR attached to the UCF document.



Thanks d= orian.



-ln

On Aug 8, 2012, at 2:55 PM, Dorian C= ougias wrote:



> The UCF will provide a common mapping= for you, with unique and persistent IDs.

>

> I ca= n provide UCF spreadsheets to those of you who need them.

>
>

>

> Dorian J. Cougias

> C= ompliance Scientist

> Unified Compliance Framework

>= ;



------=_Part_50636_1477024047.1344489637620-- From mrex@sap.com Thu Aug 9 01:15: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 AE0E121F84DC for ; Thu, 9 Aug 2012 01:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.173 X-Spam-Level: X-Spam-Status: No, score=-10.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeA1U7KOzsVz for ; Thu, 9 Aug 2012 01:15:51 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id C229421F859A for ; Thu, 9 Aug 2012 01:15:50 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q798FmCs015991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Aug 2012 10:15:48 +0200 (MEST) In-Reply-To: <00C069FD01E0324C9FFCADF539701DB30B9179FC@ex2k10mb2.corp.yaanatech.com> To: Michael Hammer Date: Thu, 9 Aug 2012 10:15:48 +0200 (CEST) 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: <20120809081548.22D1D1A145@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "shanna@juniper.net" , "mrex@sap.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: Thu, 09 Aug 2012 08:15:52 -0000 Michael Hammer wrote: > > Lastly, you are stating that Germany's laws apply globally and over-ride any > other country's laws. > I beg to differ. I actually did not mean to say or imply that. I would appreciate when you could quote the relevant text that you interpreted in that fashion so that I can try to improve my communication skills on legalese issues. (I'm native german and a novice in english/US legalese terminology). > > There is also a disconnect over when a company tells an employee not to put > any PII on the system owned by the company, I'm beginning to understand that the confusion is coming from a terminology misunderstanding. Either the US term "PII" refers to just an insignificant small subset of what is called PII in Europe, or the existing descriptions of what it means are just thoroughly confusing and misleading. Data protection is even more about control (who gets to know what about a data subject), than it is about confidentiality. And it encompasses all information "ANY information related to", not just the identifier (name) and the few example attributes that are typically quoted such as address, date-of-birth, gender, religion, ethnic origin. Quoting from the english version of the European Data Protection Directive: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:en:NOT For the purposes of this Directive: (a) 'personal data' shall mean any information relating to an identified or identifiable natural person ('data subject'); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity; PII includes - every single datum that an individual creates, every keypress, every mouse-move, even the length of the pauses between keypresses, body movements (breathing, twinkle, ...) - every datum that is (or can be with moderate effort) directly or indirectly related to an individual describing characteristics of the individual, showing actions/activities, opinions, thoughts > > and the employee proceeds to do so anyway, > it is somehow the company's fault if they detect that PII. It is impossible for an individual to create information that is *NOT* PII. It may be possible to anonymize PII after its creation, or at least ensure that it is re-distributed in anonymized fashion, but reliable anonymization may sometimes turn out to be difficult in reality. And not necessarily wanted. -Martin PS: and if you're wondering how this interacts with copyright, and whether there is some kind of "automatic" transfer of ownership of copyrights based on an employment contract, that is a very long and different story, there are specific statues which kinds of rights on which kinds of works are transfered by an employment contract, and at least in Germany the non-transferable "publication privilege" from the author/creator personality right in Germany's copyright statute (Art 12 (1) UrhG) precludes any automatic transfer, and transfer of rights on contents of non-public telecommunication is a seperate can of worms. From mrex@sap.com Thu Aug 9 01:32:55 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF2821F85D8 for ; Thu, 9 Aug 2012 01:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.174 X-Spam-Level: X-Spam-Status: No, score=-10.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxxowLxWJylu for ; Thu, 9 Aug 2012 01:32:54 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5197721F85D2 for ; Thu, 9 Aug 2012 01:32:54 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q798WqIU017618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Aug 2012 10:32:52 +0200 (MEST) In-Reply-To: <502281A9.8020800@yaanatech.com> To: tony@yaanatech.com Date: Thu, 9 Aug 2012 10:32:52 +0200 (CEST) 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: <20120809083252.2312E1A145@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: david.oliva@verizon.net, lnunez@c3isecurity.com, sacm@ietf.org Subject: Re: [sacm] Strategic alignment of security with business in SACM in an international context 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: Thu, 09 Aug 2012 08:32:55 -0000 Tony Rutkowski wrote: > > Could you provide a copy of ISO 27001 so we could > take a look at it? ISO (and all of its national member organizations) are "traditional" standardization developing organizations (SDOs) that are in the publishing business. i.e. a non-marginal part of their budget is from selling copies of their standards (and the national member bodies may offer translations as well). I believe the selling price is (or once was) calculated from number of pages. -Martin From david.oliva@verizon.net Thu Aug 9 05:58: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 BCFAF21F86BD; Thu, 9 Aug 2012 05:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.381 X-Spam-Level: X-Spam-Status: No, score=-0.381 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XT5JaYIrhGdN; Thu, 9 Aug 2012 05:58:05 -0700 (PDT) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C5221F86A8; Thu, 9 Aug 2012 05:58:04 -0700 (PDT) Received: from vms170025pub.verizon.net ([unknown] [192.168.1.3]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M8H00JP7O0DJ8IX@vms173001.mailsrvcs.net>; Thu, 09 Aug 2012 07:57:49 -0500 (CDT) Received: from 96.241.55.45 ([96.241.55.45]) by vms170025 (Verizon Webmail) with HTTP; Thu, 09 Aug 2012 07:57:49 -0500 (CDT) Date: Thu, 09 Aug 2012 07:57:49 -0500 (CDT) From: david.oliva@verizon.net To: dcougias@netfrontiers.com, lnunez@c3isecurity.com Message-id: <23623150.93912.1344517069256.JavaMail.root@vms170025> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7bit X-Mailer: Verizon Webmail X-Originating-IP: [96.241.55.45] Cc: david.oliva@verizon.net, mile@ietf.org, david.waltermire@nist.gov, sacm@ietf.org Subject: Re: [sacm] =?utf-8?q?Strategic_alignment_of_security_with_business_in?= =?utf-8?q?_SACM_in=C2=A0=C2=A0=C2=A0=C2=A0an_international_context?= X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 09 Aug 2012 12:58:06 -0000
Phenomenal!
 
Can you please send me (us) one?
 
David Oliva
 
 
On 08/08/12, Dorian Cougias<dcougias@netfrontiers.com> wrote:
 
The UCF will provide a common mapping for you, with unique and persistent IDs.

I can provide UCF spreadsheets to those of you who need them.



Dorian J. Cougias
Compliance Scientist
Unified Compliance Framework

From david.waltermire@nist.gov Thu Aug 9 06:06:39 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E6021F86C8; Thu, 9 Aug 2012 06:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.034 X-Spam-Level: X-Spam-Status: No, score=-6.034 tagged_above=-999 required=5 tests=[AWL=-0.388, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJhmReWHhCSn; Thu, 9 Aug 2012 06:06:34 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 7529321F8687; Thu, 9 Aug 2012 06:06:33 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 9 Aug 2012 09:06:24 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 9 Aug 2012 09:06:31 -0400 From: "Waltermire, David A." To: "'david.oliva@verizon.net'" , "'dcougias@netfrontiers.com'" , "'lnunez@c3isecurity.com'" Date: Thu, 9 Aug 2012 09:05:05 -0400 Thread-Topic: =?utf-8?B?UmU6IFtzYWNtXSBTdHJhdGVnaWMgYWxpZ25tZW50IG9mIHNlY3VyaXR5IHc=?= =?utf-8?B?aXRoIGJ1c2luZXNzIGluIFNBQ00gaW7CoMKgwqDCoGFuIGludGVybmF0aW9u?= =?utf-8?B?YWwgY29udGV4dA==?= Thread-Index: Ac12LmGvLHtvzMKtTl6y2SOAWBZV3wAATaxu Message-ID: In-Reply-To: <23623150.93912.1344517069256.JavaMail.root@vms170025> 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_D7A0423E5E193F40BE6E94126930C4930B9F5B7E79MBCLUSTERxcha_" MIME-Version: 1.0 Cc: "'mile@ietf.org'" , "'sacm@ietf.org'" Subject: Re: [sacm] =?utf-8?q?Strategic_alignment_of_security_with_business_in?= =?utf-8?q?_SACM_in=C2=A0=C2=A0=C2=A0=C2=A0an_international_context?= X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 09 Aug 2012 13:06:39 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E79MBCLUSTERxcha_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogZGF2aWQub2xpdmFA dmVyaXpvbi5uZXQgPGRhdmlkLm9saXZhQHZlcml6b24ubmV0Pg0KVG86IGRjb3VnaWFzQG5ldGZy b250aWVycy5jb20gPGRjb3VnaWFzQG5ldGZyb250aWVycy5jb20+OyBsbnVuZXpAYzNpc2VjdXJp dHkuY29tIDxsbnVuZXpAYzNpc2VjdXJpdHkuY29tPg0KQ2M6IFdhbHRlcm1pcmUsIERhdmlkIEEu OyBkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldCA8ZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ+OyBtaWxl QGlldGYub3JnIDxtaWxlQGlldGYub3JnPjsgc2FjbUBpZXRmLm9yZyA8c2FjbUBpZXRmLm9yZz4N ClNlbnQ6IFRodSBBdWcgMDkgMDg6NTc6NDkgMjAxMg0KU3ViamVjdDogUmU6IFJlOiBbc2FjbV0g U3RyYXRlZ2ljIGFsaWdubWVudCBvZiBzZWN1cml0eSB3aXRoIGJ1c2luZXNzIGluIFNBQ00gaW4g ICAgYW4gaW50ZXJuYXRpb25hbCBjb250ZXh0DQoNClBoZW5vbWVuYWwhDQoNCkNhbiB5b3UgcGxl YXNlIHNlbmQgbWUgKHVzKSBvbmU/DQoNCkRhdmlkIE9saXZhDQoNCg0KT24gMDgvMDgvMTIsIERv cmlhbiBDb3VnaWFzPGRjb3VnaWFzQG5ldGZyb250aWVycy5jb20+IHdyb3RlOg0KDQpUaGUgVUNG IHdpbGwgcHJvdmlkZSBhIGNvbW1vbiBtYXBwaW5nIGZvciB5b3UsIHdpdGggdW5pcXVlIGFuZCBw ZXJzaXN0ZW50IElEcy4NCg0KSSBjYW4gcHJvdmlkZSBVQ0Ygc3ByZWFkc2hlZXRzIHRvIHRob3Nl IG9mIHlvdSB3aG8gbmVlZCB0aGVtLg0KDQoNCg0KRG9yaWFuIEouIENvdWdpYXMNCkNvbXBsaWFu Y2UgU2NpZW50aXN0DQpVbmlmaWVkIENvbXBsaWFuY2UgRnJhbWV3b3JrDQoNCg== --_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E79MBCLUSTERxcha_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGRpdj48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPg0KSTwvZm9udD48L2Rpdj4N Cjxicj48ZGl2PjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0YWJpbmRleD0t MT4NCjxmb250IGZhY2U9VGFob21hIHNpemU9Mj4NCjxiPkZyb208L2I+OiBkYXZpZC5vbGl2YUB2 ZXJpem9uLm5ldCAmbHQ7ZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQmZ3Q7DTxicj48Yj5UbzwvYj46 IGRjb3VnaWFzQG5ldGZyb250aWVycy5jb20gJmx0O2Rjb3VnaWFzQG5ldGZyb250aWVycy5jb20m Z3Q7OyBsbnVuZXpAYzNpc2VjdXJpdHkuY29tICZsdDtsbnVuZXpAYzNpc2VjdXJpdHkuY29tJmd0 Ow08YnI+PGI+Q2M8L2I+OiBXYWx0ZXJtaXJlLCBEYXZpZCBBLjsgZGF2aWQub2xpdmFAdmVyaXpv bi5uZXQgJmx0O2RhdmlkLm9saXZhQHZlcml6b24ubmV0Jmd0OzsgbWlsZUBpZXRmLm9yZyAmbHQ7 bWlsZUBpZXRmLm9yZyZndDs7IHNhY21AaWV0Zi5vcmcgJmx0O3NhY21AaWV0Zi5vcmcmZ3Q7DTxi cj48Yj5TZW50PC9iPjogVGh1IEF1ZyAwOSAwODo1Nzo0OSAyMDEyPGJyPjxiPlN1YmplY3Q8L2I+ OiBSZTogUmU6IFtzYWNtXSBTdHJhdGVnaWMgYWxpZ25tZW50IG9mIHNlY3VyaXR5IHdpdGggYnVz aW5lc3MgaW4gU0FDTSBpbsKgwqDCoMKgYW4gaW50ZXJuYXRpb25hbCBjb250ZXh0DTxicj48L2Zv bnQ+PGJyPjwvZGl2Pg0KPGRpdiBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsOyBDT0xPUjogIzAw MDAwMDsgRk9OVC1TSVpFOiAxMnB4Ij48RElWPlBoZW5vbWVuYWwhPC9ESVY+PERJVj4mbmJzcDs8 L0RJVj48RElWPkNhbiB5b3UgcGxlYXNlIHNlbmQgbWUgKHVzKSBvbmU/PC9ESVY+PERJVj4mbmJz cDs8L0RJVj48RElWPkRhdmlkIE9saXZhPC9ESVY+PERJVj4mbmJzcDs8L0RJVj48RElWPiZuYnNw OzwvRElWPjxESVYgc3R5bGU9Ik1BUkdJTjogNXB4IDBweDsgQk9SREVSLVRPUDogI2JjYmNiYyAx cHggc29saWQiPjwvRElWPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogYXJpYWw7IENPTE9SOiAj MDAwMDAwOyBGT05ULVNJWkU6IDEycHgiPk9uIDA4LzA4LzEyLCA8U1BBTj5Eb3JpYW4gQ291Z2lh cyZsdDtkY291Z2lhc0BuZXRmcm9udGllcnMuY29tJmd0OzwvU1BBTj4gd3JvdGU6PC9TUEFOPjxE SVY+Jm5ic3A7PC9ESVY+PERJViBzdHlsZT0iRk9OVC1GQU1JTFk6IGFyaWFsOyBDT0xPUjogIzAw MDAwMDsgRk9OVC1TSVpFOiAxMnB4Ij5UaGUgVUNGIHdpbGwgcHJvdmlkZSBhIGNvbW1vbiBtYXBw aW5nIGZvciB5b3UsIHdpdGggdW5pcXVlIGFuZCBwZXJzaXN0ZW50IElEcy48QlI+PEJSPkkgY2Fu IHByb3ZpZGUgVUNGIHNwcmVhZHNoZWV0cyB0byB0aG9zZSBvZiB5b3Ugd2hvIG5lZWQgdGhlbS48 QlI+PEJSPjxESVY+PEJSPjwvRElWPjxESVY+PEJSPjwvRElWPjxESVY+RG9yaWFuIEouIENvdWdp YXM8L0RJVj48RElWPkNvbXBsaWFuY2UgU2NpZW50aXN0PC9ESVY+PERJVj5VbmlmaWVkIENvbXBs aWFuY2UgRnJhbWV3b3JrPC9ESVY+PEJSPjwvRElWPjwvZGl2Pg0K --_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E79MBCLUSTERxcha_-- From david.waltermire@nist.gov Thu Aug 9 06:08:24 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C81A21F86D6; Thu, 9 Aug 2012 06:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=-0.374, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnE+emBCcL37; Thu, 9 Aug 2012 06:08:23 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 0557E21F86C8; Thu, 9 Aug 2012 06:08:22 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 9 Aug 2012 09:08:13 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 9 Aug 2012 09:08:20 -0400 From: "Waltermire, David A." To: "'david.oliva@verizon.net'" , "'dcougias@netfrontiers.com'" , "'lnunez@c3isecurity.com'" Date: Thu, 9 Aug 2012 09:06:53 -0400 Thread-Topic: =?utf-8?B?UmU6IFtzYWNtXSBTdHJhdGVnaWMgYWxpZ25tZW50IG9mIHNlY3VyaXR5IHc=?= =?utf-8?B?aXRoIGJ1c2luZXNzIGluIFNBQ00gaW7CoMKgwqDCoGFuIGludGVybmF0aW9u?= =?utf-8?B?YWwgY29udGV4dA==?= Thread-Index: Ac12LmGvLHtvzMKtTl6y2SOAWBZV3wAAXcIv Message-ID: In-Reply-To: <23623150.93912.1344517069256.JavaMail.root@vms170025> 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_D7A0423E5E193F40BE6E94126930C4930B9F5B7E7AMBCLUSTERxcha_" MIME-Version: 1.0 Cc: "'mile@ietf.org'" , "'sacm@ietf.org'" Subject: Re: [sacm] =?utf-8?q?Strategic_alignment_of_security_with_business_in?= =?utf-8?q?_SACM_in=C2=A0=C2=A0=C2=A0=C2=A0an_international_context?= X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 09 Aug 2012 13:08:24 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E7AMBCLUSTERxcha_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkuIEZhdCBmaW5nZXJlZCBzZW5kLiBJdCBtaWdodCBiZSBiZXN0IHRvIGtlZXAgYW55IGNv cHlyaWdodGVkIG1hdGVyaWFsIG9mZiB0aGUgbGlzdCwgdW5sZXNzIGl0IGlzIGJlaW5nIGNvbnRy aWJ1dGVkIHRvIHRoZSBJRVRGIGFzIGFuIEkvRC4NCg0KVGhhbmtzLA0KRGF2ZQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQg PGRhdmlkLm9saXZhQHZlcml6b24ubmV0Pg0KVG86IGRjb3VnaWFzQG5ldGZyb250aWVycy5jb20g PGRjb3VnaWFzQG5ldGZyb250aWVycy5jb20+OyBsbnVuZXpAYzNpc2VjdXJpdHkuY29tIDxsbnVu ZXpAYzNpc2VjdXJpdHkuY29tPg0KQ2M6IFdhbHRlcm1pcmUsIERhdmlkIEEuOyBkYXZpZC5vbGl2 YUB2ZXJpem9uLm5ldCA8ZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ+OyBtaWxlQGlldGYub3JnIDxt aWxlQGlldGYub3JnPjsgc2FjbUBpZXRmLm9yZyA8c2FjbUBpZXRmLm9yZz4NClNlbnQ6IFRodSBB dWcgMDkgMDg6NTc6NDkgMjAxMg0KU3ViamVjdDogUmU6IFJlOiBbc2FjbV0gU3RyYXRlZ2ljIGFs aWdubWVudCBvZiBzZWN1cml0eSB3aXRoIGJ1c2luZXNzIGluIFNBQ00gaW4gICAgYW4gaW50ZXJu YXRpb25hbCBjb250ZXh0DQoNClBoZW5vbWVuYWwhDQoNCkNhbiB5b3UgcGxlYXNlIHNlbmQgbWUg KHVzKSBvbmU/DQoNCkRhdmlkIE9saXZhDQoNCg0KT24gMDgvMDgvMTIsIERvcmlhbiBDb3VnaWFz PGRjb3VnaWFzQG5ldGZyb250aWVycy5jb20+IHdyb3RlOg0KDQpUaGUgVUNGIHdpbGwgcHJvdmlk ZSBhIGNvbW1vbiBtYXBwaW5nIGZvciB5b3UsIHdpdGggdW5pcXVlIGFuZCBwZXJzaXN0ZW50IElE cy4NCg0KSSBjYW4gcHJvdmlkZSBVQ0Ygc3ByZWFkc2hlZXRzIHRvIHRob3NlIG9mIHlvdSB3aG8g bmVlZCB0aGVtLg0KDQoNCg0KRG9yaWFuIEouIENvdWdpYXMNCkNvbXBsaWFuY2UgU2NpZW50aXN0 DQpVbmlmaWVkIENvbXBsaWFuY2UgRnJhbWV3b3JrDQoNCg== --_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E7AMBCLUSTERxcha_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGRpdj48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPg0KU29ycnkuICBGYXQgZmlu Z2VyZWQgc2VuZC4gIEl0IG1pZ2h0IGJlIGJlc3QgdG8ga2VlcCBhbnkgY29weXJpZ2h0ZWQgbWF0 ZXJpYWwgb2ZmIHRoZSBsaXN0LCB1bmxlc3MgaXQgaXMgYmVpbmcgY29udHJpYnV0ZWQgdG8gdGhl IElFVEYgYXMgYW4gSS9ELjxicj48YnI+VGhhbmtzLDxicj5EYXZlPC9mb250PjwvZGl2Pg0KPGJy PjxkaXY+PGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRhYmluZGV4PS0xPg0K PGZvbnQgZmFjZT1UYWhvbWEgc2l6ZT0yPg0KPGI+RnJvbTwvYj46IGRhdmlkLm9saXZhQHZlcml6 b24ubmV0ICZsdDtkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldCZndDsNPGJyPjxiPlRvPC9iPjogZGNv dWdpYXNAbmV0ZnJvbnRpZXJzLmNvbSAmbHQ7ZGNvdWdpYXNAbmV0ZnJvbnRpZXJzLmNvbSZndDs7 IGxudW5lekBjM2lzZWN1cml0eS5jb20gJmx0O2xudW5lekBjM2lzZWN1cml0eS5jb20mZ3Q7DTxi cj48Yj5DYzwvYj46IFdhbHRlcm1pcmUsIERhdmlkIEEuOyBkYXZpZC5vbGl2YUB2ZXJpem9uLm5l dCAmbHQ7ZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQmZ3Q7OyBtaWxlQGlldGYub3JnICZsdDttaWxl QGlldGYub3JnJmd0Ozsgc2FjbUBpZXRmLm9yZyAmbHQ7c2FjbUBpZXRmLm9yZyZndDsNPGJyPjxi PlNlbnQ8L2I+OiBUaHUgQXVnIDA5IDA4OjU3OjQ5IDIwMTI8YnI+PGI+U3ViamVjdDwvYj46IFJl OiBSZTogW3NhY21dIFN0cmF0ZWdpYyBhbGlnbm1lbnQgb2Ygc2VjdXJpdHkgd2l0aCBidXNpbmVz cyBpbiBTQUNNIGluwqDCoMKgwqBhbiBpbnRlcm5hdGlvbmFsIGNvbnRleHQNPGJyPjwvZm9udD48 YnI+PC9kaXY+DQo8ZGl2IHN0eWxlPSJGT05ULUZBTUlMWTogQXJpYWw7IENPTE9SOiAjMDAwMDAw OyBGT05ULVNJWkU6IDEycHgiPjxESVY+UGhlbm9tZW5hbCE8L0RJVj48RElWPiZuYnNwOzwvRElW PjxESVY+Q2FuIHlvdSBwbGVhc2Ugc2VuZCBtZSAodXMpIG9uZT88L0RJVj48RElWPiZuYnNwOzwv RElWPjxESVY+RGF2aWQgT2xpdmE8L0RJVj48RElWPiZuYnNwOzwvRElWPjxESVY+Jm5ic3A7PC9E SVY+PERJViBzdHlsZT0iTUFSR0lOOiA1cHggMHB4OyBCT1JERVItVE9QOiAjYmNiY2JjIDFweCBz b2xpZCI+PC9ESVY+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBhcmlhbDsgQ09MT1I6ICMwMDAw MDA7IEZPTlQtU0laRTogMTJweCI+T24gMDgvMDgvMTIsIDxTUEFOPkRvcmlhbiBDb3VnaWFzJmx0 O2Rjb3VnaWFzQG5ldGZyb250aWVycy5jb20mZ3Q7PC9TUEFOPiB3cm90ZTo8L1NQQU4+PERJVj4m bmJzcDs8L0RJVj48RElWIHN0eWxlPSJGT05ULUZBTUlMWTogYXJpYWw7IENPTE9SOiAjMDAwMDAw OyBGT05ULVNJWkU6IDEycHgiPlRoZSBVQ0Ygd2lsbCBwcm92aWRlIGEgY29tbW9uIG1hcHBpbmcg Zm9yIHlvdSwgd2l0aCB1bmlxdWUgYW5kIHBlcnNpc3RlbnQgSURzLjxCUj48QlI+SSBjYW4gcHJv dmlkZSBVQ0Ygc3ByZWFkc2hlZXRzIHRvIHRob3NlIG9mIHlvdSB3aG8gbmVlZCB0aGVtLjxCUj48 QlI+PERJVj48QlI+PC9ESVY+PERJVj48QlI+PC9ESVY+PERJVj5Eb3JpYW4gSi4gQ291Z2lhczwv RElWPjxESVY+Q29tcGxpYW5jZSBTY2llbnRpc3Q8L0RJVj48RElWPlVuaWZpZWQgQ29tcGxpYW5j ZSBGcmFtZXdvcms8L0RJVj48QlI+PC9ESVY+PC9kaXY+DQo= --_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E7AMBCLUSTERxcha_-- From david.oliva@verizon.net Thu Aug 9 06:15: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 34B1A21F867C for ; Thu, 9 Aug 2012 06:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.642 X-Spam-Level: X-Spam-Status: No, score=-0.642 tagged_above=-999 required=5 tests=[AWL=0.402, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JinPS3DvQoAl for ; Thu, 9 Aug 2012 06:15:01 -0700 (PDT) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by ietfa.amsl.com (Postfix) with ESMTP id 99C5321F8665 for ; Thu, 9 Aug 2012 06:15:01 -0700 (PDT) Received: from vms170025pub.verizon.net ([unknown] [192.168.1.3]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M8H00MHCOSJGRN1@vms173005.mailsrvcs.net> for sacm@ietf.org; Thu, 09 Aug 2012 08:14:43 -0500 (CDT) Received: from 96.241.55.45 ([96.241.55.45]) by vms170025 (Verizon Webmail) with HTTP; Thu, 09 Aug 2012 08:14:43 -0500 (CDT) Date: Thu, 09 Aug 2012 08:14:43 -0500 (CDT) From: david.oliva@verizon.net To: lnunez@c3isecurity.com Message-id: <33365097.95248.1344518083103.JavaMail.root@vms170025> 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.55.45] Cc: david.oliva@verizon.net, mrex@sap.com, sacm@ietf.org, tony@yaanatech.com Subject: Re: [sacm] Strategic alignment of security with business in SACM in an international context X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 09 Aug 2012 13:15:02 -0000
&nb= sp;
 Luis:
 
Is it possible that th= e IETF get a special multi-user license from ISO?
When I bou= ght my copy it cost around $125.00 and cannot share it.
I also di= scovered that ISO's standards change much faster then NIST's.
We= need the ISO/IEC 27001:2005 first edition (2005-10-15) beca= use that is what the SP 800-53 maps to.
 
David Ol= iva
 
 
 
On 08/09/12, Martin Rex= <mrex@sap.com> wrote:
 
Tony Rutkowski wrote:
= >
> Could you provide a copy of ISO 27001 so we could
> tak= e a look at it?

ISO (and all of its national member organizations)are "traditional" standardization developing organizations (SDOs)
that= are in the publishing business. i.e. a non-marginal part
of their budge= t is from selling copies of their standards
(and the national member bod= ies may offer translations as well).

I believe the selling price is = (or once was) calculated
from number of pages.

-Martin
<= /div> From tony@yaanatech.com Thu Aug 9 06:46:12 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B01021F8688; Thu, 9 Aug 2012 06:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM1QVy2wJp1m; Thu, 9 Aug 2012 06:46:12 -0700 (PDT) Received: from extmail1.prd.yaanatech.com (extmail1.prd.yaanatech.com [205.140.198.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2E03D21F8687; Thu, 9 Aug 2012 06:46:12 -0700 (PDT) Received: from [192.168.0.4] (pool-173-72-150-118.clppva.fios.verizon.net [173.72.150.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extmail1.prd.yaanatech.com (Postfix) with ESMTP id D62CD58081; Thu, 9 Aug 2012 13:46:10 +0000 (UTC) Message-ID: <5023BF21.6030205@yaanatech.com> Date: Thu, 09 Aug 2012 09:46:09 -0400 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: "Waltermire, David A." References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040907080601000108040801" Cc: "'david.oliva@verizon.net'" , "'lnunez@c3isecurity.com'" , "'mile@ietf.org'" , "'dcougias@netfrontiers.com'" , "'sacm@ietf.org'" Subject: Re: [sacm] =?iso-8859-1?q?=5Bmile=5D__Strategic_alignment_of_security?= =?iso-8859-1?q?_with_business_in_SACM_in=A0=A0=A0=A0an_international_cont?= =?iso-8859-1?q?ext?= 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: Thu, 09 Aug 2012 13:46:12 -0000 This is a multi-part message in MIME format. --------------040907080601000108040801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David, I don't think you really want to have such a requirement. Almost everything is explicitly or implicitly copyrighted. IETF material itself asserts a copyright. What is relevant is any restrictions associated with the copyright. It seems inappropriate for a technical body to effectively require a copyright analysis of everything potentially sent to a list. Work would cease. --tony On 8/9/2012 9:06 AM, Waltermire, David A. wrote: > Sorry. Fat fingered send. It might be best to keep any copyrighted > material off the list, unless it is being contributed to the IETF as > an I/D. --------------040907080601000108040801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
David,

I don't think you really want to have such a requirement.
Almost everything is explicitly or implicitly copyrighted.
IETF material itself asserts a copyright.  What is relevant
is any restrictions associated with the copyright.  It seems
inappropriate for a technical body to effectively require
a copyright analysis of everything potentially sent to a list.
Work would cease.

--tony


On 8/9/2012 9:06 AM, Waltermire, David A. wrote:
Sorry. Fat fingered send. It might be best to keep any copyrighted material off the list, unless it is being contributed to the IETF as an I/D.

--------------040907080601000108040801-- From david.oliva@verizon.net Thu Aug 9 06:55: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 375E421F8665 for ; Thu, 9 Aug 2012 06:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.733 X-Spam-Level: X-Spam-Status: No, score=0.733 tagged_above=-999 required=5 tests=[AWL=-1.089, BAYES_40=-0.185, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nw3RjMa5PyZZ for ; Thu, 9 Aug 2012 06:55:33 -0700 (PDT) Received: from vms173021pub.verizon.net (vms173021pub.verizon.net [206.46.173.21]) by ietfa.amsl.com (Postfix) with ESMTP id 99C9521F8650 for ; Thu, 9 Aug 2012 06:55:33 -0700 (PDT) Received: from vms170025pub.verizon.net ([unknown] [192.168.1.3]) by vms173021.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M8H001PKQOAYH3G@vms173021.mailsrvcs.net> for sacm@ietf.org; Thu, 09 Aug 2012 08:55:23 -0500 (CDT) Received: from 96.241.55.45 ([96.241.55.45]) by vms170025 (Verizon Webmail) with HTTP; Thu, 09 Aug 2012 08:55:22 -0500 (CDT) Date: Thu, 09 Aug 2012 08:55:22 -0500 (CDT) From: david.oliva@verizon.net To: sacm@ietf.org Message-id: <15316495.99085.1344520522988.JavaMail.root@vms170025> 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.55.45] Subject: [sacm] =?utf-8?q?SACM_in_support_of_=E2=80=9CAsset_management?= =?utf-8?q?=E2=80=9D_in_compliance_with_ISO_27001?= X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 09 Aug 2012 13:55:34 -0000

Luis and all:

The new SC= AP 1.2 (SACM) is adding two specifications (or formats for those who have a= bad taste of the term specification) associated with assets.  These specs are the Asset Identification = (AI) and Asset Reporting Format (ARF). &n= bsp;The three specifications which developers should use for this pu= rpose should be AI, ARF, and CPE (Common Platforms Enumeration).=

SACM Asset Management applications which map= their output to ISO 27001 sections A.7.1.1 =E2=80=9CInventory of Assets=E2= =80=9D, A.7.1.2 =E2=80=9COwnership of Assets=E2=80=9D, and A.7.1.3 =E2=80= =9CAcceptable use of assets=E2=80=9D will be of great appeal to internation= al business organizations.

Note al= so that, in general, asset management is not only a security issue, but a g= ood business practice issue as well. = ; Thus, the strategic objectives of security and business =E2=80=9Cg= et married =E2=80=9Cat this point.

=  

= David Oliva

From tonynad@microsoft.com Thu Aug 9 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 C218421F871E; Thu, 9 Aug 2012 07:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3EuoXIUVE1M; Thu, 9 Aug 2012 07:53:33 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8D021F871D; Thu, 9 Aug 2012 07:53:33 -0700 (PDT) Received: from mail248-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 9 Aug 2012 14:53:33 +0000 Received: from mail248-tx2 (localhost [127.0.0.1]) by mail248-tx2-R.bigfish.com (Postfix) with ESMTP id 2F4395C0105; Thu, 9 Aug 2012 14:53:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VS-20(z3e13hzbb2dI98dI9371Ic85dhzz1202h1082kzz8275ch1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah107ah) Received-SPF: pass (mail248-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail248-tx2 (localhost.localdomain [127.0.0.1]) by mail248-tx2 (MessageSwitch) id 1344524010811349_30640; Thu, 9 Aug 2012 14:53:30 +0000 (UTC) Received: from TX2EHSMHS029.bigfish.com (unknown [10.9.14.240]) by mail248-tx2.bigfish.com (Postfix) with ESMTP id B9A581BC0045; Thu, 9 Aug 2012 14:53:30 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS029.bigfish.com (10.9.99.129) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 9 Aug 2012 14:53:30 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.298.5; Thu, 9 Aug 2012 14:53:29 +0000 Received: from mail180-co1-R.bigfish.com (10.243.78.249) by CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id 14.1.225.23; Thu, 9 Aug 2012 14:53:28 +0000 Received: from mail180-co1 (localhost [127.0.0.1]) by mail180-co1-R.bigfish.com (Postfix) with ESMTP id BED7FC4026B; Thu, 9 Aug 2012 14:53:28 +0000 (UTC) Received: from mail180-co1 (localhost.localdomain [127.0.0.1]) by mail180-co1 (MessageSwitch) id 1344524006868813_19240; Thu, 9 Aug 2012 14:53:26 +0000 (UTC) Received: from CO1EHSMHS028.bigfish.com (unknown [10.243.78.254]) by mail180-co1.bigfish.com (Postfix) with ESMTP id C80622C0058; Thu, 9 Aug 2012 14:53:26 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS028.bigfish.com (10.243.66.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 9 Aug 2012 14:53:25 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.203]) by BL2PRD0310HT001.namprd03.prod.outlook.com ([10.255.97.36]) with mapi id 14.16.0175.005; Thu, 9 Aug 2012 14:53:25 +0000 From: Anthony Nadalin To: "tony@yaanatech.com" , "Waltermire, David A." Thread-Topic: =?iso-8859-1?Q?[sacm]_[mile]__Strategic_alignment_of_security_with_busine?= =?iso-8859-1?Q?ss_in_SACM_in=A0=A0=A0=A0an_international_context?= Thread-Index: AQHNdjVmI5aVfzU+bEGRQzPjkLgmxZdRj9kQ Date: Thu, 9 Aug 2012 14:53:24 +0000 Message-ID: References: <5023BF21.6030205@yaanatech.com> In-Reply-To: <5023BF21.6030205@yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.56] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9DCB06BL2PRD0310MB362_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%YAANATECH.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%NIST.GOV$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VERIZON.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%C3ISECURITY.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%NETFRONTIERS.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "'david.oliva@verizon.net'" , "'lnunez@c3isecurity.com'" , "'mile@ietf.org'" , "'dcougias@netfrontiers.com'" , "'sacm@ietf.org'" Subject: Re: [sacm] =?iso-8859-1?q?=5Bmile=5D__Strategic_alignment_of_security?= =?iso-8859-1?q?_with_business_in_SACM_in=A0=A0=A0=A0an_international_cont?= =?iso-8859-1?q?ext?= X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 09 Aug 2012 14:53:34 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9DCB06BL2PRD0310MB362_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think David is referring to the ISO type of document which is a pay per c= opy with various distribution restrictions, which I know you knew about bef= ore you asked for a copy on this list as you have complained about the ISO = documentation model many times in various fora. From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ton= y Rutkowski Sent: Thursday, August 09, 2012 6:46 AM To: Waltermire, David A. Cc: 'david.oliva@verizon.net'; 'lnunez@c3isecurity.com'; 'mile@ietf.org'; '= dcougias@netfrontiers.com'; 'sacm@ietf.org' Subject: Re: [sacm] [mile] Strategic alignment of security with business in= SACM in an international context David, I don't think you really want to have such a requirement. Almost everything is explicitly or implicitly copyrighted. IETF material itself asserts a copyright. What is relevant is any restrictions associated with the copyright. It seems inappropriate for a technical body to effectively require a copyright analysis of everything potentially sent to a list. Work would cease. --tony On 8/9/2012 9:06 AM, Waltermire, David A. wrote: Sorry. Fat fingered send. It might be best to keep any copyrighted material= off the list, unless it is being contributed to the IETF as an I/D. --_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9DCB06BL2PRD0310MB362_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I think David is referrin= g to the ISO type of document which is a pay per copy with various distribu= tion restrictions, which I know you knew about before you asked for a copy on this list as you have complained about the ISO documen= tation model many times in various fora.

 <= /p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.o= rg] On Behalf Of Tony Rutkowski
Sent: Thursday, August 09, 2012 6:46 AM
To: Waltermire, David A.
Cc: 'david.oliva@verizon.net'; 'lnunez@c3isecurity.com'; 'mile@ietf.= org'; 'dcougias@netfrontiers.com'; 'sacm@ietf.org'
Subject: Re: [sacm] [mile] Strategic alignment of security with busi= ness in SACM in    an international context<= /span>

 

David,

I don't think you really want to have such a requirement.
Almost everything is explicitly or implicitly copyrighted.
IETF material itself asserts a copyright.  What is relevant
is any restrictions associated with the copyright.  It seems
inappropriate for a technical body to effectively require
a copyright analysis of everything potentially sent to a list.
Work would cease.

--tony


On 8/9/2012 9:06 AM, Waltermire, David A. wrote:

Sorry. Fat fingered send. It m= ight be best to keep any copyrighted material off the list, unless it is be= ing contributed to the IETF as an I/D.

 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9DCB06BL2PRD0310MB362_-- From amontville@tripwire.com Thu Aug 9 09:06: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 0A90B21F87FC; Thu, 9 Aug 2012 09:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.644 X-Spam-Level: X-Spam-Status: No, score=-3.644 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYc1VSGr4l9R; Thu, 9 Aug 2012 09:06:55 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 70C7621F87E8; Thu, 9 Aug 2012 09:06:55 -0700 (PDT) Received: from mail220-co1-R.bigfish.com (10.243.78.248) by CO1EHSOBE015.bigfish.com (10.243.66.78) with Microsoft SMTP Server id 14.1.225.23; Thu, 9 Aug 2012 16:06:55 +0000 Received: from mail220-co1 (localhost [127.0.0.1]) by mail220-co1-R.bigfish.com (Postfix) with ESMTP id 1758FC03C3; Thu, 9 Aug 2012 16:06:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -2 X-BigFish: VPS-2(z3e13hzbb2dI98dI9371Izz1202hz31izz2dh2a8h668h839he5bhf0ah107ah) Received: from mail220-co1 (localhost.localdomain [127.0.0.1]) by mail220-co1 (MessageSwitch) id 1344528413892850_5878; Thu, 9 Aug 2012 16:06:53 +0000 (UTC) Received: from CO1EHSMHS020.bigfish.com (unknown [10.243.78.239]) by mail220-co1.bigfish.com (Postfix) with ESMTP id D7B9A50004A; Thu, 9 Aug 2012 16:06:53 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by CO1EHSMHS020.bigfish.com (10.243.66.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 9 Aug 2012 16:06:52 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 9 Aug 2012 09:08:50 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Thu, 9 Aug 2012 09:06:51 -0700 From: Adam Montville To: "Waltermire, David A." , "'david.oliva@verizon.net'" , "'dcougias@netfrontiers.com'" , "'lnunez@c3isecurity.com'" Thread-Topic: =?iso-8859-1?Q?[sacm]_Strategic_alignment_of_security_with_business_in_SA?= =?iso-8859-1?Q?CM_in=A0=A0=A0=A0an_international_context?= Thread-Index: AQHNdkj8/1tomtWW7E2gKZo0ZkPNzA== Date: Thu, 9 Aug 2012 16:06:51 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.16.97.206] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Cc: "'mile@ietf.org'" , "'sacm@ietf.org'" Subject: Re: [sacm] =?iso-8859-1?q?Strategic_alignment_of_security_with_busine?= =?iso-8859-1?q?ss_in_SACM_in=A0=A0=A0=A0an_international_context?= X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 09 Aug 2012 16:06:56 -0000 On 8/9/12 6:06 AM, "Waltermire, David A." wrote: >It might be best to keep any copyrighted material off the list, unless it >is being contributed to the IETF as an I/D. Perhaps this is prudent. Also, I don't think we need a full copy - the actual prose is quite sparse. We should be able to get by, at least for now, with just the TOC (I sent a link out yesterday). From michael.hammer@yaanatech.com Thu Aug 9 09:55: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 7AC5421F85A5 for ; Thu, 9 Aug 2012 09:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joE7YQ1yrMyX for ; Thu, 9 Aug 2012 09:55:36 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 832CF21F8644 for ; Thu, 9 Aug 2012 09:55:36 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 9 Aug 2012 09:55:35 -0700 From: Michael Hammer To: "mrex@sap.com" Thread-Topic: [sacm] Legal aspects of System monitoring Thread-Index: AQHNcebv9wpWqLOXkkW1HGuGxo9Hw5dKJ8AAgANL5YCAAAL0gIAACqqAgAAKjYCAAA8AAIAAB8sAgACMTgCAAH6dAIABBWwAgACuZ0CAAMXkgP//lrpQgADh8ACAAA3fwA== Date: Thu, 9 Aug 2012 16:55:34 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB30B918CE9@ex2k10mb2.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB30B9179FC@ex2k10mb2.corp.yaanatech.com> <20120809081548.22D1D1A145@ld9781.wdf.sap.corp> In-Reply-To: <20120809081548.22D1D1A145@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.50.59] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CD762E.4433EFC0" MIME-Version: 1.0 Cc: "shanna@juniper.net" , "sacm@ietf.org" Subject: Re: [sacm] Legal aspects of System 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, 09 Aug 2012 16:55:37 -0000 ------=_NextPart_000_0000_01CD762E.4433EFC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Martin, Your wording stated that it did not matter where in the world the server was located. It is possible for a user in Germany to subscribe to a service anywhere in the world, and the Cloud operator may not even know that has happened, since this could be completely self-service, or the identities used may not have any way to identify it as a German user. So, in effect you are criminalizing a company for the behavior of the user. Mike -----Original Message----- From: Martin Rex [mailto:mrex@sap.com] Sent: Thursday, August 09, 2012 4:16 AM To: Michael Hammer Cc: mrex@sap.com; shanna@juniper.net; sacm@ietf.org Subject: Re: [sacm] Legal aspects of System monitoring Michael Hammer wrote: > > Lastly, you are stating that Germany's laws apply globally and > over-ride any other country's laws. > I beg to differ. I actually did not mean to say or imply that. I would appreciate when you could quote the relevant text that you interpreted in that fashion so that I can try to improve my communication skills on legalese issues. (I'm native german and a novice in english/US legalese terminology). > > There is also a disconnect over when a company tells an employee not > to put any PII on the system owned by the company, I'm beginning to understand that the confusion is coming from a terminology misunderstanding. Either the US term "PII" refers to just an insignificant small subset of what is called PII in Europe, or the existing descriptions of what it means are just thoroughly confusing and misleading. Data protection is even more about control (who gets to know what about a data subject), than it is about confidentiality. And it encompasses all information "ANY information related to", not just the identifier (name) and the few example attributes that are typically quoted such as address, date-of-birth, gender, religion, ethnic origin. Quoting from the english version of the European Data Protection Directive: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:en:NO T For the purposes of this Directive: (a) 'personal data' shall mean any information relating to an identified or identifiable natural person ('data subject'); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity; PII includes - every single datum that an individual creates, every keypress, every mouse-move, even the length of the pauses between keypresses, body movements (breathing, twinkle, ...) - every datum that is (or can be with moderate effort) directly or indirectly related to an individual describing characteristics of the individual, showing actions/activities, opinions, thoughts > > and the employee proceeds to do so anyway, it is somehow the company's > fault if they detect that PII. It is impossible for an individual to create information that is *NOT* PII. It may be possible to anonymize PII after its creation, or at least ensure that it is re-distributed in anonymized fashion, but reliable anonymization may sometimes turn out to be difficult in reality. And not necessarily wanted. -Martin PS: and if you're wondering how this interacts with copyright, and whether there is some kind of "automatic" transfer of ownership of copyrights based on an employment contract, that is a very long and different story, there are specific statues which kinds of rights on which kinds of works are transfered by an employment contract, and at least in Germany the non-transferable "publication privilege" from the author/creator personality right in Germany's copyright statute (Art 12 (1) UrhG) precludes any automatic transfer, and transfer of rights on contents of non-public telecommunication is a seperate can of worms. ------=_NextPart_000_0000_01CD762E.4433EFC0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgw OTE2NTUzNFowIwYJKoZIhvcNAQkEMRYEFK24JZsxmpaEDTkO/quMwIFlMnFBMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAMHpQXgkPcjFfYbBRwaT67FKQE3kZZOb0etk3F+IYOWPs W312OIZgjRyvpn/DzRiv5eXIJjTuERlhq38Y9MfiHDHXxbAZfTEErc3JwhTnZbtiWNez+sQA2Xa2 GSjbSYZlNcpz+d9lqK8yYN8N2IJ2JHJ6OvtxPUgugweaO+0igTsAAAAAAAA= ------=_NextPart_000_0000_01CD762E.4433EFC0-- From michael.hammer@yaanatech.com Thu Aug 9 09:58:26 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 452D521F877C for ; Thu, 9 Aug 2012 09:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Mpp5f4wox+D for ; Thu, 9 Aug 2012 09:58:25 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id B175821F8779 for ; Thu, 9 Aug 2012 09:58:25 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 9 Aug 2012 09:58:25 -0700 From: Michael Hammer To: "david.oliva@verizon.net" , "lnunez@c3isecurity.com" Thread-Topic: [sacm] Strategic alignment of security with business in SACM in an international context Thread-Index: AQHNdjDwI1VBf2QYd06XOWanEmrGopdRs7hQ Date: Thu, 9 Aug 2012 16:58:24 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB30B918D45@ex2k10mb2.corp.yaanatech.com> References: <33365097.95248.1344518083103.JavaMail.root@vms170025> In-Reply-To: <33365097.95248.1344518083103.JavaMail.root@vms170025> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.50.59] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0009_01CD762E.A9584540" MIME-Version: 1.0 Cc: "mrex@sap.com" , "sacm@ietf.org" , Tony Rutkowski Subject: Re: [sacm] Strategic alignment of security with business in SACM in an international context X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 09 Aug 2012 16:58:26 -0000 ------=_NextPart_000_0009_01CD762E.A9584540 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01CD762E.A9584540" ------=_NextPart_001_000A_01CD762E.A9584540 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit That would essentially obliviate the copyright making it global. Mike From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of david.oliva@verizon.net Sent: Thursday, August 09, 2012 9:15 AM To: lnunez@c3isecurity.com Cc: david.oliva@verizon.net; mrex@sap.com; sacm@ietf.org; Tony Rutkowski Subject: Re: [sacm] Strategic alignment of security with business in SACM in an international context Luis: Is it possible that the IETF get a special multi-user license from ISO? When I bought my copy it cost around $125.00 and cannot share it. I also discovered that ISO's standards change much faster then NIST's. We need the ISO/IEC 27001:2005 first edition (2005-10-15) because that is what the SP 800-53 maps to. David Oliva On 08/09/12, Martin Rex wrote: Tony Rutkowski wrote: > > Could you provide a copy of ISO 27001 so we could > take a look at it? ISO (and all of its national member organizations) are "traditional" standardization developing organizations (SDOs) that are in the publishing business. i.e. a non-marginal part of their budget is from selling copies of their standards (and the national member bodies may offer translations as well). I believe the selling price is (or once was) calculated from number of pages. -Martin ------=_NextPart_001_000A_01CD762E.A9584540 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

That would essentially obliviate the copyright making it = global.

 

Mike

 

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = david.oliva@verizon.net
Sent: Thursday, August 09, 2012 = 9:15 AM
To: lnunez@c3isecurity.com
Cc: = david.oliva@verizon.net; mrex@sap.com; sacm@ietf.org; Tony = Rutkowski
Subject: Re: [sacm] Strategic alignment of security = with business in SACM in an international = context

 

&n= bsp;

&n= bsp;Luis:

&n= bsp;

Is= it possible that the IETF get a special multi-user license from = ISO?

Wh= en I bought my copy it cost around $125.00 and cannot share = it.

I = also discovered that ISO's standards change much faster then NIST's. =

We= need the ISO/IEC 27001:2005 first edition = (2005-10-15) because that is what the SP 800-53 maps = to.

&n= bsp;

Da= vid Oliva

&n= bsp;

&n= bsp;

&n= bsp;

On= 08/09/12, Martin Rex<mrex@sap.com> = wrote:

&n= bsp;

To= ny Rutkowski wrote:
>
> Could you provide a copy of ISO = 27001 so we could
> take a look at it?

ISO (and all of its = national member organizations)
are "traditional" = standardization developing organizations (SDOs)
that are in the = publishing business. i.e. a non-marginal part
of their budget is from = selling copies of their standards
(and the national member bodies may = offer translations as well).

I believe the selling price is (or = once was) calculated
from number of = pages.

-Martin

------=_NextPart_001_000A_01CD762E.A9584540-- ------=_NextPart_000_0009_01CD762E.A9584540 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgw OTE2NTgyNFowIwYJKoZIhvcNAQkEMRYEFC6l8ZTdoWS1A8Zu2+aQlEOUmTyzMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGA33IwKjhpxrb2QzTd/I6XWJ1ssdR6zCqBLYTBtr3tsytt Ljkf9sgl+3G9ATA7JjQWXhSpf1JPq4oOcDauTKEo3F21LyQK0h0nk1Sf5m5gqHZJuI/ENIIsfWtq f5Tuu+miAiFjoDykXtQy+zI6gv6XygMkLWmcpSk0f82IlGI57JUAAAAAAAA= ------=_NextPart_000_0009_01CD762E.A9584540-- From michael.hammer@yaanatech.com Thu Aug 9 17:41:46 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD7E21F85A3 for ; Thu, 9 Aug 2012 17:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIm5lsoZT3gP for ; Thu, 9 Aug 2012 17:41:45 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 99B3D21F85A0 for ; Thu, 9 Aug 2012 17:41:43 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 9 Aug 2012 17:41:42 -0700 From: Michael Hammer To: "David.Misell@bcs.org" Thread-Topic: [sacm] Legal aspects of System monitoring Thread-Index: AQHNcebv9wpWqLOXkkW1HGuGxo9Hw5dKJ8AAgANL5YCAAAL0gIAACqqAgAAKjYCAAA8AAIAAB8sAgACMTgCAAH6dAIABBWwAgACuZ0CAAMXkgP//lrpQgADh8ACAAA3fwIAA8HaA//+bUvA= Date: Fri, 10 Aug 2012 00:41:42 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB30B91A385@ex2k10mb2.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB30B9179FC@ex2k10mb2.corp.yaanatech.com> <20120809081548.22D1D1A145@ld9781.wdf.sap.corp> <00C069FD01E0324C9FFCADF539701DB30B918CE9@ex2k10mb2.corp.yaanatech.com> <1344554765.4305.8.camel@ubuntu> In-Reply-To: <1344554765.4305.8.camel@ubuntu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.50.59] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_023D_01CD766F.61DF8B60" MIME-Version: 1.0 Cc: "shanna@juniper.net" , "mrex@sap.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 List-Id: "Discussion List 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, 10 Aug 2012 00:41:46 -0000 ------=_NextPart_000_023D_01CD766F.61DF8B60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Dave, If it were only that simple. When we start using addresses to be identities, and many of these change as you hop through systems, and you have all sorts of encapsulations, then it is anybody's guess where something really came from or who they really are. Let's say you have a US user of a US service provider with certain ID's and IP addresses, Who travels to Germany and gets new visited network IDs and IP addresses (take LISP mobility as an example). That user then uses a cloud service that actually processes data that exists in the US, but a window on that data is sent to the user. Whose law governs the behavior here? Some countries would have us erect giant firewalls like the Chinese have to monitor every last bit, so we would know what is inside versus outside the geographical borders to ensure that countries laws are enforced. The unintended consequence might be less privacy not more. Mike -----Original Message----- From: David Misell [mailto:david.misell@btinternet.com] Sent: Thursday, August 09, 2012 7:26 PM To: Michael Hammer Cc: mrex@sap.com; shanna@juniper.net; sacm@ietf.org Subject: Re: [sacm] Legal aspects of System monitoring Michael, Isn't that a problem of the AS number in which the service is, maybe that needs to appear in the contract bindings? Just a thought, if we go back to Saltzer RFC 1498: - a name identifies what you want, - an address identifies where it is, and - an route identifies a way to get there. Clearly the how you get there is just as relevelnt today! dave On Thu, 2012-08-09 at 16:55 +0000, Michael Hammer wrote: > Martin, > > Your wording stated that it did not matter where in the world the > server was located. It is possible for a user in Germany to subscribe > to a service anywhere in the world, and the Cloud operator may not > even know that has happened, since this could be completely > self-service, or the identities used may not have any way to identify > it as a German user. So, in effect you are criminalizing a company for the > behavior of the user. > > Mike > > > > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Thursday, August 09, 2012 4:16 AM > To: Michael Hammer > Cc: mrex@sap.com; shanna@juniper.net; sacm@ietf.org > Subject: Re: [sacm] Legal aspects of System monitoring > > Michael Hammer wrote: > > > > Lastly, you are stating that Germany's laws apply globally and > > over-ride any other country's laws. > > I beg to differ. > > I actually did not mean to say or imply that. I would appreciate when > you could quote the relevant text that you interpreted in that fashion > so that I can try to improve my communication skills on legalese issues. > (I'm native german and a novice in english/US legalese terminology). > > > > > > There is also a disconnect over when a company tells an employee not > > to put any PII on the system owned by the company, > > I'm beginning to understand that the confusion is coming from a > terminology misunderstanding. Either the US term "PII" refers to just > an insignificant small subset of what is called PII in Europe, or the > existing descriptions of what it means are just thoroughly confusing and > misleading. > > Data protection is even more about control (who gets to know what > about a data subject), than it is about confidentiality. And it > encompasses all information "ANY information related to", not just the > identifier (name) and the few example attributes that are typically > quoted such as address, date-of-birth, gender, religion, ethnic origin. > > > Quoting from the english version of the European Data Protection Directive: > > > http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046 > :en:NO > T > > For the purposes of this Directive: > > (a) 'personal data' shall mean any information relating to an identified > or identifiable natural person ('data subject'); an identifiable person > is one who can be identified, directly or indirectly, in particular by > reference to an identification number or to one or more factors > specific to his physical, physiological, mental, economic, cultural > or social identity; > > > PII includes > - every single datum that an individual creates, > every keypress, every mouse-move, even the length of the pauses > between keypresses, body movements (breathing, twinkle, ...) > - every datum that is (or can be with moderate effort) directly > or indirectly related to an individual describing characteristics > of the individual, showing actions/activities, opinions, thoughts > > > > > > and the employee proceeds to do so anyway, it is somehow the > > company's fault if they detect that PII. > > It is impossible for an individual to create information that is *NOT* PII. > It may be possible to anonymize PII after its creation, or at least > ensure that it is re-distributed in anonymized fashion, but reliable > anonymization may sometimes turn out to be difficult in reality. > And not necessarily wanted. > > > -Martin > > PS: and if you're wondering how this interacts with copyright, > and whether there is some kind of "automatic" transfer of ownership > of copyrights based on an employment contract, that is a very long > and different story, there are specific statues which kinds of rights > on which kinds of works are transfered by an employment contract, > and at least in Germany the non-transferable "publication privilege" > from the author/creator personality right in Germany's copyright > statute (Art 12 (1) UrhG) precludes any automatic transfer, > and transfer of rights on contents of non-public telecommunication > is a seperate can of worms. > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm -- Kind Regards, dave David S. Misell, 07710380044 ------=_NextPart_000_023D_01CD766F.61DF8B60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgx MDAwNDE0MVowIwYJKoZIhvcNAQkEMRYEFAbMOm+aXLJ42yJNAb0KdbYCLQ/uMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGA2MHDkvnUJ4tCpxMKqs8EbXtREychyDZFWJQpQ7qX+fO1 dMcfaPjFbInLu5SYefZkD80FiSRRcbAb0ZeoUjUTQnQ2pnbcgR3gypXTfPZLr/9WQBrySZAvEFYT 5hNDXq+tK8trXZ+mfIMGqsDV1aKhjBD/Yo52AEqB9FxN8OOR1MgAAAAAAAA= ------=_NextPart_000_023D_01CD766F.61DF8B60-- From mrex@sap.com Fri Aug 10 11:33: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 9A8D421F86AD for ; Fri, 10 Aug 2012 11:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.675 X-Spam-Level: X-Spam-Status: No, score=-9.675 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_00=-2.599, GB_PHARMACY=1, HELO_EQ_DE=0.35, ONLINE_PHARMACY=0.001, RCVD_IN_DNSWL_HI=-8, TVD_VISIT_PHARMA=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNM2MQCt5Xll for ; Fri, 10 Aug 2012 11:33:34 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C80D221F84E1 for ; Fri, 10 Aug 2012 11:33:33 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q7AIXVCR003811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Aug 2012 20:33:31 +0200 (MEST) In-Reply-To: <00C069FD01E0324C9FFCADF539701DB30B918CE9@ex2k10mb2.corp.yaanatech.com> To: Michael Hammer Date: Fri, 10 Aug 2012 20:33:30 +0200 (CEST) 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: <20120810183330.E8A141A15A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "shanna@juniper.net" , "mrex@sap.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: Fri, 10 Aug 2012 18:33:34 -0000 Michael Hammer wrote: > > Your wording stated that it did not matter where in the world the server > was located. It is possible for a user in Germany to subscribe to a service > anywhere in the world, and the Cloud operator may not even know that has > happened, since this could be completely self-service, or the identities > used may not have any way to identify it as a German user. Now we're talking completely past each other. The previous discussion was about employer vs. employees. When it is a german employment contract and the workplace is in Germany, then German jurisdiction will apply, and this will be independent where the employer is processing his data, on a local server or abroad. Local laws and regulation may limit which kind of data and data processing an employer may legally "offshore" into other jurisdictions. That is not to be confused with a vendor/service provider to customer relationship, where vendor/service provider and customer are living in different jurisdictions from the beginning. Normally, the local laws and regulations where the vendor/service provider is operating apply. But this _may_ limit to which "netizens" the vendor/service provider may "legally" offer services, in particular when there actually exists a national subsidiary in the jurisdiction of the netizen/customer. Examples: Online Gambling, Online (re)distribution of copyrighted works, Online pharmacy. > > So, in effect you are criminalizing a company I wrote illegal/unlawful ("rechtswidrig"), _not_ criminal ("strafbar"). but I'm not sufficiently familiar with english/US legalese terminology, to know whether my use of english terminology is appropriate. The way I understand "criminial" is that it fits an existing criminal statute and is directly punishable (i.e. all previous offenses are punishable), whereas when some conduct is merely unlawfully infringing/ encroaching on rights, and the affected person can obtain injunction (backed by punishment), but only continued or future infringments/encroachments will be punishable. > > for the behavior of the user. I don't understand the latter. If the company is infringing on the users rights, then it is liable. User rights may result from the jurisdiction under which the services are being offered, from the contract between vendor/service provider and the user, and from international treaties that may apply to the goods/services. -Martin From michael.hammer@yaanatech.com Fri Aug 10 12:08: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 C6C2C21F8673 for ; Fri, 10 Aug 2012 12:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_00=-2.599, GB_PHARMACY=1, ONLINE_PHARMACY=0.001, TVD_VISIT_PHARMA=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrdlpdTB4Kvx for ; Fri, 10 Aug 2012 12:08:14 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2E421F8685 for ; Fri, 10 Aug 2012 12:08:13 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Fri, 10 Aug 2012 12:08:12 -0700 From: Michael Hammer To: "mrex@sap.com" Thread-Topic: [sacm] Legal aspects of System monitoring Thread-Index: AQHNcebv9wpWqLOXkkW1HGuGxo9Hw5dKJ8AAgANL5YCAAAL0gIAACqqAgAAKjYCAAA8AAIAAB8sAgACMTgCAAH6dAIABBWwAgACuZ0CAAMXkgP//lrpQgADh8ACAAA3fwIACMQsA//+QtRA= Date: Fri, 10 Aug 2012 19:08:11 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB30B91A7DE@ex2k10mb2.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB30B918CE9@ex2k10mb2.corp.yaanatech.com> <20120810183330.E8A141A15A@ld9781.wdf.sap.corp> In-Reply-To: <20120810183330.E8A141A15A@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.50.59] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0064_01CD7709.F5349F50" MIME-Version: 1.0 Cc: "shanna@juniper.net" , "sacm@ietf.org" Subject: Re: [sacm] Legal aspects of System 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: Fri, 10 Aug 2012 19:08:14 -0000 ------=_NextPart_000_0064_01CD7709.F5349F50 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Martin, Yes, language and culture is always challenging. Yes, we have both criminal and civil categories as well, but only one supreme court. (btw, I used to live across from the Bundesgerichtshof (sp?) in Karslruhe on Herrenstrasse.) The former tends to be driven by statutes, and the latter from tort law from English common law. The U.S. constitution was designed to limit government by specifying explicit powers, with all others going to the States and the People. The Bill of rights outlines individual rights, but you have to interpolate to find anything about privacy. There is also the concept of contract law. And if two parties agree to a contract, so long as it isn't explicitly prohibited, then it is lawful. You alluded to contracts earlier, but noted that German law has placed additional restrictions on that. So, this seems to devolve to which laws apply, and the key factor is a person resident in Germany must have a German employment contract, and under those terms, these privacy laws would apply. BTW, I was there under the Status of Forces Agreement and hence German Law did not always apply to me, much to the consternation of some German government folks who came to knock on my door and insist that I provide answers to their census and I told them to go pound sand. :) So much for privacy. Mike -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Martin Rex Sent: Friday, August 10, 2012 2:33 PM To: Michael Hammer Cc: shanna@juniper.net; mrex@sap.com; sacm@ietf.org Subject: Re: [sacm] Legal aspects of System monitoring Michael Hammer wrote: > > Your wording stated that it did not matter where in the world the > server was located. It is possible for a user in Germany to subscribe > to a service anywhere in the world, and the Cloud operator may not > even know that has happened, since this could be completely > self-service, or the identities used may not have any way to identify it as a German user. Now we're talking completely past each other. The previous discussion was about employer vs. employees. When it is a german employment contract and the workplace is in Germany, then German jurisdiction will apply, and this will be independent where the employer is processing his data, on a local server or abroad. Local laws and regulation may limit which kind of data and data processing an employer may legally "offshore" into other jurisdictions. That is not to be confused with a vendor/service provider to customer relationship, where vendor/service provider and customer are living in different jurisdictions from the beginning. Normally, the local laws and regulations where the vendor/service provider is operating apply. But this _may_ limit to which "netizens" the vendor/service provider may "legally" offer services, in particular when there actually exists a national subsidiary in the jurisdiction of the netizen/customer. Examples: Online Gambling, Online (re)distribution of copyrighted works, Online pharmacy. > > So, in effect you are criminalizing a company I wrote illegal/unlawful ("rechtswidrig"), _not_ criminal ("strafbar"). but I'm not sufficiently familiar with english/US legalese terminology, to know whether my use of english terminology is appropriate. The way I understand "criminial" is that it fits an existing criminal statute and is directly punishable (i.e. all previous offenses are punishable), whereas when some conduct is merely unlawfully infringing/ encroaching on rights, and the affected person can obtain injunction (backed by punishment), but only continued or future infringments/encroachments will be punishable. > > for the behavior of the user. I don't understand the latter. If the company is infringing on the users rights, then it is liable. User rights may result from the jurisdiction under which the services are being offered, from the contract between vendor/service provider and the user, and from international treaties that may apply to the goods/services. -Martin _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_000_0064_01CD7709.F5349F50 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgx MDE5MDgxMVowIwYJKoZIhvcNAQkEMRYEFC1p2Xss4Feu3BqY7A5iVA2lpkQeMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGA2P6BK/POgWvbmkFS1OC2+AWdFPZL8OHISL5JEfPG2uXx b1gMLySgfKqANsK5/JLkfmnFlNaS4zXZ/uRp+cOW3J8JvFBX9UYRLM4yq70KmMpRIBrSJyOBaJW7 ph6U5LRWgodBm1pMDyugpgPEU/SMdOpfTHpURPG5c5c4EnEPQAYAAAAAAAA= ------=_NextPart_000_0064_01CD7709.F5349F50-- From Kent_Landfield@mcafee.com Fri Aug 10 14:44: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 6D67B21F866A for ; Fri, 10 Aug 2012 14:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.085 X-Spam-Level: X-Spam-Status: No, score=-6.085 tagged_above=-999 required=5 tests=[AWL=-0.489, BAYES_00=-2.599, GB_PHARMACY=1, HTML_MESSAGE=0.001, ONLINE_PHARMACY=0.001, RCVD_IN_DNSWL_MED=-4, TVD_VISIT_PHARMA=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbiBpaqVtnM4 for ; Fri, 10 Aug 2012 14:44:12 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 72CAF21F865F for ; Fri, 10 Aug 2012 14:44:12 -0700 (PDT) Received: from DALEXHT1.corp.nai.org (unknown [10.64.5.51]) by dalsmrelay2.nai.com with smtp id 19f9_ee40_84948ea7_cfbf_4937_a7bf_0af1807c3f15; Fri, 10 Aug 2012 16:44:01 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT1.corp.nai.org ([::1]) with mapi; Fri, 10 Aug 2012 16:42:37 -0500 From: To: , Date: Fri, 10 Aug 2012 16:43:38 -0500 Thread-Topic: [sacm] Legal aspects of System monitoring Thread-Index: Ac13QQ7+aeJq0v9KSnq2N5d3cIlgjQ== Message-ID: In-Reply-To: <20120810183330.E8A141A15A@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC4AF80539A34kentlandfieldmcafeecom_" MIME-Version: 1.0 Cc: shanna@juniper.net, sacm@ietf.org Subject: Re: [sacm] Legal aspects of System 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: Fri, 10 Aug 2012 21:44:13 -0000 --_000_CC4AF80539A34kentlandfieldmcafeecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, While this is a very stimulating conversation, it has little to do, at pres= ent, with the work of this potential working group. As was requested befor= e by others, PLEASE take this to the appropriate forum. This list is NOT i= t. If you are responding to these types of message, please don't. Thank you. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Martin Rex > Reply-To: "mrex@sap.com" > Date: Friday, August 10, 2012 2:33 PM To: Michael Hammer > Cc: "shanna@juniper.net" >, "mrex@sap.com" >, "sacm@ietf.org" > Subject: Re: [sacm] Legal aspects of System monitoring Michael Hammer wrote: Your wording stated that it did not matter where in the world the server was located. It is possible for a user in Germany to subscribe to a servic= e anywhere in the world, and the Cloud operator may not even know that has happened, since this could be completely self-service, or the identities used may not have any way to identify it as a German user. Now we're talking completely past each other. The previous discussion was about employer vs. employees. When it is a german employment contract and the workplace is in Germany, then German jurisdiction will apply, and this will be independent where the employer is processing his data, on a local server or abroad. Local laws and regulation may limit which kind of data and data processing an employer may legally "offshore" into other jurisdictions. That is not to be confused with a vendor/service provider to customer relationship, where vendor/service provider and customer are living in different jurisdictions from the beginning. Normally, the local laws and regulations where the vendor/service provider is operating apply. But this _may_ limit to which "netizens" the vendor/service provide= r may "legally" offer services, in particular when there actually exists a national subsidiary in the jurisdiction of the netizen/customer. Examples: Online Gambling, Online (re)distribution of copyrighted works, Online pharmacy. So, in effect you are criminalizing a company I wrote illegal/unlawful ("rechtswidrig"), _not_ criminal ("strafbar"). but I'm not sufficiently familiar with english/US legalese terminology, to know whether my use of english terminology is appropriate. The way I understand "criminial" is that it fits an existing criminal statute and is directly punishable (i.e. all previous offenses are punishable), whereas when some conduct is merely unlawfully infringing/ encroaching on rights, and the affected person can obtain injunction (backed by punishment), but only continued or future infringments/encroachments will be punishable. for the behavior of the user. I don't understand the latter. If the company is infringing on the users rights, then it is liable. User rights may result from the jurisdiction under which the services are being offered, from the contract between vendor/service provider and the user, and from international treaties that may apply to the goods/services. -Martin _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_CC4AF80539A34kentlandfieldmcafeecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,=

While this is a very stimulating conversation, it= has little to do, at present, with the work of this potential working grou= p.  As was requested before by others,  PLEASE take this to the a= ppropriate forum. This list is NOT it.  If you are responding to these= types of message, please don't.

Thank you. <= /div>

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096&nbs= p;
Mobile: +1.817= .637.8026<= br>Web: www.mcafee.com
From: Martin Rex <<= a href=3D"mailto:mrex@sap.com">mrex@sap.com>
Reply-To: "mrex@sap.co= m" <mrex@sap.com>
Date: Friday, August 10, 2012 2:33 PM
<= span style=3D"font-weight:bold">To: Michael Hammer <michael.hammer@yaanatech.com>Cc: "shanna@juniper.net" <shanna@juniper.net>, "mrex@sap.com<= /a>" <mrex@sap.com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Legal aspects of System monitoring

Michael Ha= mmer wrote:
=
Your wording stated that it did not matter where in the world t= he server
was located.  It is possible for a user in G= ermany to subscribe to a service
anywhere in the world, and the = Cloud operator may not even know that has
happened, since this c= ould be completely self-service, or the identities
used may not = have any way to identify it as a German user.

Now we're talking completely past each other.

=
The previous discussion was about employer vs. employees.  W= hen it is a
german employment contract and the workplace is in Ge= rmany, then German
jurisdiction will apply, and this will be inde= pendent where the employer
is processing his data, on a local ser= ver or abroad.  Local laws and
regulation may limit whi= ch kind of data and data processing an employer
may legally "offs= hore" into other jurisdictions.


Tha= t is not to be confused with a vendor/service provider to customer
relationship, where vendor/service provider and customer are living
=
in different jurisdictions from the beginning.  Normally, th= e local
laws and regulations where the vendor/service provider is= operating
apply.  But this _may_ limit to which "netiz= ens" the vendor/service provider
may "legally" offer services, in= particular when there actually exists
a national subsidiary in t= he jurisdiction of the netizen/customer.

Examples:= Online Gambling, Online (re)distribution of copyrighted works,
O= nline pharmacy.



So, in effect you are crim= inalizing a company

I wrote illegal/u= nlawful ("rechtswidrig"), _not_ criminal ("strafbar").
but I'm no= t sufficiently familiar with english/US legalese terminology,
to = know whether my use of english terminology is appropriate.

The way I understand "criminial" is that it fits an existing crimi= nal
statute and is directly punishable (i.e. all previous offense= s are
punishable), whereas when some conduct is merely unlawfully= infringing/
encroaching on rights, and the affected person can o= btain injunction
(backed by punishment), but only continued or fu= ture
infringments/encroachments will be punishable.

<= div>
          = ;            &n= bsp;            = ;          for the behavior of= the user.

I don't understand the lat= ter.  If the company is infringing on the
users rights,= then it is liable.  User rights may result from
the ju= risdiction under which the services are being offered, from
the c= ontract between vendor/service provider and the user, and from
in= ternational treaties that may apply to the goods/services.


-Martin
_________________________________= ______________
sacm mailing list

 --_000_CC4AF80539A34kentlandfieldmcafeecom_-- From amontville@tripwire.com Fri Aug 10 14:46: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 82DC721F866A for ; Fri, 10 Aug 2012 14:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.277 X-Spam-Level: X-Spam-Status: No, score=-5.277 tagged_above=-999 required=5 tests=[AWL=1.322, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPvSdWW9Zpvy for ; Fri, 10 Aug 2012 14:46:06 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id F114D21F8659 for ; Fri, 10 Aug 2012 14:46:05 -0700 (PDT) Received: from mail243-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 10 Aug 2012 21:46:05 +0000 Received: from mail243-tx2 (localhost [127.0.0.1]) by mail243-tx2-R.bigfish.com (Postfix) with ESMTP id 7699B1F0041C; Fri, 10 Aug 2012 21:46:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zzbb2dI98dI9371Izz1202hzz8275bhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail243-tx2 (localhost.localdomain [127.0.0.1]) by mail243-tx2 (MessageSwitch) id 134463516361366_26842; Fri, 10 Aug 2012 21:46:03 +0000 (UTC) Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.246]) by mail243-tx2.bigfish.com (Postfix) with ESMTP id 0C1C7138004E; Fri, 10 Aug 2012 21:46:03 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 10 Aug 2012 21:46:02 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 Aug 2012 14:47:58 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Fri, 10 Aug 2012 14:46:01 -0700 From: Adam Montville To: "Kent_Landfield@McAfee.com" , "mrex@sap.com" , "michael.hammer@yaanatech.com" Thread-Topic: [sacm] Legal aspects of System monitoring Thread-Index: AQHNcebweuOA+8HKqU2i7Uq8cRJNJpdKJ8AAgANL5YCAAAL0gIAACqqAgAAKjYCAAA8AAIAAB8sAgACMTgCAAH6dAIABBWwAgAEkpgCAAE+lgIAADl6AgABqTACAAJE5AIABrbEAgAA1IAD//4tPgA== Date: Fri, 10 Aug 2012 21:46:00 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.16.97.205] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Cc: "shanna@juniper.net" , "sacm@ietf.org" Subject: Re: [sacm] Legal aspects of System 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: Fri, 10 Aug 2012 21:46:06 -0000 On 8/10/12 2:43 PM, "Kent_Landfield@McAfee.com" wrote: >While this is a very stimulating conversation, it has little to do, at >present, with the work of this potential working group. As was requested >before by others, PLEASE take this to the appropriate forum. This list >is NOT it. If you are responding to these types of message, please don't. +1 From lnunez@c3isecurity.com Fri Aug 10 15:08:39 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4D211E8091 for ; Fri, 10 Aug 2012 15:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LFeyD6DkV+8 for ; Fri, 10 Aug 2012 15:08:38 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F13511E8087 for ; Fri, 10 Aug 2012 15:08:38 -0700 (PDT) Received: by yhq56 with SMTP id 56so2303985yhq.31 for ; Fri, 10 Aug 2012 15:08:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=YbPdSuRDgiexGSKtH03aSIxA+37buMA4FWeNaOf9ruk=; b=Z8grfMGo8lWjLI8n+918OHH8kOYe8zPSHa4GYsAVeojaKFWbKgxeJaLEP6WjpkWLM/ W0SgLJ+vbyqfWQWKoib79iKHYkDmvUPPu7VpBcbMOZnbmFJEaL9xJticRfepd+pmOv7B Hw4qWLplupzyjZcxfY6vm6S7OASJKtKSB7mkZFdwcX68Pmjo+O9wUqU/0W9V5dWRDHQ7 EkqFSzXYsyGBWPDZfovn6PlY5aXuaITDza+EDOrJpU1TEdmjETESWqYqgoVP1t+QCE8J jcTHWbCNtaJ/OEdrq4LbeNz9xbCgYLXB9vVSjZULhO9IJ9K5ArVHjky94921zRzBon7f nhSw== Received: by 10.236.187.35 with SMTP id x23mr912081yhm.58.1344636517736; Fri, 10 Aug 2012 15:08:37 -0700 (PDT) Received: from [192.168.1.25] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id w5sm84555anl.10.2012.08.10.15.08.35 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 15:08:36 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <66CEF897-2DA4-47C5-8A63-44F1C385A711@c3isecurity.com> X-Mailer: iPhone Mail (9B206) From: Luis Nunez Date: Fri, 10 Aug 2012 18:08:32 -0400 To: Adam Montville X-Gm-Message-State: ALoCoQlpadRm7cFCkCT/g/b5wUpO5kJpWJcvJvO0o5EoiA+Vc/U1wvvrvLwSSrz/denFoCNpQCYC Cc: "shanna@juniper.net" , "mrex@sap.com" , "michael.hammer@yaanatech.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 List-Id: "Discussion List 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, 10 Aug 2012 22:08:39 -0000 +1 Thanks -ln Sent from mobile phone On Aug 10, 2012, at 17:46, Adam Montville wrote: > On 8/10/12 2:43 PM, "Kent_Landfield@McAfee.com" > wrote: > >> While this is a very stimulating conversation, it has little to do, at >> present, with the work of this potential working group. As was requested >> before by others, PLEASE take this to the appropriate forum. This list >> is NOT it. If you are responding to these types of message, please don't. > > +1 > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From amontville@tripwire.com Wed Aug 15 07:27:00 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE5321F86F3 for ; Wed, 15 Aug 2012 07:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.316 X-Spam-Level: X-Spam-Status: No, score=-5.316 tagged_above=-999 required=5 tests=[AWL=1.283, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPxsnbbfWCYk for ; Wed, 15 Aug 2012 07:26:59 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7624821F86E3 for ; Wed, 15 Aug 2012 07:26:59 -0700 (PDT) Received: from mail125-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Wed, 15 Aug 2012 14:26:58 +0000 Received: from mail125-tx2 (localhost [127.0.0.1]) by mail125-tx2-R.bigfish.com (Postfix) with ESMTP id E8D7D42049D; Wed, 15 Aug 2012 14:26:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zzbb2dI98dI9371I542M1432Izz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail125-tx2 (localhost.localdomain [127.0.0.1]) by mail125-tx2 (MessageSwitch) id 1345040815501519_28387; Wed, 15 Aug 2012 14:26:55 +0000 (UTC) Received: from TX2EHSMHS012.bigfish.com (unknown [10.9.14.254]) by mail125-tx2.bigfish.com (Postfix) with ESMTP id 74174460192; Wed, 15 Aug 2012 14:26:55 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by TX2EHSMHS012.bigfish.com (10.9.99.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 15 Aug 2012 14:26:54 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Aug 2012 07:28:44 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Wed, 15 Aug 2012 07:26:53 -0700 From: Adam Montville To: "Moriarty, Kathleen" , "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: Using the Frame of Reference Thread-Index: AQHNdDkTRwSx007YrEGOEBCjcgvwt5dOvU9AgAAOJhCAAA8kcIAAAgUQgAwe+wA= Date: Wed, 15 Aug 2012 14:26:52 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <3B68D3174978574BA96CAA05BA96D4F4@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] Using the Frame of Reference X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 15 Aug 2012 14:27:00 -0000 On 8/7/12 2:25 PM, "Moriarty, Kathleen" wrote: >The configuration check languages are validating after the configurations >have been set. Other systems are used to manage configurations that may >be vendor/product dependant. Managing the configuration expressions is something that is critical to our overall success, and I would say that managing such content - to include creation, selection, tailoring of specific checks - is therefore important to us. It would be very useful to keep this in mind as we would expect the other systems Kathleen mentioned to work with our expressions. > >-----Original Message----- >From: Waltermire, David A. [mailto:david.waltermire@nist.gov] >Sent: Tuesday, August 07, 2012 5:16 PM >To: Moriarty, Kathleen; Adam Montville; sacm@ietf.org >Subject: RE: Using the Frame of Reference > >+1 on clearly defining our assumptions. Agreed. > > >>=20 >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Waltermire, David A. >> Sent: Tuesday, August 07, 2012 4:10 PM >> To: Adam Montville; sacm@ietf.org >> Subject: Re: [sacm] Using the Frame of Reference >>=20 >> Are your 5 aspects of SCM controls or activities? Well, they're really both depending on your perspective (this is why I'd like us to continuously define common vocabulary). They are activities, but that activity itself is a control, or, at the very least, substantiates a control, from the perspective of a control framework. >> I would argue more >> so that latter. I also like how you have broken down the different >> "layers" of information for each of the 5 aspects. In my mind the >> initial scope of this effort should focus on the "Observable Model" and >> lower which I would interpret as being the data formats that describe >> what is to be observed, how to observe it, and how to report those >> observations. =20 I would prefer to describe what is to be observed, but not necessarily require an expression of how to make the observation. >>Things like tasking are the protocol bits to ensure that >> the right observations are made and that the results are provided (or >> not provided) to specific network components. I see a potential distinction here. Tasking involves scoping and instructing, and it's the scoping piece that helps ensure the right observations are made, and the instructing that tells a sacm-compliant (can I say that?) tool to go do something. >>=20 >> I would argue that "Configuration Assessment" might have a >> "configuration compliance" model above "assessment" that would be a >> peer to "vulnerability". This would put the configuration state in >> context within the enterprise, just like the "vulnerability model" >> does. I'm not sure I'm understanding this, but I haven't tried to draw it out (short on time at the moment). It seems that what you're suggesting is that what I've written as "assessment model" would be decomposed into a parent and child, where the parent is the "configuration compliance" piece and the "assessment" aspect is then the child? Also, when you say "configuration compliance," I want to be clear that you're talking about expressing a platform-level checklist of configuration settings, and then harvesting the data to measure an instance of that platform against that checklist - in other words, you're not talking about compliance to control frameworks, but to something I would generally call benchmarks (not measuring to NIST 800-53, but to a DISA STIG, for example). >>=20 >> It is at the scoring/risk layer that we may want to tie-in control >> frameworks. But what does this really mean? Does it mean that you are >> demonstrating successful implementation of a control through the >> collection of supporting data? Does it mean providing data that >> indicates that the use of the control is effective in reducing security >> exposure or risk? There are many other considerations as well. >>=20 >> It might be enough for this effort to ensure that the results from the >> assessment/remediation model/layer is capable of being associated with >> the controls they implement. I have found it helpful to look at this from two perspectives: auditor and security operations. As an auditor, it's my job to ensure that the benchmarks (tests) being applied to in-scope systems substantiate the controls and control objectives described in a given framework. So, the answer to your second question is yes. As a security operations guy, I want to ensure that the benchmarks being applied to in-scope (all, really) systems effectively treat the risk of attack, compromise, breach (put your word here). So, the answer to your third question is also yes (but we'll need help from other efforts to do so). A first step, as I think you would agree (judging based on your last sentence above), is to clearly get benchmark-level content clearly associated with particular controls and control objectives. >>=20 >>=20 >> > -----Original Message----- >> > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >> > Of Adam Montville >> > Sent: Monday, August 06, 2012 9:08 PM >> > To: sacm@ietf.org >> > Subject: [sacm] Using the Frame of Reference >> > >> > All: >> > >> > Here's how I would envision using the frame of reference using >> > Security Configuration Management (SCM) as an example. >> > >> > SCM is really five controls often assisted by technical toolsets >> > (depending on who you ask, so this is just one perspective): >> > >> > 1. Configuration Assessment (password length is set to x) >> > 2. Patch and Vulnerability Assessment (software package x is at >> > version >> > a.b.c) >> > 3. Configuration Remediation (set password length to x) >> > 4. Patch Remediation (bring software package x to at least version >> > a.b.c) >> > 5. Rate of Change (how are the files, registry entries, and other >> > Settings changing over time >> > >> > Because asset management is critical to the success of these >> controls, >> > I assert that we should revisit what we have today in the way of >> > models and where we need improvement (gaps or less than ideal >> coverage). >> > Appropriate asset models are required for each of SCM's constituent >> > parts, as listed below. >> > >> > We might assert the following information model relationships: >> > >> > o Security Configuration Management is composed of >> > o Configuration Assessment, which requires a/an >> > - Asset Model (information/characterization) >> > - Observable Model, >> > - Assessment Model (checklists), >> > - Scoring/Risk Model; >> > o Patch and Vulnerability Assessment, which requires a/an >> > - Asset Model, >> > - Observable Model, >> > - Assessment Model, >> > - Vulnerability Model, >> > - Scoring/Risk Model; >> > o Configuration Remediation, which requires a/an >> > - Asset Model, >> > - Observable Model, >> > - Remediation Model; >> > o Patch Remediation, which requires a/an >> > - Asset Model, >> > - Observable Model, >> > - Remediation Model. >> > >> > Note that some of the Supporting Concepts would be helpful here as >> > well. >> > Tasking/Workflow, is one example (consider assessing an endpoint, >> > remediating, then reassessing). >> > >> > The Observable Model should be one that describes that which can be >> > technically observed on an endpoint and which is able to provide >> > contextual information with respect to that observable (either >> > directly or through use of another model). For example, if I'm >> > looking at a the Account Lockout Duration setting for a Windows >> Server >> > 2008 R2 machine Group Policy Object, then we should provide the means >> > for content producers to include acceptable values for that >> > configuration item, such that implementers using these specifications >> > can provide guidance to their users with respect to that particular >> setting. >> > >> > Something that seems lacking here is tying back to control frameworks >> > (control in the ISO 27000/NIST 800-53 sense of the term). In the >> case >> > of SCM, we could use any number of the available control frameworks >> to >> > guide us. For example, the third SANS Top 20 Critical Control, >> > "Secure Configurations for Hardware and Software on Laptops, >> > Workstations, and Servers" might require one or more SCM constituents >> as defined above. >> > >> > I'm particularly interested in this because it has been shown that, >> to >> > date, security automation efforts have been rather shotgun in their >> > approach and have not necessarily done a good job ensuring that >> > requirements derived from top-level scenarios are being satisfied. >> > Also, knowing the exact needs of these controls can help us focus on >> > what that which must be done, rather than upon that which could be >> > done. >> > >> > Regards, >> > >> > Adam >> From amontville@tripwire.com Wed Aug 15 07:30: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 0924E21F86E3 for ; Wed, 15 Aug 2012 07:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[AWL=1.246, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbuvXlCR8poX for ; Wed, 15 Aug 2012 07:30:03 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7938C21F86DF for ; Wed, 15 Aug 2012 07:30:03 -0700 (PDT) Received: from mail272-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 15 Aug 2012 14:30:02 +0000 Received: from mail272-tx2 (localhost [127.0.0.1]) by mail272-tx2-R.bigfish.com (Postfix) with ESMTP id 5A389440130; Wed, 15 Aug 2012 14:30:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1202hzz8275bhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail272-tx2 (localhost.localdomain [127.0.0.1]) by mail272-tx2 (MessageSwitch) id 1345041000791016_27255; Wed, 15 Aug 2012 14:30:00 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.250]) by mail272-tx2.bigfish.com (Postfix) with ESMTP id BDE70780046; Wed, 15 Aug 2012 14:30:00 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 15 Aug 2012 14:29:59 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Aug 2012 07:31:49 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Wed, 15 Aug 2012 07:29:58 -0700 From: Adam Montville To: Adam Montville , Stephen Hanna , Luis Nunez , Omar Santos Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOA Date: Wed, 15 Aug 2012 14:29:57 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 15 Aug 2012 14:30:04 -0000 On 8/6/12 7:27 AM, "Adam Montville" wrote: > > >UC1 and UC3 both require assessment of endpoint state. If not for the NEA >ties in UC1, it seems a subset of UC3. So, we should be able to start >with the main concern of UC3: Security Configuration Management. > > I haven't seen much activity on this thread (there was another thread, "Using the Frame of Reference," discussing some approaches we can use to keep us focused and meaningful). Are there any objections to tackling UC3 followed by UC1? Does anyone disagree with my assertion that UC3 is a subset of UC1 and that a reasonable starting point is Security Configuration Management? From shanna@juniper.net Wed Aug 15 08:25:57 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 3EC7C21F883E for ; Wed, 15 Aug 2012 08:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dfECMWs+3pg for ; Wed, 15 Aug 2012 08:25:56 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3E06321F883B for ; Wed, 15 Aug 2012 08:25:54 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUCu/gceBjOKyEhTigPCO7CM4MWgrj45H@postini.com; Wed, 15 Aug 2012 08:25:56 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 15 Aug 2012 08:24:29 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 15 Aug 2012 11:24:28 -0400 From: Stephen Hanna To: Adam Montville , Luis Nunez , Omar Santos Date: Wed, 15 Aug 2012 11:24:26 -0400 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlA= 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 15 Aug 2012 15:25:57 -0000 I agree. Let's work on UC1 and UC3. The other use cases are valuable but just doing UC1 and UC3 is plenty of work for this group for the next year or two (maybe five!). I saw several emails in favor of this a few weeks ago. I thought that it was settled. I'd like to see a revised charter and use case document, scoped down to focus on just UC1 and UC3. What do others think? Do we have rough consensus on this? If so, let's get moving. Thanks, Steve > -----Original Message----- > From: Adam Montville [mailto:amontville@tripwire.com] > Sent: Wednesday, August 15, 2012 10:30 AM > To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos > Cc: sacm@ietf.org > Subject: Re: [sacm] Proposed use cases to move forward >=20 > On 8/6/12 7:27 AM, "Adam Montville" wrote: >=20 > > > > > >UC1 and UC3 both require assessment of endpoint state. If not for the > NEA > >ties in UC1, it seems a subset of UC3. So, we should be able to start > >with the main concern of UC3: Security Configuration Management. > > > > >=20 >=20 > I haven't seen much activity on this thread (there was another thread, > "Using the Frame of Reference," discussing some approaches we can use > to > keep us focused and meaningful). >=20 > Are there any objections to tackling UC3 followed by UC1? Does anyone > disagree with my assertion that UC3 is a subset of UC1 and that a > reasonable starting point is Security Configuration Management? >=20 From lnunez@c3isecurity.com Wed Aug 15 08:45:57 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 6340221E80F5 for ; Wed, 15 Aug 2012 08:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.624 X-Spam-Level: X-Spam-Status: No, score=-3.624 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-aZnH8NzmYh for ; Wed, 15 Aug 2012 08:45:54 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D96721E80D9 for ; Wed, 15 Aug 2012 08:45:54 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2091054ghb.31 for ; Wed, 15 Aug 2012 08:45:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=VTqM08bgBkHakMu0BIbNOyCa2z3yDFE/65cnyOjASRU=; b=iGoJW00C6JOKoNgb7rCnzqSZaVtaNiK4UYKTRRWsfGu6qFJXT9ixLuJXe25DCZwGQ/ btlnu+GJfyz/1rwrJ4sWWe2x2sf3Nj3shEVTQ1+2KQpa8Qb0jcupQXGiVDLCVSEiQMUb T1zs51KlUzzH6UJAYcYDYpxxeHN7giVO66v182SO0zMNeN7F2DS1fyVIDrt1apA5uNaC eROMdmwKXg9m21Q9XuCNryxZhZfCoRm6bPPPJom0GTN2dxASmGlNzbhG0j7pivezIkOI U2cynz9X1U9ONEdHsbNPrkEQj4PfLabB2NSjRs4sCzQ3FIG4nbjpvSBR2IbGMdD1ky5C CeUg== Received: by 10.236.141.42 with SMTP id f30mr16828411yhj.120.1345045553952; Wed, 15 Aug 2012 08:45:53 -0700 (PDT) Received: from [192.168.1.16] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id y10sm3279881yhd.6.2012.08.15.08.45.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Aug 2012 08:45:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_943AAED8-1F4F-4A8F-B898-BC1D19BAD440" From: Luis Nunez In-Reply-To: <002e01cd7af0$8985f610$9c91e230$@cloudsecurityalliance.org> Date: Wed, 15 Aug 2012 11:45:49 -0400 Message-Id: <34D73D4A-9582-4BD4-AFF6-A812B1053211@c3isecurity.com> References: <002e01cd7af0$8985f610$9c91e230$@cloudsecurityalliance.org> To: Becky Swain X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQl4n2WPOyTtdUBRZgPeNHVl4gJDcndJfoOd6HY7K/FYqcqg4xeD3/7oQX56XU7t8+POT7RK Cc: 'John Howie' , 'Ruben Oliva' , mile@ietf.org, "'Waltermire, David A.'" , sacm@ietf.org Subject: Re: [sacm] [mile] Cloud Control Matrix X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 15 Aug 2012 15:45:57 -0000 --Apple-Mail=_943AAED8-1F4F-4A8F-B898-BC1D19BAD440 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 John, thanks for the information and intro. Hi Becky, CCM is a worth while effort that contributes tremendously to community. Some questions I have is: 1. Do you see CCM expand to other controls sets or what is currently = mapped good enough for coverage?=20 2. CCM is for cloud environments, is there a difference if you apply to = non-cloud environments? Looking to see if there is gap in mapping if = CCM is applied to non-cloud environments. Thanks. -ln =20 On Aug 15, 2012, at 10:16 AM, Becky Swain wrote: > John, thanks for adding me to the communication thread. > =20 > Luis et al, if there are any questions on CCM or specifically on what = is changing for CCM v2.0, please let me know how I could assist. > =20 > Becky Swain > (mobile) +1 (650) 520-0263 > (skype) rebeccadswain > (twitter) @rebeccadswain > =20 > From: John Howie [mailto:jhowie@cloudsecurityalliance.org]=20 > Sent: Tuesday, August 14, 2012 9:39 PM > To: Luis Nunez; Waltermire, David A. > Cc: Ruben Oliva; mile@ietf.org; sacm@ietf.org; Becky Swain > Subject: Re: [mile] [sacm] Strategic alignment of security with = business in SACM in an international context > =20 > Hi all, > =20 > The Cloud Security Alliance intellectual property, including the Cloud = Controls Matrix, can be used royalty free with attribution, should you = wish to use it. We are making some updates to the Cloud Controls Matrix, = and I have Cc'ed Becky Swain who can answer any questions you might have = about the updates. > =20 > Regards, > =20 > John > > =20 > From: Luis Nunez > Date: Wednesday, August 8, 2012 9:50 AM > To: "Waltermire, David A." > Cc: Ruben Oliva , , = > Subject: Re: [mile] [sacm] Strategic alignment of security with = business in SACM in an international context > =20 > I had mention the Cloud Security Matrix (Cloud Security Alliance) in = another thread. > 1. is this something we can use as basis for mapping the various = regulations to a common id? > 2. Is this SACM or MILE GRC related work? > =20 > thanks. > -ln > =20 > On Aug 8, 2012, at 12:37 PM, Waltermire, David A. wrote: >=20 >=20 > The challenge we will likely face in scoping down the effort is that = we might not be able to work on the full stack that supports low-level = data collection, as well as higher level security processes and = controls. This is because we will likely need to charter around a lower = layer of function. This is why we need to scope as part of this work an = architecture document that illustrates how the smaller scope of work = fits into the larger picture that supports alignment with international = compliance models. > =20 > To say it a different way, we need to define a comprehensive picture = of the =93end state=94, even though we may only get part way there based = on an initial SACM charter. > =20 > We can use documents like ISO 27001 as guidance in producing the = architecture document to insure that the end state aligns well with your = concerns below. > =20 > Sincerely, > Dave > =20 > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of david.oliva@verizon.net > Sent: Wednesday, August 08, 2012 10:22 AM > To: lnunez@c3isecurity.com; sacm@ietf.org > Subject: [sacm] Strategic alignment of security with business in SACM = in an international context > =20 > =20 > Luis and all: >=20 > Unless we can demonstrate that the technologies and specifications we = are developing align with the security objectives of international = compliance models (such as ISO 27001) we cannot demonstrate strategic = alignment of business and security objectives in their context.=20 >=20 > Strategic alignment of security objectives with business objectives = can be at least partially joined via SACM thru the SP 800-53 to ISO = 27001 mapping table. If this were to happen to SACM then the validated = products will have less appeal and less marketability. The validated = products will work fine, but they will work with limited capability and = scope. For example, currently validated SCAP 1.0 products do not use = the Open Checklist Interactive Language (OCIL). OCIL is an open = specification (created by the security community for use by anybody, any = developer, any country) that facilitates non-automated assessment of = security processes. OCIL would allow an ISO 27001 compliance assessor = in Germany to create a question =93Does the organization comply ISO/IEC = 27001:2005 para 4.2.2 e) =91Does the organization implement a training = and awareness programme=92=94 and answer =91yes=92 or =91no=92. Then = the results can be accessed and read whether the organization uses = product X or product Y because OCIL is an open security specification. = Another example of OCIL is a rather mundane security function of = universal use. OCIL allows an ISO 27001 security compliance officer to = answer =91yes=92 or =91no=92 to the question =93Is the door shut?=94 and = make the result electronically readable whether he/she uses product X or = product Y. As for business, the flexibility of OCIL allows a company to = create a question =93Did the company reach our 7% profit strategic = objective over the past 10 years?=94 and able to answer it =91yes=92 or = =91no=92 with product X, Y, or Z and ensure interoperability. >=20 > =20 >=20 > David Oliva >=20 > =20 >=20 > =20 > =20 > On 08/07/12, Luis Nunez wrote: > =20 > Thanks the comment. I am glad someone agrees with me :) > =20 > -ln > =20 > On Aug 7, 2012, at 11:46 AM, david.oliva@verizon.net wrote: >=20 >=20 >=20 > Luis and all: > =20 > You are on target. > SACM is not a law enforcement thing, but is a facilitator of legal = issues in association with the protection of private information and = health-related information. >=20 > I think a couple of examples to show how SACM facilitates legal issues = about personal information is in order. >=20 > A SACM configuration scanner is able to monitor the configuration of = security controls as specified in ISO/IEC 27001:2005. This can be = accomplished when tier IV SCAP content is used because the output maps = the finding (compliance or non-compliance) of the scanner to security = control ISO/IEC 27001:2005 paragraph A.10.6.2 =93Security of Network = Services=94. Thus a SACM scanner is able to assist in international = governance compliance about personal information because SP 800-53 maps = to ISO 27001. >=20 > A SACM vulnerability scanner is able to meet compliance with ISO = 27001, para A.12.6.1 =93Control of technical vulnerabilities=94 because = a SACM scanner using SCAP tier IV content can map its output to the ISO = governance. SACM Vulnerability scanning can address aspects of = confidentiality of personal information by identifying software = vulnerabilities of the databases that house them, and do it in the = context of an international set of security standards. >=20 > =20 > David Oliva > =20 > =20 > =20 > On 08/06/12, Luis Nunez wrote: > =20 > Looking at it another way I could see security automation as a way to = discover if a system is configured to meet privacy policies . =20 > =20 > Security automation is an enabler for transparency so that = individuals and organizations may understand the complex computing = environment. > =20 > Thanks for bring up this issue. As a community we may want to look at = building content around privacy controls. > =20 > -ln > =20 > On Aug 6, 2012, at 12:42 PM, wrote: >=20 >=20 >=20 > None of the efforts we are talking about for SACM are targeted toward = PII or individuals. They are targeted at the configuration of the = platforms deployed in the enterprise to assure they comply with the = site's security policy. PII is not collected. This is not monitoring of = individual or employee actions. I am not a lawyer and will not speak as = one. We will let the lawyer's decide at the appropriate time. > =20 > Kent Landfield >=20 > McAfee | An Intel Company > Direct: +1.972.963.7096=20 > Mobile: +1.817.637.8026 > Web: www.mcafee.com > =20 > From: Martin Rex > Reply-To: "mrex@sap.com" > Date: Monday, August 6, 2012 11:32 AM > To: "tony@yaanatech.com" > Cc: "mrex@sap.com" , "sacm@ietf.org" > Subject: Re: [sacm] Legal aspects of System monitoring > =20 > Tony Rutkowski wrote: > Martin Rex wrote: > =20 > In Germany, an employer monitoring a company-owned PC that an employee = uses > for communication (EMail, VoiP, IM) would be unconditionally illegal. > =20 > Really? > =20 > No kidding! > =20 > =20 > =20 > That is not consistent with comments > I've seen concerning German law. > =20 > There is a significant amount of mis-information floating the = internet. > And a mindboggling large number of lawyers are making wild guesses, = rather > that doing research. > =20 > The decisions of the german federal constitional court (GFCC) have = been > quite consistent over the past decade about what with respect to > encroaching on the general right of personality, informational > self-determination, freedom of conduct and created a "fundamental = right > to the guarantee of the integrity and confidentiality of information > technology systems". The court has set the minimum requirements that > are prerequisite to such encroachment, such as the prerequisite of a > clear formal statute law, which needs to be limited to situation where > real facts create probable cause. > =20 > The original GFCC decision in german language is quite comprehensible > (to me, at least), while I'm having some difficulties understanding > the english translation (and the english translation is shorter!?). > =20 > BVerfG-Entscheidung "1 BvR 370/07 vom 27.2.2008" Randnummer 196- > http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007.html#abs196 > =20 > english translation of "1 BvR 370/07 vom 27.2.2008" > = http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007en.html#abs130 > =20 > =20 > To be *unconditionally* illegal, would > preclude almost any rationally required > maintenance or threat mitigation. > =20 > It is possible to perform maintenance and threat mitigation entirely > without "monitoring" systems. > =20 > A mere threat is insufficient for monitoring, if that involves = collecting > PII data, i.e. data from which a persons conduct can be infered. > =20 > =20 > =20 > It is fair to observe that recent German > Constitutional Court decisions impose > constraints, but they certainly are > not "unconditional." > =20 > One of the prerequisite is a clear formal statute law, > which currently does not exist for the purposes "sacm" is about. > =20 > quoting from the above GFCC decision: > =20 > 2. The fundamental right to the guarantee of the confidentiality and > integrity of information technology systems is not unrestricted. > Encroachments may be justified both for preventive purposes, and for > criminal prosecution. The individual must only accept such = restrictions > of his or her right which are based on a statutory foundation that > is constitutional. > =20 > =20 > This currently makes collecting data about peoples conduct = "unconditionally" > illegal for most practical purposes (exempting from prosecution only > individual occasions of justified self-defence against an imminent > vicious attack based on real facts that create probable cause). > =20 > This applies to all surveillance that impairs persons "freedom of = conduct". > The majority of past decisions of specific events was about = surveillance > with a camera, but the GFCC decision makes it crystal clear that > this applies to *any* kind of surveillance. Different to monitoring = of > computer systems, there is statutory law for camera surveillance, > that allows optical surveillance under certain conditions > (Art. 6b BDSG "BundesDatenSchutzGesetz). > =20 > The lack of a formal statutory foundation makes surveillance illegal > and entitles subjects to "cease and desist" rulings and sometimes > damages. > =20 > In one more recent (and constitutionally correct) rulings, an employer > had put up a camera that had in view not only the entrance door, but > also two workplaces. The employees protested against this camera, > but the employer would not "fix" it, so at least one employee sued, > The court confirmed that this camera surveillance at the workplace > was illegal due to its chilling effect alone, and since it had been > installed for a whole year, the employee was arwarded 4 month of = income > as damages (for the chilling effect). > =20 > Another recent decision was about evidence from a covert video > surveillance showing an employee taking a package of cigarettes > on two occasions, where the German Federal Labour Court > (the supreme court for labor related issues) remanded the decision > to the trial court because it had failed to establish whether the > covert video surveillance really met all constitutional prerequisites > otherwise the video surveillance would have been illegal and not > be admissible as evidence in court. > (German decision: http://lexetius.com/2012,2351) > =20 > The German Federal Constitional Court neutered numerous laws during = the > last decade due to lack of clarity and/or overbroad encroachment of > the personal right of self-determination and the right to = confidentiality > of telecommunications. > =20 > See also the GFCC decision about the scanning of license plates > (the decision 1 BvR 2074/05 vom 11.3.2008 in german) > http://www.bverfg.de/entscheidungen/rs20080311_1bvr2-07405.html > =20 > where it confirmed that data collection requires formal statue law, > and that the law in question wasn't limited to probable cause and > therefore unconstitutional. > =20 > =20 > The only currently existing formal statue law in Germany, that could = be > used in some limited fashion for "Monitoring" is Art.100 TKG, > http://www.gesetze-im-internet.de/tkg_2004/__100.html > but that statue is clearly limited in purpose, it will not allow that = data > to be used for automatic surveillance of "employee conduct" with = respect > to "company-defined policies". Employers try hard to avoid TKG for = their > networks (for which they will have to formally register), but that = also > means that they do not have a formal statutory law for performing any > kind of surveillance/monitoring as described in Art. 100 TKG for = systems > that are used by employees for telecommunications and a significant = part > of their daily activies. > =20 > =20 > -Martin > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > =20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > =20 > =20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > =20 > _______________________________________________ mile mailing list = mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --Apple-Mail=_943AAED8-1F4F-4A8F-B898-BC1D19BAD440 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 John,
thanks for the information and = intro.

Hi Becky,
CCM is a worth while = effort that contributes tremendously to = community.

Some questions I have = is:
1. Do you see CCM expand to other controls sets or what is = currently mapped good enough for coverage? 
2. CCM is for = cloud environments, is there a difference if you apply to non-cloud = environments?  Looking to see if there is gap in mapping if CCM is = applied to non-cloud = environments.

Thanks.

-l= n
 
On Aug 15, 2012, at 10:16 AM, Becky = Swain wrote:

John, = thanks for adding me to the communication = thread.
Luis et = al, if there are any questions on CCM or specifically on what is = changing for CCM v2.0, please let me know how I could = assist.
Becky Swain
 +1 (650) = 520-0263
(skype) rebeccadswain
 @rebeccadswain
From: John Howie = [mailto:jhowie@cloudsecurityalliance.org] 
Sent: Tuesday, August 14, 2012 = 9:39 PM
To: Luis Nunez; Waltermire, = David A.
Cc: Ruben Oliva; mile@ietf.org; sacm@ietf.org; Becky Swain
Subject: Re: [mile] [sacm] Strategic = alignment of security with business in SACM in an international = context
Hi = all,
The Cloud Security Alliance intellectual property, including = the Cloud Controls Matrix, can be used royalty free with attribution, = should you wish to use it. We are making some updates to the Cloud = Controls Matrix, and I have Cc'ed Becky Swain who can answer any = questions you might have about the = updates.
 
 
John
 


The challenge we will likely face = in scoping down the effort is that we might not be able to work on the = full stack that supports low-level data collection, as well as higher = level security processes and controls.  This is because we will = likely need to charter around a lower layer of function.  This is = why we need to scope as part of this work an architecture document that = illustrates how the smaller scope of work fits into the larger picture = that supports alignment with international compliance = models.To = say it a different way, we need to define a comprehensive picture of the = =93end state=94, even though we may only get part way there based on an = initial SACM charter.We = can use documents like ISO 27001 as guidance in producing the = architecture document to insure that the end state aligns well with your = concerns below.
sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of  Wednesday, August 08, 2012 = 10:22 AM
To: lnunez@c3isecurity.com; sacm@ietf.org
Subject: [sacm] Strategic alignment = of security with business in SACM in an international = context Unless we can demonstrate that the = technologies and specifications we are developing align with the = security objectives of international compliance models (such as ISO = 27001) we cannot demonstrate strategic alignment of business and = security objectives in their context. 

Strategic = alignment of security objectives with business objectives can be at = least partially joined via SACM thru the SP 800-53 to ISO 27001 mapping = table.  If this were to happen to SACM then the validated products = will have less appeal and less marketability. The validated products = will work fine, but they will work with limited capability and = scope.  For example, currently validated SCAP 1.0 products do not = use the Open Checklist Interactive Language (OCIL).   OCIL is = an open specification (created by the security community for use by = anybody, any developer, any country) that facilitates non-automated = assessment of security processes.  OCIL would allow an ISO 27001 = compliance assessor in Germany to create a question =93Does the = organization comply ISO/IEC 27001:2005 para 4.2.2 e) =91Does the = organization implement a training and awareness programme=92=94 and = answer =91yes=92 or =91no=92.  Then the results can be accessed and = read whether the organization uses product X or product Y because OCIL = is an open security specification.  Another example of OCIL is a = rather mundane security function of universal use.  OCIL allows an = ISO 27001 security compliance officer to answer =91yes=92 or =91no=92 to = the question =93Is the door shut?=94 and make the result electronically = readable whether he/she uses product X or product Y.  As for = business, the flexibility of OCIL allows a company to create a question = =93Did the company reach our 7% profit strategic objective over the past = 10 years?=94 and able to answer it =91yes=92 or =91no=92 with product X, = Y, or Z and ensure interoperability. 

 

 



 Luis and all:I think a couple of examples to = show how SACM facilitates legal issues about personal information is in = order.

A SACM configuration scanner is able to = monitor the configuration of security controls as specified in ISO/IEC = 27001:2005.  This can be accomplished when tier IV SCAP content is = used because the output maps the finding (compliance or non-compliance) = of the scanner to security control ISO/IEC 27001:2005 paragraph A.10.6.2 = =93Security of Network Services=94.  Thus a SACM scanner is able to = assist in international governance compliance about personal information = because SP 800-53 maps to ISO 27001.A SACM vulnerability scanner is = able to meet compliance with ISO 27001, para A.12.6.1 =93Control of = technical vulnerabilities=94 because a SACM scanner using SCAP tier IV = content can map its output to the ISO governance.  SACM = Vulnerability scanning can address aspects of confidentiality of = personal information by identifying software vulnerabilities of the = databases that house them, and do it in the context of an international = set of security standards. David = Oliva 

  



None of the efforts we = are talking about for SACM are targeted toward PII or individuals. They = are targeted at the configuration of the platforms deployed in the = enterprise to assure they comply with the site's security policy. =  PII is not collected. This is not monitoring of individual or = employee actions.  I am not a lawyer and will not speak as one. We = will let the lawyer's decide at the appropriate = time.
Kent = Landfield

McAfee | An Intel = Company
Direct: = +1.972.963.7096 
Mobile: = +1.817.637.8026
Web: 
From: Martin Rex < "mrex@sap.com" <mrex@sap.com>
Date: Monday, August 6, 2012 = 11:32 AM
To: "tony@yaanatech.com" < "mrex@sap.com" <mrex@sap.com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Legal = aspects of System monitoringTony = Rutkowski wrote:
Martin Rex = wrote:
In Germany, an employer = monitoring a company-owned PC that an employee = uses
for communication = (EMail, VoiP, IM) would be unconditionally = illegal.
No = kidding!
That is not consistent = with comments
I've seen concerning = German = law.
There is a significant = amount of mis-information floating the = internet.
And a mindboggling large = number of lawyers are making wild guesses, = rather
that doing = research.
The decisions of the = german federal constitional court (GFCC) have = been
quite consistent over = the past decade about what with respect = to
encroaching on the general right of = personality, = informational
self-determination, = freedom of conduct and created a "fundamental = right
to the guarantee of the = integrity and confidentiality of = information
technology = systems".  The court has set the minimum requirements = that
are prerequisite to such = encroachment, such as the prerequisite of = a
clear formal statute law, which needs to be = limited to situation = where
real facts create = probable cause.
The original GFCC = decision in german language is quite = comprehensible
(to me, at least), while = I'm having some difficulties = understanding
the english translation = (and the english translation is = shorter!?).
BVerfG-Entscheidung "1 = BvR 370/07 vom 27.2.2008" Randnummer = 196-
sacm@ietf.org
 mile@ietf.org , Omar Santos , Adam Montville Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 15 Aug 2012 15:48:20 -0000 +1 -ln On Aug 15, 2012, at 11:24 AM, Stephen Hanna wrote: > I agree. Let's work on UC1 and UC3. The other use cases are > valuable but just doing UC1 and UC3 is plenty of work for this > group for the next year or two (maybe five!). > > I saw several emails in favor of this a few weeks ago. I thought > that it was settled. I'd like to see a revised charter and use case > document, scoped down to focus on just UC1 and UC3. > > What do others think? Do we have rough consensus on this? > If so, let's get moving. > > Thanks, > > Steve > >> -----Original Message----- >> From: Adam Montville [mailto:amontville@tripwire.com] >> Sent: Wednesday, August 15, 2012 10:30 AM >> To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos >> Cc: sacm@ietf.org >> Subject: Re: [sacm] Proposed use cases to move forward >> >> On 8/6/12 7:27 AM, "Adam Montville" wrote: >> >>> >>> >>> UC1 and UC3 both require assessment of endpoint state. If not for the >> NEA >>> ties in UC1, it seems a subset of UC3. So, we should be able to start >>> with the main concern of UC3: Security Configuration Management. >>> >>> >> >> >> I haven't seen much activity on this thread (there was another thread, >> "Using the Frame of Reference," discussing some approaches we can use >> to >> keep us focused and meaningful). >> >> Are there any objections to tackling UC3 followed by UC1? Does anyone >> disagree with my assertion that UC3 is a subset of UC1 and that a >> reasonable starting point is Security Configuration Management? >> > From amontville@tripwire.com Wed Aug 15 09:17: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 1CE8121F8834 for ; Wed, 15 Aug 2012 09:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-6C6nt24Z1k for ; Wed, 15 Aug 2012 09:17:55 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB7621E80EF for ; Wed, 15 Aug 2012 09:17:55 -0700 (PDT) Received: from mail129-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 15 Aug 2012 16:17:54 +0000 Received: from mail129-va3 (localhost [127.0.0.1]) by mail129-va3-R.bigfish.com (Postfix) with ESMTP id A56A7260518; Wed, 15 Aug 2012 16:17:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zzbb2dI98dI9371Izz1202hzz8275chz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail129-va3 (localhost.localdomain [127.0.0.1]) by mail129-va3 (MessageSwitch) id 1345047472530752_2765; Wed, 15 Aug 2012 16:17:52 +0000 (UTC) Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.244]) by mail129-va3.bigfish.com (Postfix) with ESMTP id 7D157160069; Wed, 15 Aug 2012 16:17:52 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 15 Aug 2012 16:17:49 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Aug 2012 09:19:39 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Wed, 15 Aug 2012 09:17:48 -0700 From: Adam Montville To: Stephen Hanna , Luis Nunez , Omar Santos Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAAAvxbAA== Date: Wed, 15 Aug 2012 16:17:47 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <13362E459536804FB384BE3FB480601C@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 15 Aug 2012 16:17:56 -0000 On 8/15/12 8:24 AM, "Stephen Hanna" wrote: >Do we have rough consensus on this? I believe we do. Does anyone disagree? From david.oliva@verizon.net Wed Aug 15 09:30: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 878AE21F8804 for ; Wed, 15 Aug 2012 09:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.564 X-Spam-Level: X-Spam-Status: No, score=-0.564 tagged_above=-999 required=5 tests=[AWL=0.480, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzAGEcG5nYKV for ; Wed, 15 Aug 2012 09:30:21 -0700 (PDT) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0F54821F87DB for ; Wed, 15 Aug 2012 09:30:21 -0700 (PDT) Received: from vms170025pub.verizon.net ([unknown] [192.168.1.3]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M8T001TH1U99630@vms173019.mailsrvcs.net> for sacm@ietf.org; Wed, 15 Aug 2012 11:30:10 -0500 (CDT) Received: from 96.241.55.45 ([96.241.55.45]) by vms170025 (Verizon Webmail) with HTTP; Wed, 15 Aug 2012 11:30:09 -0500 (CDT) Date: Wed, 15 Aug 2012 11:30:09 -0500 (CDT) From: david.oliva@verizon.net To: shanna@juniper.net, sacm@ietf.org, anton@chuvakin.org Message-id: <10469770.153890.1345048209584.JavaMail.root@vms170025> 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.55.45] Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 15 Aug 2012 16:30:21 -0000
&nb= sp;Hello all:
 
I think in terms on which specific= ations to associate with each use case.
 
For UC1= , I can think AI and ARF for Asset Information, CCE and CCSS for syste= m configuration, CVE and CVSS for System vulnerability.
 
But I just cannot see which spec in SCAP 1.2  to associat= e system weanesses.  The only thing close to a spec that approaches th= ese criteria are the Common Weakness Enumeration (CWE) and Common Weakness = Scoring System (CWSS) that MITRE is working one.   But these two = specifications are not ready yet.  If CWE and CWSS are part of a futur= e version of SACM/SCAP then yes.
 
For = UC3, I cannot see which spec in SCAP 1.2 to associate with network events.&= nbsp; The only thing close to a spec that approaches this criterion is the = Common Events Enumeration (CEE) that Dr. Chuvakin is working on.
=
In a short question to Dr. Chuvakin about the possibility of CEE and S= CAP working together he replied "CEE can work with SCAP via OVAL, CPE, AI a= nd ARF to report
events identifying the affected assets in a standard wa= y".  If CEE is part of a future SACM version, then yes.
 
David Oliva
 
 
=
On 08/15/12, <= SPAN>Stephen Hanna<shanna@juniper.net> wrote:
 = ;
I= agree. Let's work on UC1 and UC3. The other use cases are
valuable but = just doing UC1 and UC3 is plenty of work for this
group for the next yea= r or two (maybe five!).

I saw several emails in favor of this a few = weeks ago. I thought
that it was settled. I'd like to see a revised char= ter and use case
document, scoped down to focus on just UC1 and UC3.
=
What do others think? Do we have rough consensus on this?
If so, let= 's get moving.

Thanks,

Steve

> -----Original Messag= e-----
> From: Adam Montville [mailto:amontville@tripwire.com]=
> Sent: Wednesday, August 15, 2012 10:30 AM
> To: Adam Montvil= le; Stephen Hanna; Luis Nunez; Omar Santos
> Cc: sacm@ietf.org
> = Subject: Re: [sacm] Proposed use cases to move forward
>
> On = 8/6/12 7:27 AM, "Adam Montville" <amontville@tripwire.com> wr= ote:
>
> >
> >
> >UC1 and UC3 both requir= e assessment of endpoint state. If not for the
> NEA
> >ties= in UC1, it seems a subset of UC3. So, we should be able to start
> &= gt;with the main concern of UC3: Security Configuration Management.
>= >
> >
>
>
> I haven't seen much activity o= n this thread (there was another thread,
> "Using the Frame of Refere= nce," discussing some approaches we can use
> to
> keep us focu= sed and meaningful).
>
> Are there any objections to tackling = UC3 followed by UC1? Does anyone
> disagree with my assertion that UC= 3 is a subset of UC1 and that a
> reasonable starting point is Securi= ty Configuration Management?
>

______________________________= _________________
sacm mailing list
sacm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sacm
From david.waltermire@nist.gov Wed Aug 15 10:13: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 D64E321F87AE for ; Wed, 15 Aug 2012 10:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHCYo4fcdhES for ; Wed, 15 Aug 2012 10:13:14 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id AC04821F8797 for ; Wed, 15 Aug 2012 10:13:13 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Aug 2012 13:12:30 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 15 Aug 2012 13:10:59 -0400 From: "Waltermire, David A." To: Stephen Hanna , Adam Montville , Luis Nunez , Omar Santos Date: Wed, 15 Aug 2012 13:12:45 -0400 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 15 Aug 2012 17:13:15 -0000 +1 on scoping the charter to UC1 and UC3. I think we are better served with a use cases document, and eventually an architecture documemnt, that is broader scoped. Both of these documents will help inform the work we will do under the charter as it relates to the larger context. To this end I would suggest we focus on expanding the use case document primarily in the areas of UC1 and UC3 for now. We can expand the other use cases later. Sincerely, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Stephen Hanna > Sent: Wednesday, August 15, 2012 11:24 AM > To: Adam Montville; Luis Nunez; Omar Santos > Cc: sacm@ietf.org > Subject: Re: [sacm] Proposed use cases to move forward > > I agree. Let's work on UC1 and UC3. The other use cases are valuable > but just doing UC1 and UC3 is plenty of work for this group for the > next year or two (maybe five!). > > I saw several emails in favor of this a few weeks ago. I thought that > it was settled. I'd like to see a revised charter and use case > document, scoped down to focus on just UC1 and UC3. > > What do others think? Do we have rough consensus on this? > If so, let's get moving. > > Thanks, > > Steve > > > -----Original Message----- > > From: Adam Montville [mailto:amontville@tripwire.com] > > Sent: Wednesday, August 15, 2012 10:30 AM > > To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Proposed use cases to move forward > > > > On 8/6/12 7:27 AM, "Adam Montville" wrote: > > > > > > > > > > >UC1 and UC3 both require assessment of endpoint state. If not for > the > > NEA > > >ties in UC1, it seems a subset of UC3. So, we should be able to > > >start with the main concern of UC3: Security Configuration > Management. > > > > > > > > > > > > I haven't seen much activity on this thread (there was another > thread, > > "Using the Frame of Reference," discussing some approaches we can use > > to keep us focused and meaningful). > > > > Are there any objections to tackling UC3 followed by UC1? Does > anyone > > disagree with my assertion that UC3 is a subset of UC1 and that a > > reasonable starting point is Security Configuration Management? > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From amontville@tripwire.com Wed Aug 15 10:40: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 B850721F867B for ; Wed, 15 Aug 2012 10:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.88 X-Spam-Level: X-Spam-Status: No, score=-3.88 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4RkBBf+9B0S for ; Wed, 15 Aug 2012 10:40:57 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB3F21F8634 for ; Wed, 15 Aug 2012 10:40:55 -0700 (PDT) Received: from mail72-db3-R.bigfish.com (10.3.81.227) by DB3EHSOBE010.bigfish.com (10.3.84.30) with Microsoft SMTP Server id 14.1.225.23; Wed, 15 Aug 2012 17:40:54 +0000 Received: from mail72-db3 (localhost [127.0.0.1]) by mail72-db3-R.bigfish.com (Postfix) with ESMTP id 7C35DE048A; Wed, 15 Aug 2012 17:40:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zzbb2dI98dI9371Izz1202hzzz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail72-db3 (localhost.localdomain [127.0.0.1]) by mail72-db3 (MessageSwitch) id 1345052452238539_15357; Wed, 15 Aug 2012 17:40:52 +0000 (UTC) Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.242]) by mail72-db3.bigfish.com (Postfix) with ESMTP id 33C3FC0304; Wed, 15 Aug 2012 17:40:52 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 15 Aug 2012 17:40:51 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Aug 2012 10:42:39 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Wed, 15 Aug 2012 10:40:48 -0700 From: Adam Montville To: "Waltermire, David A." , Stephen Hanna , Luis Nunez , Omar Santos Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABIwmA Date: Wed, 15 Aug 2012 17:40:47 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.16.97.10] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <2AD2055BBB0E1747AD16109707162648@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 15 Aug 2012 17:40:58 -0000 On 8/15/12 10:12 AM, "Waltermire, David A." wrote: >To this end I would suggest we focus on expanding the use case document >primarily in the areas of UC1 and UC3 for now. We can expand the other >use cases later. How would you prefer to get started? I have some time set aside on Friday to devote to this effort exclusively. I am happy to work on polishing section 3.3 and start on corresponding language in sections 4, 5, and 6. Adam From david.waltermire@nist.gov Wed Aug 15 10:52:59 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 8BB2111E80BA for ; Wed, 15 Aug 2012 10:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.487 X-Spam-Level: X-Spam-Status: No, score=-6.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtBO-D50u9sv for ; Wed, 15 Aug 2012 10:52:57 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 07CBF11E8091 for ; Wed, 15 Aug 2012 10:52:55 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Aug 2012 13:52:35 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 15 Aug 2012 13:51:04 -0400 From: "Waltermire, David A." To: Adam Montville , Stephen Hanna , Luis Nunez , Omar Santos Date: Wed, 15 Aug 2012 13:52:51 -0400 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABIwmAAABNVrA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 15 Aug 2012 17:52:59 -0000 Adam, That works for me. As I mentioned, my preference would be to flesh out all sections relative to UC1 and UC3. I would be happy to meet with you on Friday morning to dicuss how to collaborate on the edits. We have plenty of good content to include from all the list discussion. Sincerely, Dave > -----Original Message----- > From: Adam Montville [mailto:amontville@tripwire.com] > Sent: Wednesday, August 15, 2012 1:41 PM > To: Waltermire, David A.; Stephen Hanna; Luis Nunez; Omar Santos > Cc: sacm@ietf.org > Subject: Re: [sacm] Proposed use cases to move forward > > On 8/15/12 10:12 AM, "Waltermire, David A." > wrote: > > >To this end I would suggest we focus on expanding the use case > document > >primarily in the areas of UC1 and UC3 for now. We can expand the > other > >use cases later. > > > How would you prefer to get started? I have some time set aside on > Friday to devote to this effort exclusively. I am happy to work on > polishing section 3.3 and start on corresponding language in sections > 4, 5, and 6. > > Adam > From amontville@tripwire.com Wed Aug 15 10:56: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 4950321F8609 for ; Wed, 15 Aug 2012 10:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.372 X-Spam-Level: X-Spam-Status: No, score=-5.372 tagged_above=-999 required=5 tests=[AWL=1.227, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOZm9tVMRpJl for ; Wed, 15 Aug 2012 10:56:33 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id A8A9221F861D for ; Wed, 15 Aug 2012 10:56:33 -0700 (PDT) Received: from mail149-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 15 Aug 2012 17:56:33 +0000 Received: from mail149-tx2 (localhost [127.0.0.1]) by mail149-tx2-R.bigfish.com (Postfix) with ESMTP id 15C661E03B4; Wed, 15 Aug 2012 17:56:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1202hzzz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail149-tx2 (localhost.localdomain [127.0.0.1]) by mail149-tx2 (MessageSwitch) id 1345053390825866_960; Wed, 15 Aug 2012 17:56:30 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.248]) by mail149-tx2.bigfish.com (Postfix) with ESMTP id C54D94600E9; Wed, 15 Aug 2012 17:56:30 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 15 Aug 2012 17:56:30 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Aug 2012 10:58:19 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Wed, 15 Aug 2012 10:56:29 -0700 From: Adam Montville To: "Waltermire, David A." , Stephen Hanna , Luis Nunez , Omar Santos Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABIwmAAABNVrAAAD6WAA== Date: Wed, 15 Aug 2012 17:56:28 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.16.97.10] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 15 Aug 2012 17:56:34 -0000 On 8/15/12 10:52 AM, "Waltermire, David A." wrote: >Adam, > >That works for me. As I mentioned, my preference would be to flesh out >all sections relative to UC1 and UC3. I would be happy to meet with you >on Friday morning to dicuss how to collaborate on the edits. We have >plenty of good content to include from all the list discussion. Agreed. Friday's wide open for me, so just let me know when you plan to call. > >Sincerely, >Dave > > From david.waltermire@nist.gov Wed Aug 15 11:02:25 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8171E21F8745 for ; Wed, 15 Aug 2012 11:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjQEaO9iGtVi for ; Wed, 15 Aug 2012 11:02:25 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id B73EB21F8742 for ; Wed, 15 Aug 2012 11:02:12 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Aug 2012 14:01:52 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 15 Aug 2012 14:00:21 -0400 From: "Waltermire, David A." To: Adam Montville , Stephen Hanna , Luis Nunez , Omar Santos Date: Wed, 15 Aug 2012 14:02:08 -0400 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABIwmAAABNVrAAAD6WAAAALWcg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 15 Aug 2012 18:02:25 -0000 Would 10a EDT work for you? Thanks, Dave > -----Original Message----- > From: Adam Montville [mailto:amontville@tripwire.com] > Sent: Wednesday, August 15, 2012 1:56 PM > To: Waltermire, David A.; Stephen Hanna; Luis Nunez; Omar Santos > Cc: sacm@ietf.org > Subject: Re: [sacm] Proposed use cases to move forward > > On 8/15/12 10:52 AM, "Waltermire, David A." > wrote: > > >Adam, > > > >That works for me. As I mentioned, my preference would be to flesh > out > >all sections relative to UC1 and UC3. I would be happy to meet with > >you on Friday morning to dicuss how to collaborate on the edits. We > >have plenty of good content to include from all the list discussion. > > > Agreed. Friday's wide open for me, so just let me know when you plan > to call. > > > > >Sincerely, > >Dave > > > > > > From amontville@tripwire.com Wed Aug 15 11:09: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 02A9C11E80DE for ; Wed, 15 Aug 2012 11:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.404 X-Spam-Level: X-Spam-Status: No, score=-5.404 tagged_above=-999 required=5 tests=[AWL=1.195, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol8zBDTz4MWK for ; Wed, 15 Aug 2012 11:09:34 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF2E11E80DC for ; Wed, 15 Aug 2012 11:09:34 -0700 (PDT) Received: from mail107-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 15 Aug 2012 18:09:33 +0000 Received: from mail107-tx2 (localhost [127.0.0.1]) by mail107-tx2-R.bigfish.com (Postfix) with ESMTP id C01D44038E; Wed, 15 Aug 2012 18:09:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zzbb2dI98dI9371I542M1432I4015Izz1202hzz1033IL8275dhz2dh2a8h668h839h944hd25he5bhf0ah107ah) Received: from mail107-tx2 (localhost.localdomain [127.0.0.1]) by mail107-tx2 (MessageSwitch) id 1345054172176355_4921; Wed, 15 Aug 2012 18:09:32 +0000 (UTC) Received: from TX2EHSMHS018.bigfish.com (unknown [10.9.14.249]) by mail107-tx2.bigfish.com (Postfix) with ESMTP id 20D711A02DB; Wed, 15 Aug 2012 18:09:32 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by TX2EHSMHS018.bigfish.com (10.9.99.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 15 Aug 2012 18:09:31 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Aug 2012 11:11:20 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Wed, 15 Aug 2012 11:09:30 -0700 From: Adam Montville To: "Waltermire, David A." Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABIwmAAABNVrAAAD6WAAAALWcgAABGqBI= Date: Wed, 15 Aug 2012 18:09:28 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Cc: Luis Nunez , Stephen Hanna , "sacm@ietf.org" , Omar Santos Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 15 Aug 2012 18:09:35 -0000 Yes. Sent from my iPhone On Aug 15, 2012, at 11:02 AM, "Waltermire, David A." wrote: > Would 10a EDT work for you? >=20 > Thanks, > Dave >=20 >=20 >> -----Original Message----- >> From: Adam Montville [mailto:amontville@tripwire.com] >> Sent: Wednesday, August 15, 2012 1:56 PM >> To: Waltermire, David A.; Stephen Hanna; Luis Nunez; Omar Santos >> Cc: sacm@ietf.org >> Subject: Re: [sacm] Proposed use cases to move forward >>=20 >> On 8/15/12 10:52 AM, "Waltermire, David A." >> wrote: >>=20 >>> Adam, >>>=20 >>> That works for me. As I mentioned, my preference would be to flesh >> out >>> all sections relative to UC1 and UC3. I would be happy to meet with >>> you on Friday morning to dicuss how to collaborate on the edits. We >>> have plenty of good content to include from all the list discussion. >>=20 >>=20 >> Agreed. Friday's wide open for me, so just let me know when you plan >> to call. >>=20 >>>=20 >>> Sincerely, >>> Dave >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From shanna@juniper.net Wed Aug 15 12:55:55 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D82A21F869A for ; Wed, 15 Aug 2012 12:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ax2zkimQl-J1 for ; Wed, 15 Aug 2012 12:55:54 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2A83A21F8698 for ; Wed, 15 Aug 2012 12:55:54 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUCv+wz8D555Z/zjfulKJDTXXEdBnt2hD@postini.com; Wed, 15 Aug 2012 12:55:54 PDT 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, 15 Aug 2012 12:55:30 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Aug 2012 12:55:29 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 15 Aug 2012 15:55:28 -0400 From: Stephen Hanna To: "Waltermire, David A." , Adam Montville , Luis Nunez , Omar Santos Date: Wed, 15 Aug 2012 15:55:27 -0400 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwg 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 15 Aug 2012 19:55:55 -0000 I love broad scope. Don't get me wrong! But I'm concerned about having a use cases document and an architecture document for this working group that goes way beyond the charter and initial scope for the group. I'm concerned that this will lead to lots of discussions on the sacm list and lots of effort being spent on topics that are out of scope, diverting us from the tasks at hand and slowing our progress. I'm concerned that the working group chairs won't be able to cut off discussion of topics by saying they're out of scope for the working group. I'm concerned that we'll get sidetracked or even derailed by controversies that aren't relevant to the scope of the group. I'm concerned that by including all of security automation within our use cases and architecture, we may actually prevent the formation of other working groups that could work on those other use cases. We have plenty of work to keep us busy for years with UC1 and UC3. There's agreement that the technology needed is mature enough for IETF standardization. I suggest that we scope this working group to address only those use cases and that our use cases and architecture be limited to them. I'm sorely tempted to create an ambitious architecture for security automation that encompasses all of the use cases that we have described so far and maybe more. I understand that people have a hard time understanding how the NEA and MILE and SACM standards fit together and I would love to address that in an IETF RFC. But I have seen several grand architecture efforts die or come to nothing in IETF. IETF is filled with smart engineers with clever ideas. We're great at solving problems but if we can't agree on the problem to solve or if we choose the wrong problem, we can easily spin an intricate and pointless web. I think we'll do better if we scope our effort properly. Maybe a few people can create an individual submission describing a grand architecture and roadmap for security automation and ask people in SACM to review and provide feedback on that document. That would be a good way to get a grand architecture while still ensuring that the SACM effort keeps its focus. In IETF as in so many things, you must keep your focus or you'll never succeed. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Waltermire, David A. > Sent: Wednesday, August 15, 2012 1:13 PM > To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos > Cc: sacm@ietf.org > Subject: Re: [sacm] Proposed use cases to move forward >=20 > +1 on scoping the charter to UC1 and UC3. >=20 > I think we are better served with a use cases document, and eventually > an architecture documemnt, that is broader scoped. Both of these > documents will help inform the work we will do under the charter as it > relates to the larger context. >=20 > To this end I would suggest we focus on expanding the use case document > primarily in the areas of UC1 and UC3 for now. We can expand the other > use cases later. >=20 > Sincerely, > Dave >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of > > Stephen Hanna > > Sent: Wednesday, August 15, 2012 11:24 AM > > To: Adam Montville; Luis Nunez; Omar Santos > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Proposed use cases to move forward > > > > I agree. Let's work on UC1 and UC3. The other use cases are valuable > > but just doing UC1 and UC3 is plenty of work for this group for the > > next year or two (maybe five!). > > > > I saw several emails in favor of this a few weeks ago. I thought that > > it was settled. I'd like to see a revised charter and use case > > document, scoped down to focus on just UC1 and UC3. > > > > What do others think? Do we have rough consensus on this? > > If so, let's get moving. > > > > Thanks, > > > > Steve > > > > > -----Original Message----- > > > From: Adam Montville [mailto:amontville@tripwire.com] > > > Sent: Wednesday, August 15, 2012 10:30 AM > > > To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos > > > Cc: sacm@ietf.org > > > Subject: Re: [sacm] Proposed use cases to move forward > > > > > > On 8/6/12 7:27 AM, "Adam Montville" > wrote: > > > > > > > > > > > > > > >UC1 and UC3 both require assessment of endpoint state. If not for > > the > > > NEA > > > >ties in UC1, it seems a subset of UC3. So, we should be able to > > > >start with the main concern of UC3: Security Configuration > > Management. > > > > > > > > > > > > > > > > > I haven't seen much activity on this thread (there was another > > thread, > > > "Using the Frame of Reference," discussing some approaches we can > use > > > to keep us focused and meaningful). > > > > > > Are there any objections to tackling UC3 followed by UC1? Does > > anyone > > > disagree with my assertion that UC3 is a subset of UC1 and that a > > > reasonable starting point is Security Configuration Management? > > > > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From gunnar.engelbach@threatguard.com Wed Aug 15 13:08: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 5BF7E21F8594 for ; Wed, 15 Aug 2012 13:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9ntZlCF5U7T for ; Wed, 15 Aug 2012 13:08:19 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8A25621F853A for ; Wed, 15 Aug 2012 13:08:19 -0700 (PDT) Received: (qmail 9722 invoked from network); 15 Aug 2012 13:07:30 -0700 Received: from h69-130-58-233.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.227?) (69.130.58.233) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 15 Aug 2012 13:07:29 -0700 Message-ID: <502C01C0.4050108@ThreatGuard.com> Date: Wed, 15 Aug 2012 16:08:32 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 CC: "sacm@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 15 Aug 2012 20:08:20 -0000 +2 It's worth having a broad document even if parts of it aren't clearly defined to stake out the expected scope of the working group and because considerations of the broader scope might affect decisions on the focus areas. But I absolutely agree that the best way to make real progress is to focus on a tight subset, and it looks like UC1 and UC3 is the consensus (and there's no dissent on that here). --gun On 8/15/2012 3:55 PM, Stephen Hanna wrote: > I love broad scope. Don't get me wrong! But I'm concerned about > having a use cases document and an architecture document for > this working group that goes way beyond the charter and initial > scope for the group. > > I'm concerned that this will lead to lots of discussions on > the sacm list and lots of effort being spent on topics that > are out of scope, diverting us from the tasks at hand and > slowing our progress. > > I'm concerned that the working group chairs won't be able to > cut off discussion of topics by saying they're out of scope > for the working group. > > I'm concerned that we'll get sidetracked or even derailed by > controversies that aren't relevant to the scope of the group. > > I'm concerned that by including all of security automation > within our use cases and architecture, we may actually prevent > the formation of other working groups that could work on > those other use cases. > > We have plenty of work to keep us busy for years with UC1 > and UC3. There's agreement that the technology needed is > mature enough for IETF standardization. I suggest that > we scope this working group to address only those use cases > and that our use cases and architecture be limited to them. > > I'm sorely tempted to create an ambitious architecture for > security automation that encompasses all of the use cases > that we have described so far and maybe more. I understand > that people have a hard time understanding how the NEA and > MILE and SACM standards fit together and I would love to > address that in an IETF RFC. But I have seen several grand > architecture efforts die or come to nothing in IETF. IETF is > filled with smart engineers with clever ideas. We're great at > solving problems but if we can't agree on the problem to solve > or if we choose the wrong problem, we can easily spin an > intricate and pointless web. > > I think we'll do better if we scope our effort properly. > > Maybe a few people can create an individual submission > describing a grand architecture and roadmap for security > automation and ask people in SACM to review and provide > feedback on that document. That would be a good way to get > a grand architecture while still ensuring that the SACM > effort keeps its focus. In IETF as in so many things, you > must keep your focus or you'll never succeed. > > Thanks, > > Steve > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Waltermire, David A. >> Sent: Wednesday, August 15, 2012 1:13 PM >> To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos >> Cc: sacm@ietf.org >> Subject: Re: [sacm] Proposed use cases to move forward >> >> +1 on scoping the charter to UC1 and UC3. >> >> I think we are better served with a use cases document, and eventually >> an architecture documemnt, that is broader scoped. Both of these >> documents will help inform the work we will do under the charter as it >> relates to the larger context. >> >> To this end I would suggest we focus on expanding the use case document >> primarily in the areas of UC1 and UC3 for now. We can expand the other >> use cases later. >> >> Sincerely, >> Dave >> >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >> Of >>> Stephen Hanna >>> Sent: Wednesday, August 15, 2012 11:24 AM >>> To: Adam Montville; Luis Nunez; Omar Santos >>> Cc: sacm@ietf.org >>> Subject: Re: [sacm] Proposed use cases to move forward >>> >>> I agree. Let's work on UC1 and UC3. The other use cases are valuable >>> but just doing UC1 and UC3 is plenty of work for this group for the >>> next year or two (maybe five!). >>> >>> I saw several emails in favor of this a few weeks ago. I thought that >>> it was settled. I'd like to see a revised charter and use case >>> document, scoped down to focus on just UC1 and UC3. >>> >>> What do others think? Do we have rough consensus on this? >>> If so, let's get moving. >>> >>> Thanks, >>> >>> Steve >>> >>>> -----Original Message----- >>>> From: Adam Montville [mailto:amontville@tripwire.com] >>>> Sent: Wednesday, August 15, 2012 10:30 AM >>>> To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos >>>> Cc: sacm@ietf.org >>>> Subject: Re: [sacm] Proposed use cases to move forward >>>> >>>> On 8/6/12 7:27 AM, "Adam Montville" >> wrote: >>>> >>>>> >>>>> >>>>> UC1 and UC3 both require assessment of endpoint state. If not for >>> the >>>> NEA >>>>> ties in UC1, it seems a subset of UC3. So, we should be able to >>>>> start with the main concern of UC3: Security Configuration >>> Management. >>>>> >>>>> >>>> >>>> >>>> I haven't seen much activity on this thread (there was another >>> thread, >>>> "Using the Frame of Reference," discussing some approaches we can >> use >>>> to keep us focused and meaningful). >>>> >>>> Are there any objections to tackling UC3 followed by UC1? Does >>> anyone >>>> disagree with my assertion that UC3 is a subset of UC1 and that a >>>> reasonable starting point is Security Configuration Management? >>>> >>> >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From kathleen.moriarty@emc.com Thu Aug 16 00:18: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 7B94421F8568; Thu, 16 Aug 2012 00:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 pxV26IfOpRrs; Thu, 16 Aug 2012 00:18:12 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 87A0F21F84FA; Thu, 16 Aug 2012 00:18:08 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q7G7Hv2T000375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2012 03:18:02 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 16 Aug 2012 03:17:31 -0400 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.222.70.236]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q7G7HSHU002481; Thu, 16 Aug 2012 03:17:28 -0400 Received: from mx15a.corp.emc.com ([169.254.1.66]) by mxhub15.corp.emc.com ([128.222.70.236]) with mapi; Thu, 16 Aug 2012 03:17:28 -0400 From: "Moriarty, Kathleen" To: John Howie , Luis Nunez , "Waltermire, David A." Date: Thu, 16 Aug 2012 03:16:24 -0400 Thread-Topic: [mile] [sacm] Strategic alignment of security with business in SACM in an international context Thread-Index: Ac16oAo1GneTJJwhSu+vlKaM5fsktgA3wDI4 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: Ruben Oliva , "mile@ietf.org" , "sacm@ietf.org" , Becky Swain Subject: Re: [sacm] [mile] Strategic alignment of security with business in SACM in an international context X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 16 Aug 2012 07:18:13 -0000 Thank you very much for the disclosure and offer, this could be extremely h= elpful! We will also need a form filled in on the IETF site for the disclosure, I'l= l email you separately. Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of John Howie= [jhowie@cloudsecurityalliance.org] Sent: Wednesday, August 15, 2012 12:39 AM To: Luis Nunez; Waltermire, David A. Cc: Ruben Oliva; mile@ietf.org; sacm@ietf.org; Becky Swain Subject: Re: [mile] [sacm] Strategic alignment of security with business in= SACM in an international context Hi all, The Cloud Security Alliance intellectual property, including the Cloud Cont= rols Matrix, can be used royalty free with attribution, should you wish to = use it. We are making some updates to the Cloud Controls Matrix, and I have= Cc'ed Becky Swain who can answer any questions you might have about the up= dates. Regards, John [cid:A936CCB9-0FA0-4F17-97F6-B45ABC11EFA3] From: Luis Nunez > Date: Wednesday, August 8, 2012 9:50 AM To: "Waltermire, David A." > Cc: Ruben Oliva >, = >, = > Subject: Re: [mile] [sacm] Strategic alignment of security with business in= SACM in an international context I had mention the Cloud Security Matrix (Cloud Security Alliance) in anothe= r thread. 1. is this something we can use as basis for mapping the various regulation= s to a common id? 2. Is this SACM or MILE GRC related work? thanks. -ln On Aug 8, 2012, at 12:37 PM, Waltermire, David A. wrote: The challenge we will likely face in scoping down the effort is that we mig= ht not be able to work on the full stack that supports low-level data colle= ction, as well as higher level security processes and controls. This is be= cause we will likely need to charter around a lower layer of function. Thi= s is why we need to scope as part of this work an architecture document tha= t illustrates how the smaller scope of work fits into the larger picture th= at supports alignment with international compliance models. To say it a different way, we need to define a comprehensive picture of the= =93end state=94, even though we may only get part way there based on an in= itial SACM charter. We can use documents like ISO 27001 as guidance in producing the architectu= re document to insure that the end state aligns well with your concerns bel= ow. Sincerely, Dave From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of david.oliva@verizon.net Sent: Wednesday, August 08, 2012 10:22 AM To: lnunez@c3isecurity.com; sacm@ietf.org Subject: [sacm] Strategic alignment of security with business in SACM in an= international context Luis and all: Unless we can demonstrate that the technologies and specifications we are d= eveloping align with the security objectives of international compliance mo= dels (such as ISO 27001) we cannot demonstrate strategic alignment of busin= ess and security objectives in their context. Strategic alignment of security objectives with business objectives can be = at least partially joined via SACM thru the SP 800-53 to ISO 27001 mapping = table. If this were to happen to SACM then the validated products will hav= e less appeal and less marketability. The validated products will work fine= , but they will work with limited capability and scope. For example, curre= ntly validated SCAP 1.0 products do not use the Open Checklist Interactive = Language (OCIL). OCIL is an open specification (created by the security c= ommunity for use by anybody, any developer, any country) that facilitates n= on-automated assessment of security processes. OCIL would allow an ISO 270= 01 compliance assessor in Germany to create a question =93Does the organiza= tion comply ISO/IEC 27001:2005 para 4.2.2 e) =91Does the organization imple= ment a training and awareness programme=92=94 and answer =91yes=92 or =91no= =92. Then the results can be accessed and read whether the organization us= es product X or product Y because OCIL is an open security specification. = Another example of OCIL is a rather mundane security function of universal = use. OCIL allows an ISO 27001 security compliance officer to answer =91yes= =92 or =91no=92 to the question =93Is the door shut?=94 and make the result= electronically readable whether he/she uses product X or product Y. As fo= r business, the flexibility of OCIL allows a company to create a question = =93Did the company reach our 7% profit strategic objective over the past 10= years?=94 and able to answer it =91yes=92 or =91no=92 with product X, Y, o= r Z and ensure interoperability. David Oliva On 08/07/12, Luis Nunez> wrote: Thanks the comment. I am glad someone agrees with me :) -ln On Aug 7, 2012, at 11:46 AM, david.oliva@verizon.net wrote: Luis and all: You are on target. SACM is not a law enforcement thing, but is a facilitator of legal issues i= n association with the protection of private information and health-related= information. I think a couple of examples to show how SACM facilitates legal issues abou= t personal information is in order. A SACM configuration scanner is able to monitor the configuration of securi= ty controls as specified in ISO/IEC 27001:2005. This can be accomplished w= hen tier IV SCAP content is used because the output maps the finding (compl= iance or non-compliance) of the scanner to security control ISO/IEC 27001:2= 005 paragraph A.10.6.2 =93Security of Network Services=94. Thus a SACM sca= nner is able to assist in international governance compliance about persona= l information because SP 800-53 maps to ISO 27001. A SACM vulnerability scanner is able to meet compliance with ISO 27001, par= a A.12.6.1 =93Control of technical vulnerabilities=94 because a SACM scanne= r using SCAP tier IV content can map its output to the ISO governance. SAC= M Vulnerability scanning can address aspects of confidentiality of personal= information by identifying software vulnerabilities of the databases that = house them, and do it in the context of an international set of security st= andards. David Oliva On 08/06/12, Luis Nunez> wrote: Looking at it another way I could see security automation as a way to disco= ver if a system is configured to meet privacy policies . Security automation is an enabler for transparency so that individuals and= organizations may understand the complex computing environment. Thanks for bring up this issue. As a community we may want to look at buil= ding content around privacy controls. -ln On Aug 6, 2012, at 12:42 PM, > wrote: None of the efforts we are talking about for SACM are targeted toward PII o= r individuals. They are targeted at the configuration of the platforms depl= oyed in the enterprise to assure they comply with the site's security polic= y. PII is not collected. This is not monitoring of individual or employee = actions. I am not a lawyer and will not speak as one. We will let the lawy= er's decide at the appropriate time. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Martin Rex > Reply-To: "mrex@sap.com" > Date: Monday, August 6, 2012 11:32 AM To: "tony@yaanatech.com" > Cc: "mrex@sap.com" >= , "sacm@ietf.org" > Subject: Re: [sacm] Legal aspects of System monitoring Tony Rutkowski wrote: Martin Rex wrote: In Germany, an employer monitoring a company-owned PC that an employee uses for communication (EMail, VoiP, IM) would be unconditionally illegal. Really? No kidding! That is not consistent with comments I've seen concerning German law. There is a significant amount of mis-information floating the internet. And a mindboggling large number of lawyers are making wild guesses, rather that doing research. The decisions of the german federal constitional court (GFCC) have been quite consistent over the past decade about what with respect to encroaching on the general right of personality, informational self-determination, freedom of conduct and created a "fundamental right to the guarantee of the integrity and confidentiality of information technology systems". The court has set the minimum requirements that are prerequisite to such encroachment, such as the prerequisite of a clear formal statute law, which needs to be limited to situation where real facts create probable cause. The original GFCC decision in german language is quite comprehensible (to me, at least), while I'm having some difficulties understanding the english translation (and the english translation is shorter!?). BVerfG-Entscheidung "1 BvR 370/07 vom 27.2.2008" Randnummer 196- http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007.html#abs196 english translation of "1 BvR 370/07 vom 27.2.2008" http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007en.html#abs130 To be *unconditionally* illegal, would preclude almost any rationally required maintenance or threat mitigation. It is possible to perform maintenance and threat mitigation entirely without "monitoring" systems. A mere threat is insufficient for monitoring, if that involves collecting PII data, i.e. data from which a persons conduct can be infered. It is fair to observe that recent German Constitutional Court decisions impose constraints, but they certainly are not "unconditional." One of the prerequisite is a clear formal statute law, which currently does not exist for the purposes "sacm" is about. quoting from the above GFCC decision: 2. The fundamental right to the guarantee of the confidentiality and integrity of information technology systems is not unrestricted. Encroachments may be justified both for preventive purposes, and for criminal prosecution. The individual must only accept such restrictions of his or her right which are based on a statutory foundation that is constitutional. This currently makes collecting data about peoples conduct "unconditionally= " illegal for most practical purposes (exempting from prosecution only individual occasions of justified self-defence against an imminent vicious attack based on real facts that create probable cause). This applies to all surveillance that impairs persons "freedom of conduct". The majority of past decisions of specific events was about surveillance with a camera, but the GFCC decision makes it crystal clear that this applies to *any* kind of surveillance. Different to monitoring of computer systems, there is statutory law for camera surveillance, that allows optical surveillance under certain conditions (Art. 6b BDSG "BundesDatenSchutzGesetz). The lack of a formal statutory foundation makes surveillance illegal and entitles subjects to "cease and desist" rulings and sometimes damages. In one more recent (and constitutionally correct) rulings, an employer had put up a camera that had in view not only the entrance door, but also two workplaces. The employees protested against this camera, but the employer would not "fix" it, so at least one employee sued, The court confirmed that this camera surveillance at the workplace was illegal due to its chilling effect alone, and since it had been installed for a whole year, the employee was arwarded 4 month of income as damages (for the chilling effect). Another recent decision was about evidence from a covert video surveillance showing an employee taking a package of cigarettes on two occasions, where the German Federal Labour Court (the supreme court for labor related issues) remanded the decision to the trial court because it had failed to establish whether the covert video surveillance really met all constitutional prerequisites otherwise the video surveillance would have been illegal and not be admissible as evidence in court. (German decision: http://lexetius.com/2012,2351) The German Federal Constitional Court neutered numerous laws during the last decade due to lack of clarity and/or overbroad encroachment of the personal right of self-determination and the right to confidentiality of telecommunications. See also the GFCC decision about the scanning of license plates (the decision 1 BvR 2074/05 vom 11.3.2008 in german) http://www.bverfg.de/entscheidungen/rs20080311_1bvr2-07405.html where it confirmed that data collection requires formal statue law, and that the law in question wasn't limited to probable cause and therefore unconstitutional. The only currently existing formal statue law in Germany, that could be used in some limited fashion for "Monitoring" is Art.100 TKG, http://www.gesetze-im-internet.de/tkg_2004/__100.html but that statue is clearly limited in purpose, it will not allow that data to be used for automatic surveillance of "employee conduct" with respect to "company-defined policies". Employers try hard to avoid TKG for their networks (for which they will have to formally register), but that also means that they do not have a formal statutory law for performing any kind of surveillance/monitoring as described in Art. 100 TKG for systems that are used by employees for telecommunications and a significant part of their daily activies. -Martin _______________________________________________ sacm mailing 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 _______________________________________________ mile mailing list mile@ietf= .org https://www.ietf.org/mailman/listinfo/mile From solin@farnamhallventures.com Thu Aug 9 07:31:44 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E7721F8698 for ; Thu, 9 Aug 2012 07:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 604nRtifMXlV for ; Thu, 9 Aug 2012 07:31:44 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 288B721F8690 for ; Thu, 9 Aug 2012 07:31:43 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so1020201pbb.31 for ; Thu, 09 Aug 2012 07:31:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=tkHjXIVh2YBf8zN1ESmi1djTRc3JzPZ9C5ihxmNiHBE=; b=ofETyX344luTsNqNZjhmKp0pOTwCERhVZIHx/vWiBYTrGStz/XDFONRSvoNVb2SC6e HJj/iKhKXmqCywy7g5FlhV4nRrWtpM39tu/PqQm6oCksmnOeuSNmJxUVlWrwWWcGuTnh GHdTnUIs9z8EN0tD/4QH7akc9Fseqj7z+/aDmFHnvwlQgVA+q2wH6zu+IW1kvljRu9mS yMLBwO4A4Rf0WGLH6+v5DgJzeiKY6q+kEa++6rojFxRDA/ugPYs5L35KDH80JOt7+LR8 uyvYsUSOvHSO0vv/KeSUkLAJTpWZBHbO8AvmEl9FS/eJ7GSqyhooCH9dBzoFo+yddsRS Qcqw== Received: by 10.68.222.40 with SMTP id qj8mr4482466pbc.139.1344522703640; Thu, 09 Aug 2012 07:31:43 -0700 (PDT) Received: from [10.230.220.144] (221.sub-174-254-81.myvzw.com. [174.254.81.221]) by mx.google.com with ESMTPS id oj8sm1245815pbb.54.2012.08.09.07.31.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Aug 2012 07:31:42 -0700 (PDT) References: <15316495.99085.1344520522988.JavaMail.root@vms170025> In-Reply-To: <15316495.99085.1344520522988.JavaMail.root@vms170025> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-57768D2B-DBB0-4DD7-9D86-EAF844779790 Message-Id: <61DFC600-543A-4394-9A44-6F2A0942BF18@farnamhallventures.com> X-Mailer: iPhone Mail (9B206) From: David Solin Date: Thu, 9 Aug 2012 07:31:38 -0700 To: "david.oliva@verizon.net" X-Gm-Message-State: ALoCoQn+j6qVoD0BQv6CJooWLuf1pmOmC5x2lNDbCybYfMeVrJzAfesDjSPv3/D95mc+St8C3ca7 X-Mailman-Approved-At: Fri, 17 Aug 2012 08:01:06 -0700 Cc: "sacm@ietf.org" Subject: Re: [sacm] =?utf-8?q?SACM_in_support_of_=E2=80=9CAsset_management?= =?utf-8?q?=E2=80=9D_in_compliance_with_ISO_27001?= X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 09 Aug 2012 14:31:44 -0000 --Apple-Mail-57768D2B-DBB0-4DD7-9D86-EAF844779790 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 David, Doesn't Verizon already use a CIM-based CMDB for asset management, ITSM and H= elpdesk functions - at least in some parts of the business? Can you elaborat= e on the benefits of introducing another standard? Regards, David Solin Sent from my iPhone On Aug 9, 2012, at 6:55 AM, david.oliva@verizon.net wrote: > Luis and all: >=20 > The new SCAP 1.2 (SACM) is adding two specifications (or formats for those= who have a bad taste of the term specification) associated with assets. Th= ese specs are the Asset Identification (AI) and Asset Reporting Format (ARF)= . The three specifications which developers should use for this purpose sho= uld be AI, ARF, and CPE (Common Platforms Enumeration). >=20 > SACM Asset Management applications which map their output to ISO 27001 sec= tions A.7.1.1 =E2=80=9CInventory of Assets=E2=80=9D, A.7.1.2 =E2=80=9COwners= hip of Assets=E2=80=9D, and A.7.1.3 =E2=80=9CAcceptable use of assets=E2=80=9D= will be of great appeal to international business organizations. >=20 > Note also that, in general, asset management is not only a security issue,= but a good business practice issue as well. Thus, the strategic objectives= of security and business =E2=80=9Cget married =E2=80=9Cat this point. >=20 > =20 >=20 > David Oliva --Apple-Mail-57768D2B-DBB0-4DD7-9D86-EAF844779790 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
David,

Doesn't Verizon already use a CIM-based CMDB for asset management, ITS= M and Helpdesk functions - at least in some parts of the business? Can you e= laborate on the benefits of introducing another standard?

Regards,
David Solin

Sent from my iPhone
<= br>On Aug 9, 2012, at 6:55 AM, da= vid.oliva@verizon.net wrote:

Luis and all:

The new SCAP 1.2 (SACM) is adding two specification= s (or formats for those who have a bad taste of the term specification) asso= ciated with assets.  These spe= cs are the Asset Identification (AI) and Asset Reporting Format (ARF).  The three specifications which dev= elopers should use for this purpose should be AI, ARF, and CPE (Common Platf= orms Enumeration).

SACM Asset M= anagement applications which map their output to ISO 27001 sections A.7.1.1 =E2= =80=9CInventory of Assets=E2=80=9D, A.7.1.2 =E2=80=9COwnership of Assets=E2=80= =9D, and A.7.1.3 =E2=80=9CAcceptable use of assets=E2=80=9D will be of great= appeal to international business organizations.

Note also that, in general, asset management is not only a= security issue, but a good business practice issue as well.  Thus, the strategic objectives of security a= nd business =E2=80=9Cget married =E2=80=9Cat this point.

 

David Oli= va

= --Apple-Mail-57768D2B-DBB0-4DD7-9D86-EAF844779790-- From jhowie@cloudsecurityalliance.org Tue Aug 14 21:39:26 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 9755C21E80F1 for ; Tue, 14 Aug 2012 21:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBida32N8jEK for ; Tue, 14 Aug 2012 21:39:15 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4501A21E8086 for ; Tue, 14 Aug 2012 21:39:12 -0700 (PDT) Received: by ggnh4 with SMTP id h4so1481890ggn.31 for ; Tue, 14 Aug 2012 21:39:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:x-gm-message-state; bh=JvBnGMmRBlPNPO8BF0ZJfI7s/nP7Fa1TI8pgKmcbW2w=; b=KxCz6xX8+yBoDpNvRvVIDdzE/leQchBGmPKiKUD1098/M83YYKOzZBQAvJeZAQrkvh a0TEjJyqjnLI1zIzqdSGcNthyhw4FyCQ03nh55oGCZcoXh6xsu8zGU8y1VAheeQzLYqC SNA5Wns/fluDn8BbbMOsdLDo1/nYM5SMsxW1xDZPclRo3Vsg9BpcUFBnE4UDs1XuV+iy 3oZxHjVW7/CcoX9sEU1YqpS8CCQlhZvZZozOJNRiWYELptScc7i3X13fOxCTzlJWLppY 0MpM0jqUmLMqTgiCGhmH15vs4FfoTqOIO4irQATpppdWKO4uPh0ot8w4VODDuvtaOOV5 MXFg== Received: by 10.50.213.39 with SMTP id np7mr16044261igc.51.1345005550552; Tue, 14 Aug 2012 21:39:10 -0700 (PDT) Received: from [192.168.1.41] (c-67-170-52-163.hsd1.wa.comcast.net. [67.170.52.163]) by mx.google.com with ESMTPS id gx1sm1016665igb.16.2012.08.14.21.39.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Aug 2012 21:39:09 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Tue, 14 Aug 2012 21:39:04 -0700 From: John Howie To: Luis Nunez , "Waltermire, David A." Message-ID: Thread-Topic: [mile] [sacm] Strategic alignment of security with business in SACM in an international context In-Reply-To: Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3427825151_10020701" X-Gm-Message-State: ALoCoQmA0SKEPBChOugAf4xvgcn2KxF+zuYWncfbpW5SVLzn2EFc7gURvnf3vbDGdLx/2Obzi1sY X-Mailman-Approved-At: Fri, 17 Aug 2012 08:01:06 -0700 Cc: Ruben Oliva , mile@ietf.org, sacm@ietf.org, Becky Swain Subject: Re: [sacm] [mile] Strategic alignment of security with business in SACM in an international context X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 15 Aug 2012 04:39:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3427825151_10020701 Content-type: multipart/alternative; boundary="B_3427825152_10010932" --B_3427825152_10010932 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi all, The Cloud Security Alliance intellectual property, including the Cloud Controls Matrix, can be used royalty free with attribution, should you wish to use it. We are making some updates to the Cloud Controls Matrix, and I have Cc'ed Becky Swain who can answer any questions you might have about th= e updates. Regards, John From: Luis Nunez Date: Wednesday, August 8, 2012 9:50 AM To: "Waltermire, David A." Cc: Ruben Oliva , , Subject: Re: [mile] [sacm] Strategic alignment of security with business i= n SACM in an international context I had mention the Cloud Security Matrix (Cloud Security Alliance) in anothe= r thread. 1. is this something we can use as basis for mapping the various regulation= s to a common id? 2. Is this SACM or MILE GRC related work? thanks. -ln On Aug 8, 2012, at 12:37 PM, Waltermire, David A. wrote: > The challenge we will likely face in scoping down the effort is that we m= ight > not be able to work on the full stack that supports low-level data collec= tion, > as well as higher level security processes and controls. This is because= we > will likely need to charter around a lower layer of function. This is wh= y we > need to scope as part of this work an architecture document that illustra= tes > how the smaller scope of work fits into the larger picture that supports > alignment with international compliance models. > =20 > To say it a different way, we need to define a comprehensive picture of t= he > =B3end state=B2, even though we may only get part way there based on an initi= al > SACM charter. > =20 > We can use documents like ISO 27001 as guidance in producing the architec= ture > document to insure that the end state aligns well with your concerns belo= w. > =20 > Sincerely, > Dave > =20 > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > david.oliva@verizon.net > Sent: Wednesday, August 08, 2012 10:22 AM > To: lnunez@c3isecurity.com; sacm@ietf.org > Subject: [sacm] Strategic alignment of security with business in SACM in = an > international context > =20 > =20 > Luis and all: > Unless we can demonstrate that the technologies and specifications we are > developing align with the security objectives of international compliance > models (such as ISO 27001) we cannot demonstrate strategic alignment of > business and security objectives in their context. > Strategic alignment of security objectives with business objectives can b= e at > least partially joined via SACM thru the SP 800-53 to ISO 27001 mapping t= able. > If this were to happen to SACM then the validated products will have less > appeal and less marketability. The validated products will work fine, but= they > will work with limited capability and scope. For example, currently vali= dated > SCAP 1.0 products do not use the Open Checklist Interactive Language (OCI= L). > OCIL is an open specification (created by the security community for use = by > anybody, any developer, any country) that facilitates non-automated asses= sment > of security processes. OCIL would allow an ISO 27001 compliance assessor= in > Germany to create a question =B3Does the organization comply ISO/IEC 27001:= 2005 > para 4.2.2 e) =8CDoes the organization implement a training and awareness > programme=B9=B2 and answer =8Cyes=B9 or =8Cno=B9. Then the results can be accessed a= nd > read whether the organization uses product X or product Y because OCIL is= an > open security specification. Another example of OCIL is a rather mundane > security function of universal use. OCIL allows an ISO 27001 security > compliance officer to answer =8Cyes=B9 or =8Cno=B9 to the question =B3Is the door s= hut?=B2 > and make the result electronically readable whether he/she uses product X= or > product Y. As for business, the flexibility of OCIL allows a company to > create a question =B3Did the company reach our 7% profit strategic objectiv= e > over the past 10 years?=B2 and able to answer it =8Cyes=B9 or =8Cno=B9 with product= X, > Y, or Z and ensure interoperability. > =20 > David Oliva > =20 >=20 > =20 > =20 > On 08/07/12, Luis Nunez wrote: > =20 > Thanks the comment. I am glad someone agrees with me :) > =20 > -ln > =20 > On Aug 7, 2012, at 11:46 AM, david.oliva@verizon.net wrote: >=20 >=20 > Luis and all: > =20 > You are on target. > SACM is not a law enforcement thing, but is a facilitator of legal issues= in > association with the protection of private information and health-related > information. > I think a couple of examples to show how SACM facilitates legal issues ab= out > personal information is in order. > A SACM configuration scanner is able to monitor the configuration of secu= rity > controls as specified in ISO/IEC 27001:2005. This can be accomplished wh= en > tier IV SCAP content is used because the output maps the finding (complia= nce > or non-compliance) of the scanner to security control ISO/IEC 27001:2005 > paragraph A.10.6.2 =B3Security of Network Services=B2. Thus a SACM scanner i= s > able to assist in international governance compliance about personal > information because SP 800-53 maps to ISO 27001. > A SACM vulnerability scanner is able to meet compliance with ISO 27001, p= ara > A.12.6.1 =B3Control of technical vulnerabilities=B2 because a SACM scanner us= ing > SCAP tier IV content can map its output to the ISO governance. SACM > Vulnerability scanning can address aspects of confidentiality of personal > information by identifying software vulnerabilities of the databases that > house them, and do it in the context of an international set of security > standards. >=20 > =20 > David Oliva > =20 > =20 > =20 > On 08/06/12, Luis Nunez wrote: > =20 > Looking at it another way I could see security automation as a way to dis= cover > if a system is configured to meet privacy policies . > =20 > Security automation is an enabler for transparency so that individuals a= nd > organizations may understand the complex computing environment. > =20 > Thanks for bring up this issue. As a community we may want to look at > building content around privacy controls. > =20 > -ln > =20 > On Aug 6, 2012, at 12:42 PM, wrote: >=20 >=20 > None of the efforts we are talking about for SACM are targeted toward PII= or > individuals. They are targeted at the configuration of the platforms depl= oyed > in the enterprise to assure they comply with the site's security policy. = PII > is not collected. This is not monitoring of individual or employee action= s. I > am not a lawyer and will not speak as one. We will let the lawyer's decid= e at > the appropriate time. > =20 > Kent Landfield >=20 > McAfee | An Intel Company > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > Web: www.mcafee.com > =20 > From: Martin Rex > Reply-To: "mrex@sap.com" > Date: Monday, August 6, 2012 11:32 AM > To: "tony@yaanatech.com" > Cc: "mrex@sap.com" , "sacm@ietf.org" > Subject: Re: [sacm] Legal aspects of System monitoring > =20 >> Tony Rutkowski wrote: >>> Martin Rex wrote: >>>> =20 >>>> In Germany, an employer monitoring a company-owned PC that an employee= uses >>>> for communication (EMail, VoiP, IM) would be unconditionally illegal. >>> =20 >>> Really? >> =20 >> No kidding! >> =20 >> =20 >>> =20 >>> That is not consistent with comments >>> I've seen concerning German law. >> =20 >> There is a significant amount of mis-information floating the internet. >> And a mindboggling large number of lawyers are making wild guesses, rath= er >> that doing research. >> =20 >> The decisions of the german federal constitional court (GFCC) have been >> quite consistent over the past decade about what with respect to >> encroaching on the general right of personality, informational >> self-determination, freedom of conduct and created a "fundamental right >> to the guarantee of the integrity and confidentiality of information >> technology systems". The court has set the minimum requirements that >> are prerequisite to such encroachment, such as the prerequisite of a >> clear formal statute law, which needs to be limited to situation where >> real facts create probable cause. >> =20 >> The original GFCC decision in german language is quite comprehensible >> (to me, at least), while I'm having some difficulties understanding >> the english translation (and the english translation is shorter!?). >> =20 >> BVerfG-Entscheidung "1 BvR 370/07 vom 27.2.2008" Randnummer 196- >> http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007.html#abs196 >> =20 >> english translation of "1 BvR 370/07 vom 27.2.2008" >> http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007en.html#abs130 >> =20 >> =20 >>> To be *unconditionally* illegal, would >>> preclude almost any rationally required >>> maintenance or threat mitigation. >> =20 >> It is possible to perform maintenance and threat mitigation entirely >> without "monitoring" systems. >> =20 >> A mere threat is insufficient for monitoring, if that involves collectin= g >> PII data, i.e. data from which a persons conduct can be infered. >> =20 >> =20 >>> =20 >>> It is fair to observe that recent German >>> Constitutional Court decisions impose >>> constraints, but they certainly are >>> not "unconditional." >> =20 >> One of the prerequisite is a clear formal statute law, >> which currently does not exist for the purposes "sacm" is about. >> =20 >> quoting from the above GFCC decision: >> =20 >> 2. The fundamental right to the guarantee of the confidentiality and >> integrity of information technology systems is not unrestricted. >> Encroachments may be justified both for preventive purposes, and for >> criminal prosecution. The individual must only accept such restrictio= ns >> of his or her right which are based on a statutory foundation that >> is constitutional. >> =20 >> =20 >> This currently makes collecting data about peoples conduct "unconditiona= lly" >> illegal for most practical purposes (exempting from prosecution only >> individual occasions of justified self-defence against an imminent >> vicious attack based on real facts that create probable cause). >> =20 >> This applies to all surveillance that impairs persons "freedom of conduc= t". >> The majority of past decisions of specific events was about surveillance >> with a camera, but the GFCC decision makes it crystal clear that >> this applies to *any* kind of surveillance. Different to monitoring of >> computer systems, there is statutory law for camera surveillance, >> that allows optical surveillance under certain conditions >> (Art. 6b BDSG "BundesDatenSchutzGesetz). >> =20 >> The lack of a formal statutory foundation makes surveillance illegal >> and entitles subjects to "cease and desist" rulings and sometimes >> damages. >> =20 >> In one more recent (and constitutionally correct) rulings, an employer >> had put up a camera that had in view not only the entrance door, but >> also two workplaces. The employees protested against this camera, >> but the employer would not "fix" it, so at least one employee sued, >> The court confirmed that this camera surveillance at the workplace >> was illegal due to its chilling effect alone, and since it had been >> installed for a whole year, the employee was arwarded 4 month of income >> as damages (for the chilling effect). >> =20 >> Another recent decision was about evidence from a covert video >> surveillance showing an employee taking a package of cigarettes >> on two occasions, where the German Federal Labour Court >> (the supreme court for labor related issues) remanded the decision >> to the trial court because it had failed to establish whether the >> covert video surveillance really met all constitutional prerequisites >> otherwise the video surveillance would have been illegal and not >> be admissible as evidence in court. >> (German decision: http://lexetius.com/2012,2351) >> =20 >> The German Federal Constitional Court neutered numerous laws during the >> last decade due to lack of clarity and/or overbroad encroachment of >> the personal right of self-determination and the right to confidentialit= y >> of telecommunications. >> =20 >> See also the GFCC decision about the scanning of license plates >> (the decision 1 BvR 2074/05 vom 11.3.2008 in german) >> http://www.bverfg.de/entscheidungen/rs20080311_1bvr2-07405.html >> =20 >> where it confirmed that data collection requires formal statue law, >> and that the law in question wasn't limited to probable cause and >> therefore unconstitutional. >> =20 >> =20 >> The only currently existing formal statue law in Germany, that could be >> used in some limited fashion for "Monitoring" is Art.100 TKG, >> http://www.gesetze-im-internet.de/tkg_2004/__100.html >> but that statue is clearly limited in purpose, it will not allow that da= ta >> to be used for automatic surveillance of "employee conduct" with respect >> to "company-defined policies". Employers try hard to avoid TKG for thei= r >> networks (for which they will have to formally register), but that also >> means that they do not have a formal statutory law for performing any >> kind of surveillance/monitoring as described in Art. 100 TKG for systems >> that are used by employees for telecommunications and a significant part >> of their daily activies. >> =20 >> =20 >> -Martin >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> =20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > =20 > =20 >=20 >=20 > _______________________________________________ > 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 --B_3427825152_10010932 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi all,
=
The Cloud Security Alliance intellectual property, including = the Cloud Controls Matrix, can be used royalty free with attribution, should= you wish to use it. We are making some updates to the Cloud Controls Matrix= , and I have Cc'ed Becky Swain who can answer any questions you might have a= bout the updates.

Regards,

John

From: = Luis Nunez <lnunez@c3isec= urity.com>
Date: Wednesday,= August 8, 2012 9:50 AM
To: "Walte= rmire, David A." <david.walter= mire@nist.gov>
Cc: Ruben Ol= iva <david.oliva@verizon.net= >, <mile@ietf.org>, <sacm@ietf.org>
Subject: Re: [mile] [sacm] Strategic alignment of security with b= usiness in SACM in an international context

I had mention the Cloud Se= curity Matrix (Cloud Security Alliance) in another thread.
1. is this so= mething we can use as basis for mapping the various regulations to a common = id?
2. Is this SACM or MILE GRC related work?

=
thanks.
-ln

On Aug 8, 2012, at 12:37 = PM, Waltermire, David A. wrote:

<= blockquote type=3D"cite">
The challenge we will likely face in scoping down the eff= ort is that we might not be able to work on the full stack that supports low= -level data collection, as well as higher level security processes and contr= ols.  This is because we will likely need to charter around a lower lay= er of function.  This is why we need to scope as part of this work an a= rchitecture document that illustrates how the smaller scope of work fits int= o the larger picture that supports alignment with international compliance m= odels.
 
To say it a different way, we need to define a comprehensive picture= of the “end state”, even though we may only get part way there = based on an initial SACM charter.
&n= bsp;
We can use documents like ISO 27001 as gu= idance in producing the architecture document to insure that the end state a= ligns well with your concerns below.
 
Sincerely,<= /o:p>
Dave
 
From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of davi= d.oliva@verizon.net
Sent:&= nbsp;Wednesday, August 08, 2012 10:22 AM
To: ln= unez@c3isecurity.com; sacm@ietf.orgSubject: [sacm] Str= ategic alignment of security with business in SACM in an international conte= xt
 
 

Luis and all:

Unless we can demonstrate tha= t the technologies and specifications we are developing align with the secur= ity objectives of international compliance models (such as ISO 27001) we can= not demonstrate strategic alignment of business and security objectives in t= heir context. 

Strategic alignment of security objecti= ves with business objectives can be at least partially joined via SACM thru = the SP 800-53 to ISO 27001 mapping table.  If this were to happen to SA= CM then the validated products will have less appeal and less marketability.= The validated products will work fine, but they will work with limited capa= bility and scope.  For example, currently validated SCAP 1.0 products d= o not use the Open Checklist Interactive Language (OCIL).   OCIL i= s an open specification (created by the security community for use by anybod= y, any developer, any country) that facilitates non-automated assessment of = security processes.  OCIL would allow an ISO 27001 compliance assessor = in Germany to create a question “Does the organization comply ISO/IEC = 27001:2005 para 4.2.2 e) ‘Does the organization implement a training a= nd awareness programme’” and answer ‘yes’ or ‘= no’.  Then the results can be accessed and read whether the organ= ization uses product X or product Y because OCIL is an open security specifi= cation.  Another example of OCIL is a rather mundane security function = of universal use.  OCIL allows an ISO 27001 security compliance officer= to answer ‘yes’ or ‘no’ to the question “Is t= he door shut?” and make the result electronically readable whether he/= she uses product X or product Y.  As for business, the flexibility of O= CIL allows a company to create a question “Did the company reach our 7= % profit strategic objective over the past 10 years?” and able to answ= er it ‘yes’ or ‘no’ with product X, Y, or Z and ensu= re interoperability.

 

David Oliva

 

 
=  
On 08/07/12, Luis Nunez<= lnunez@c3isecurity.com> wrote:
 <= /o:p>
Thanks the comment.  I am glad someone agree= s with me :)
 
<= div>
 
<= span style=3D"font-size: 9pt; font-family: Arial, sans-serif; color: black; ">= On Aug 7, 2012, at 11:46 AM, david.oliva@verizon.net wrote:


 Luis and all:
 
You are on target.

SACM is not a law enforcement thing, but is a facilitator = of legal issues in association with the protection of private information an= d health-related information.=

I think a couple of examples to show how SACM facilitates legal issue= s about personal information is in order.

A SACM configuration scanner is able to monitor the confi= guration of security controls as specified in ISO/IEC 27001:2005.  This= can be accomplished when tier IV SCAP content is used because the output ma= ps the finding (compliance or non-compliance) of the scanner to security con= trol ISO/IEC 27001:2005 paragraph A.10.6.2 “Security of Network Servic= es”.  Thus a SACM scanner is able to assist in international gove= rnance compliance about personal information because SP 800-53 maps to ISO 2= 7001.

A SACM vulnerabil= ity scanner is able to meet compliance with ISO 27001, para A.12.6.1 “= Control of technical vulnerabilities” because a SACM scanner using SCA= P tier IV content can map its output to the ISO governance.  SACM Vulne= rability scanning can address aspects of confidentiality of personal informa= tion by identifying software vulnerabilities of the databases that house the= m, and do it in the context of an international set of security standards.

 =
David Oliva
 
 
 
On 08/06/12, Luis Nunez<lnunez@c3isecurity.com> wrote:
 = ;
Looking at it another way I could see secu= rity automation as a way to discover if a system is configured to meet priva= cy policies .  
 
Security automation is an enabler for transparency  so that i= ndividuals and organizations may understand the complex computing environmen= t.
 
=
=  
-ln
<= span style=3D"font-size: 9pt; font-family: Arial, sans-serif; color: black; ">=  
On Aug 6, 2012, at 12:42 PM, <Kent_Landfield@McAfee.com> wrote:


None of the efforts we are talking about for SACM are = targeted toward PII or individuals. They are targeted at the configuration o= f the platforms deployed in the enterprise to assure they comply with the si= te's security policy.  PII is not collected. This is not monitoring of = individual or employee actions.  I am not a lawyer and will not speak a= s one. We will let the lawyer's decide at the appropriate time.
 
Kent LandfieldMcAfee | A= n Intel Company
Direct: +1= .972.963.7096 
Mobile: +1.817.= 637.8026
We= b: 
From: <= /span>Martin Rex <mrex@sap.com>=
Reply-To: "mrex@sap.com" <mrex@sap.com>=
Date: Monday, Aug= ust 6, 2012 11:32 AM
To: "tony@yaanatech.com" <tony@yaanatech.com>
Cc: "mrex@sap.com" <mrex@sap.com>, "sacm@ietf.org" &= lt;sacm@ietf.org>
Subject: Re: [sacm] Legal aspects of System moni= toring
&nbs= p;
Tony Rutkowski wrote:
Martin Rex wrote:
 
<= div>
In Germany, an employer monitoring a company-o= wned PC that an employee uses
for communication (EMail, VoiP, IM) would be unconditionally i= llegal.
 
Real= ly?
 
No kiddi= ng!
 <= /o:p>
 
 =
That is not consistent wit= h comments
I've = seen concerning German law.
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bott= om: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "> 
There is a significant amount of mis-information floating th= e internet.
And = a mindboggling large number of lawyers are making wild guesses, rather<= /o:p>
that doing research.<= o:p>
 
The decisions of the germ= an federal constitional court (GFCC) have been
=
quite consistent over the past decade about w= hat with respect to
encroaching on the general right of personality, informational
self-determination, freed= om of conduct and created a "fundamental right
=
to the guarantee of the integrity and confide= ntiality of information
technology systems".  The court has set the minimum requir= ements that
are = prerequisite to such encroachment, such as the prerequisite of a<= /span>
clear formal statute law, w= hich needs to be limited to situation where
<= span style=3D"color: black; ">real facts create probable cause.
 
=
The original GFCC decision in german la= nguage is quite comprehensible
(to me, at least), while I'm having some difficulties underst= anding
the engli= sh translation (and the english translation is shorter!?).=
 
BVerfG-Entscheidung "1 BvR 370/07 vom 27.2= .2008" Randnummer 196-
 =
english translation of "1 = BvR 370/07 vom 27.2.2008"
 = ;
 
To be *uncondit= ionally* illegal, would
preclude almost any rationally required
maintenance or threat mitigation.=
 
It is possible to perf= orm maintenance and threat mitigation entirely
=
without "monitoring" systems.
 
<= /div>
A mere threat is insufficient for monito= ring, if that involves collecting
PII data, i.e. data from which a persons conduct can be in= fered.
&nbs= p;
 <= /span>
 
It is fair to observe t= hat recent German
constraints, but they certainly are
not "unconditional."<= /span>
 
One of the prerequisite= is a clear formal statute law,
which currently does not exist for the purposes "sacm" is ab= out.
 =
quoting from the abo= ve GFCC decision:
 &= nbsp;2. The fundamental right to the guarantee of the confidentiality and
  integr= ity of information technology systems is not unrestricted.=
  Encroachments may be = justified both for preventive purposes, and for
  criminal prosecution.  = ;The individual must only accept such restrictions
  of his or her right which are= based on a statutory foundation that
  is constitutional.
=
 
<= span style=3D"color: black; "> 
This currently makes collecting data about peoples conduc= t "unconditionally"
illegal for most practical purposes (exempting from prosecution only
individual occasion= s of justified self-defence against an imminent
vicious attack based on real facts that crea= te probable cause).
 
This = applies to all surveillance that impairs persons "freedom of conduct".<= /o:p>
The majority of past = decisions of specific events was about surveillance
<= /div>
with a camera, but the GFCC decision mak= es it crystal clear that
this applies to *any* kind of surveillance.  Different to= monitoring of
c= omputer systems, there is statutory law for camera surveillance,<= /span>
that allows optical surveil= lance under certain conditions
(Art. 6b BDSG "BundesDatenSchutzGesetz).
 
=
The lack of a formal statutory foundation mak= es surveillance illegal
and entitles subjects to "cease and desist" rulings and sometimes
damages.
 <= /div>
In one more recent (and constituti= onally correct) rulings, an employer
had put up a camera that had in view not only the entra= nce door, but
al= so two workplaces.  The employees protested against this camera,
but the employer = would not "fix" it, so at least one employee sued,
The court confirmed that this camera surv= eillance at the workplace
was illegal due to its chilling effect alone, and since it had bee= n
installed for = a whole year, the employee was arwarded 4 month of income<= /div>
as damages (for the chilling effec= t).
 <= /o:p>
Another recent decisi= on was about evidence from a covert video
=
surveillance showing an employee taking a package = of cigarettes
on= two occasions, where the German Federal Labour Court
(the supreme court for labor related i= ssues) remanded the decision
to the trial court because it had failed to establish whether t= he
covert video = surveillance really met all constitutional prerequisites
be admissible as evidence in court.
 
The German F= ederal Constitional Court neutered numerous laws during the
last decade due to lack of clari= ty and/or overbroad encroachment of
the personal right of self-determination and the right t= o confidentiality
 
= See also the GFCC decision about the scanning of license plates
(the decision 1 BvR 2074/05 = vom 11.3.2008 in german)
 
where it confirmed that data collect= ion requires formal statue law,
and that the law in question wasn't limited to probable caus= e and
therefore = unconstitutional.
&n= bsp;
The only current= ly existing formal statue law in Germany, that could be
used in some limited fashion for "Mo= nitoring" is Art.100 TKG,
but that statue is clearly limited= in purpose, it will not allow that data
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bott= om: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">to be used for automatic surveillance of "employee = conduct" with respect
to "company-defined policies".  Employers try hard to avoid = TKG for their
ne= tworks (for which they will have to formally register), but that also
means that they do not= have a formal statutory law for performing any
kind of surveillance/monitoring as described= in Art. 100 TKG for systems
that are used by employees for telecommunications and a signifi= cant part
of the= ir daily activies.
&= nbsp;
-Martin
_______________________= ________________________
sacm mailing list
_______________________________________________
sacm= mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm
 
 <= /o:p>

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


_______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/m= ailman/listinfo/mile --B_3427825152_10010932-- --B_3427825151_10020701 Content-type: image/png; name="JHOWIE Email Signature[98].png" Content-ID: Content-disposition: inline; filename="JHOWIE Email Signature[98].png" Content-transfer-encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAYsAAABkCAYAAAB3hRxoAAAgAElEQVR4nOy9eZRc1X3v+9ln qLl6VHdL3ZonS0JqgQSWcAy4hYPBxDSxceLY4sZcYsnPLwvBfQlEedda6wnHPJGbGLEcB5Tn gGOBE4MdRGyLYCNhsEECWkC30ICm1tAautVTzVXnnL3fH+fU0FJLaiTAvvH5shpVnbOns6tq //Zv+m6hlFL48OHDhw8f54H2mx6ADx8+fPj47YcvLHz48OHDxwXhCwsfPnz48HFB+MLChw8f PnxcEL6w8OHDhw8fF4QvLHz48OHDxwXhCwsfPnz48HFB+MLChw8fPnxcEL6w8OHDhw8fF4Qv LHz48OHDxwXhCwsfPnz48HFB+MLChw8fPnxcEL6w8OHDhw8fF4QvLHz4uET0dW3huR3Hf9PD 8OHjA4UvLMYKpQCXzb3E6V7xovJOqaRy66ni34jmVKmQQpUquWUr6xebUaULisq2itfKZUbe k6Xy3nDwOenHhtyBJxHLHiV5gXJHN1/PTT89etH9JLseHdlProvbheDRrnLPh19+nFuFQHh/ t9//NH02QI6nVwqWPbyjVLZv+4MIcTtdueKVQR5dJnhwxyDkdnCruJUdSbfus3+9rNSmEIJb K9rx4aMSvrAYK4QAhPuydK38ovJOqaRw65V+jCOaE6VCAlGq5JatrF9sRpQuCCrbKl4rlxl5 TyuV94YzYhw+zg1r+DRszV+4YKiN1uoIALZ9MR3lYWueUlXLogfIW+6V3J7HmXrtHUx77CV6 Bwbo7txEcs3naVyzBQhxxe+vYOuqXzDoVd/z/BPARl7Z5QmbwZ18ZyvMGR8HIEECy+2I7p9u ZfWmTnp7euju7uY7t8+7iAfw8bsAX1iMEaWdu/dX1h689yWtQOLu5mVZe6jUFoqtKQnlVlAo ZEUfSkkUDihZoUvIct8KlPTKKbe220JFFxXjRfoqxXuGWfnGZseTf10W/LfeT3Hjbwar6Hzm 29y+UGCagpWPbvcW/hxPrryd+x8u1lvGk12DZ3WDCbQGCRffh02qSjdz/ORbd8Dyp/jbL19D Q20tUxbcwj+9tBYeeJgdOZjysZuBJ9g5CHCcV5/uBGDzr/YB0LfzRTpZy9XNxqiPOX7aXBqa m5kyZQrNtaGLnCwf/9XhC4sxQqiicqFQJUVAgZAglLdjL+/5hSqVACFQMoed7UcWUp5Jq9Jo JUvvytqEhvvxiDP+ACQChRCq4o7G2TqDJ2SEAk2glIPMp3DyKU+o+Rgrcns2svhLD/DItm6y A7tZe2gNrWueLWsDWzdw/YZuul9az4avrqYjCWCR3LeRNd8N09nbw+a1/Xxp1Q9HMWsFofOr fGXlSlauXMnKO1axqXTPon8bLL9pPpVLfcOcq4AElgVG85WsppPNOwdhsJP7Ou9m86a1bFr1 C5LAns1raF13Aw2jPFdwGqz6+h3cs3Ilt99+P3tyoxTy4QMYfavh42wIUGctxgKlNEAhhDzD l6FQCIRQ2OkBskd2YKdOEJ64iGDTXISml4WG8IQRRYlU6XkQRZHjFhdlQ1PleATSva5ACVVR U7kdIMkNHCHX/QqB6mbCUz6KCETf50n6r4t9v/wXWP4Udy6ZggHcvWEta5Z2k/wWkE/Quq6D Ly+ZAnYbbTxTqpfvh3WP3c2Chjizbr0T1pzLrNXOTX/4h8QKQOp1NmzceoERBSpeN3PT2lau fXEnf85L0N7GJ29oopUV7OpbzqsPwJ2d5zAvJWD5re18Zn6MQiFKvb8i+DgH/K/Ge4QqL8Fl D4W3wAtRLuWWVCg7R+bEOwy//ROMSDWRqVeXy5faO9OR4GkDpYve4i+EKyBKQqNsWXIvuf93 /R3F164wk+kBMvtfJb3vl1TNvZ6wf/T6BWECtLqvrXw/jKsr/2DMIOBuw63KSvaId8WLZ5er hJWH1pv47I03EgKwW2j/0prS7eA02Lizj+8zp3TteMd/AC1EPFPZ5TffCYs3snHFNpb/0Z0Y oUbubO3kn3+wkW0sZ+Os+Khd5/vhqrY/YNkC3/zk4/zwzVBjRaWVqKQ5eA5j5SCtLDKfQhbS SMfylAaBchxkuh+ZT6NFWtDCdWUXtBCgHKSVxsmnkIUMSjrFXkodK+kgpeubEEjX9KUUSkqU U0A6ljc+gSxqQNJBFjLIfAolJVZmkHzvTjSzBqN2IsLw9wnnhD3IngPH6e45CZ3uUj9+/s3w 0D08e2AQO3eAx/7iPri7ldGX4DKCY+nPBDrzZWFiWyRKN+PcfNdaeOBaHt6yh2QuR9+e5/ja TQ/Ruu7PKa7x8XltLGcD923opP33WoA4H/9aOxtW3UfninbmnkcWnOzrITk4SF9fH4PJi/HQ +/hdgL9ijBGquKEvbeVdX4O0C1jDPeR792ClBzHC1QTrZxOom4QIRlG2hZPsRWX6MOITMGP1 XjsKaWUoDB6l0L8POz2IEa0n1DQfo6YZTTcAhSyksBInQGiY8fGIQNQzb4HKJykMHEaYEcza SQg96CotToFc7wHyJ97BsZOYDbNRjoVMnUQLTMSIjEMI81yP6sM+xt/MbGUjsOKJTmqB2mWr 2bR6F+0z69wy7evYvfZGDM7wg18MLEoajIuig9v9eTYs+0teemyAa6+fyyqvRPvaTbx475Jy ldAs2lfAxg2ruaLFlQzzrrsV2MTqP/zYOX7oJs1LW1l1/Uwe8K60retgy72LLvWJfPwXhFDK t0eMDaqU84BwF/vC0FGGd20hs287zvBBpJ1GGHHMmulEZ19NdesfIIDB1x4nuec/qV56F3VX fBpQWEPHGOzcTPrd7cjMcYSdRJi1BJoWEG/9JLFpH0WYYXKn9jLc+TNQDtULbybcNBel6Qgl yRw/wOAr/4BZN5naJbdjxsZRGOpheOcLpN99CWe4GyXT6NEpGKEacr2vEZv1ecYt+wpmdQNQ aeryMQK2Tc6GUGjkMmvncmSBeOg3YbaxySWzEI4T8rd5Pj5k+F+5MUN4QgKQNoWhYyR2/pz0 /hcJNc0levWfQjCOPXiY/Im3MCIxNNNE5vLYhTwoByMUBCUpDBxm8K2fkO95i3DzbKIz/gx0 k2zPLpJdG1BvZzDrZhKsb6AweIRC734CjbPQAhE3bwOQTg5r8AjWcB96/WSE0JCZYYbf/Amp d7cQmryE6Me/gjCjWKd2kd61GRwLEY8gDLP8TD5Gh2GMuiAbodAFTU8fHAxC8d9c7z5+t+EL i/cKAbKQI9v9Fsl3niM0cSE1H/0CoYZpgI5snoY9dT5aIIpmhsgPn8LJFDCrJ6NHa5BWjvTh HWT3/5LQpCuo++gfEaifDGgE6xqw+3dRGOzHGT6KjMVw0qdRsoBZMxEzXAfCdVgrK4OTHcAI VROINaIJRebULtIHthJsmEn1wk8RHv8RhGbgTJiEVIpCehd6QHcjsXz48OHjPcAXFmOCKsU/ CelgDR0n09MFukbkI9cQHOcKCiUVmhklUOuGpCpp4WSHUXYGPdaEbgYpDPeQPfI2IlRLbM4n CYyb7IbfCoERriHUfBkyuwPHSiLtLDLVj8rlMEL1EIziZdshc2kKQ0dAD2JWTcCRisyxnShL Ept1LeGmWSBMlAJhmGhmCM1sQAtXIzRfo/Dhw8d7gx8NNSaUaTaknSc/eBgnccJ1ZFdPQAhv GoWbpFdMeFPSQWaGoJBChMahBcM4ydNYQ/vQI9UE6l0hUwqzVRLlWCjlRaRIBzszjMJGC4cQ opybYWeTOAP7EYE4es1khNCxB0+jaQIjNg6hB72oXoWTGcIaOoJujiMQbgBfs/Dhw8d7hC8s xgg3Ixt3sS5kkXYGLRhFD0VLOdjufSj6ApRjYSWOYudOERg3GyPWgLQsZC6LbgTRzZhbQTmg wMmlyZ980zU7VU1C6BGcTBJhCIRulLpHgbRt7MS7aLqGGR0HwkBZFiIQROnCo/rwQmydLE7m FFqwGi3WhND9SCgfPny8N/jCYqwQFYl4RgAhAjjpBE4mgVCuZiCUQjoFKGkGCgoJVH4YLVCD ZkRBF2iBMMrK4uQHQSmEZqDsNLnBI1jJQ+ixKEasHqWZ4BRQjgOa5obFagIlHZxEL042hzAC Jc1GCXAsq5z/IQQoiZ1MIQcPgRFBj9b6PotLxPkoye1cjgtnKuTo2vI0jz/5HId/q+k1bJLJ D2+Agwe28+Tjj/PygcGz39s5cn4KyG8UvrAYK7xEC2GYGLFG9HCcfH8nmWNvUhg6ijN8kszJ vaQPvEHm1D6cfBqURGYyKGWhmUEQAi0Uw4iNozB4lMyh7RSGjmInTpHs3kGq6yegNRKeshQ9 FAUlEZoEK4s9eJzC0HGcxEkyR3eQ2r8Np2AholGE5uZdaEJgZ5PYp49SGOqhMHyCbO8hMt1v kzv1DiIQQgtV4UdBjRGDXTx4+8IyffdfP00f56Ekz3VxQzjMA9tHIQuswOFnV9N6/f28+st/ 59f7RjJF2X07uL+iT7HsHl7+0CSKzeGuPQx6i3Jyx99TVRVm+4U42seEJM89vLKCDn0ZDz+3 p+L2dj43cyn/3wuv8uqbp856v+OBMOEbnnw/BuLjIuE7uMcIJbw8Cz1IYNwMIjM/gZUZJvHW Tykc6UAZYWRmEJRGZObvEYg3IJSBoxyMcBQt4gqLUP00orNvYvitZxl882lSh36NZgRR6UHQ glTN/wNis69FD8UhkyA46SoKw6cZfOMHpA/8EhGKoHIpCv0nMCMNBOLjELoGuklkxiIKg3sZ fO17pA++iAhEwLKxhvoRAQ09FvZozH1cGMe5v66VNW3r6OjeTH32AI/+1UYODt6GGWqjNVSm JC8lw4fm8lhnB0w9f3hronsLres28ui9C0besA+zpnExDyxfT2fP7Uw0T/HD/zmXa6dm2G09 ypwP+tea62Rq62K2JRRL4hCft5yOjls4B1PIe8L2B9u56T54qqOb62dFePc/vsXSm+ZCxwB3 Laolt++XbGUdie/fSxzI7XhwxPvk8d10frHp0gfi46LhaxZjhCifPYQRiROb/XHqlnyR4Ph5 WBmBTOUxaidTtfDTxOcuw4iNA10j1DSf8OxPE4hWAwI9XE1s1kepW/o5Qk3zkSkHJ5HHHD+X 6qtuo/qyGzBj4wDQQhGisz5OvPVmzKpp2GmJzNqYjR8hvuD3ic67kcC4maAbaEaA+Iyl1LTe QqB2LnZKIAuC0ORW4gt/n+j8LxBuWYBuBM73mD48JLv+gzW0sW3TvSya0syUOdfwzWceZUnt +SjJbV7/9l/wXHcWsNnx+D3lw4oefI4c0PXo7bSu6qTzvlbEskep1EGSuzfxAG10fOcuFjTX Utswh5XrO2hnA893DlKmPL+/1O7DWw57tUfvD3I8ec/t/PX97q7+wR2DHH/5URYWd/gLV/Jy nw0kefTTiwFYWiUQtz9Okn4eveNbdOeA3A5WLrydv77HOyzp1gc57Gkg9vEtrFxYbG8hQqys OHgJyHXx7fu2snrzRm5bNIXaeANLvriWTStg1fe3kzrwNOHF9wH3USUE3/7ZxhHvH+1K0vP8 3/D1XxwDYHDHkywrjv/2RzluA/ZhHi5pZAt5fHtfqe+VC2/lnttdbWbH+6Il/Y5CXQRk5Wvp uH8Vd+SIEsXrjlJKKke696V0lCPdklIWqzpKKa8t6SglpZIV12RF56WepPTuS6/nYpuOcqSj pJTeGCv7cirGWB5bZbvqjGcqvio/oaMcu6CcfEo5maSyM0nl5JJK2nmvPW8MhZxy8hklHaty 0pR0CsrJp5WTTbp/+bSSTqFyMsptWFnl5FJuuVxSOfmMcvJZ91+7UFHeUdLKlctmk+57K+e2 b+Xcef0QUZz/iiveNVl61PI8O6o4d+4nMnIuPkx0PtKmaH1EJUa9164A9di2btX90noFbWpb QimlEmp9K2pdx4BKdD6ioE290J1VKrtbrQC1vjOhrOyA2ry2VbF6k+oZSJzd7ll9um2u3Tag lEqoR9pQtK5WHb0DatsjyxWsUPstdc7+SnW4W720e7fqGbDU/s1PqM27e5VSA+qJ5ajWddvc nvZvUtCqNu3uUb0DWaWyHaqt+GzZDtUOqn3dC6q3t0OtALX8qf1Kqax6oh3Vtn6bsqwetb4V 1f5Ix8gJq2ynArsfa1ewXg0opfZvWq1grdrd06sS1tnvO9a3qdZ1HUpZ+9UKUCue6FCJRLd6 at161ZlQ6qW1KNofUwNKqd6ORxQsV7uz5XG3rt2kdu/frwYs5eMicVGKbdmQoUrsp2XIEoG2 QisxqxaLa8Uj4ESZervcQFnRKbKxnnVCg6is4trqpaok7S6T9ImSS1qU6VmF24+A0jGkrmXG OyQIDVV5sp1yn0CJ4pOUHd1CN+BckUUKEJrrqzgTQiCEiQiMVnckBYcQGsIIjdFgqCGMIMIY 2edv1PAkyp+98uZZCIEqfZCSkkceKH4HKqkUfxOw8kD9OW6eh5K8iH2vbAb6+cW/PcwbDLEN 2Ld1H3ctWERLdT2twYk0146071j5xLn7LHbdD+seW82ihjj86T20ffUvOJ2F4XP2Nwv6Ye22 NVwzp9Zt5MY/gu2/4PHHD/N2D9Rf5X4P4y0TaaOeiVObaQhRJNUtIUEb/+uuZTSE4M/Xt7H8 4GmgkUICZk0dh2GECdZD04TRH+Ksb3ug/Pwt08a7/zY3EAfMM94XYfe8yQba6PzsIuIhuO3e u4Akj24FWt7lnx58EPIHgE76LJhjuuPe8Je3MMcn1r0kXJwV1FvPinTZ7m+9fOqbRHiHeXoL svByFJTCsh2kAkdJHCnBK6vrCg0N3RAYmu6tFBW0VcWFHQ2QKCUQmru4I9zbAoGDwrYlUjoo BY7CDSEVAk1oaJqGoQl0TaBpFQcUKU/IlYSfGxCrhHcsqSrThislcJTEPcWuggZEuGJIKwkW vPkpEptzhs9AnSHEzrFEnknfVclcfqYP4r2U/ZDgMuUWNwKu1BDeRqP0+XmfbYlqvXQux9kb hg8Dk65og1W/otteyYIzfiUXpiQH8gngZj553XWYhQLXbbuN8bPnnV2/AtOuaINVO+iF8gKZ 3MUznXCrWTEIc5RNxjn7s8gDwVKVHM/eE6b9oRU8sfmPmdMCb5cezKLf/QfOsbCOvGcCYWKz YEP7TDYArcvX8+MbpoxScyu/2pdk0aLik9ns3LwR1q6gFs46EOpcc2RnU6Pf74flf3wtn7w8 SrpwNds67mFeGEqhaed5Jh9jw0W6zCSl3bl3qIKqWIxExQIMAsdR2I7k9HCGAz0D9PSn6BtK k0jlUBKikSDjx8WIhE2mNVUzs7meSFAvncvg/luhdSjh7vRVcSyuozGdL3BiIEX3ySFO9KdI ZwoMp/JoKHRDp64mTnXYYPy4OBMb4kyojREwNTThhqW6Y1YoobzFv2Kh8hbzXEFy7HSS/kQO Q1PeIufeC5kGDTUR6qojGFrxlLyioBht0TtLLRsd51rkR7v8Xsp+CHA3DJ7ALQqHknQtQlLW DYsVS6rIb2TsDVfdTDtraP0/r2f/N9qps47x/b/9AUvWfvO8LLPFUy4mXdEGbIXxq7lmSpy+ A3tIXODnVnv5DbSxlK/cfzMb776BuN3Dj/5qKVtZzWOL4kDSPdnuwe/xx9/5Iv0/+hZbmUV1 GOrP2Z9F+eQNgCx7HoLVL3yDLy6DRx+pGEB8PMvYyvOvH2DeVY3Ez/Og5cU6S/8+aFu9nj+b 38z4GfOpO/MxQ/P42gr4/OI1XNG9hquaYNdP/pbPb4THdl9+3jk5E6GZi2nnDr7/4y7mfXY8 L37vx7R88U4mLIWNvzrJ39/5ZRpIcmD/AGEDxhDH7GOMuChh4e62i2/wtvXFLOfyGW9SCTL5 Am/tP0XXwVP09Axz+HSGI8MZepJZjmQchIKGkM6M2hCxgMmU2jAfmVzPkvmTaJ3RRCRkIJX0 9pwuykJKYNmSntNJdh7q450Dp+jpHeLYYJajiQKDOYsjGQuEwNQFc2IhasMaE+IhJtRGmdhU xdSWOuZPa2RKUxWaplFiwhCeSUoVtSaQUnH41BCbfrWPnftPEgrouOdtu9pGLGxy5byJfObq GVTHwiipitOCKB5jKn4XYwqEt72gRK/uwt1MePsNV69SeGYqV7zKUgsfMkKL+P7uTXxtbjsz N7iXWlc8xp/E4eQYqjdcczeb1nZw/dTiadqtPLV/OzNqjXMLm/gSftT5FHe0ttNSPPuobTXb etZS3KsHE8CmrzJ141cBWP9Cjxsldc7+zuykllueWs3c6xt5AGhro+K87yl8dn07114/kzWt 6xnY/nFgpPnIPONfsMn3w9ajh7ixZpjN6z7P9ayj9+17K45xDXHb+v2sz3yWa6c+VBrf+hf2 8+U5Ywu1KvVnLODvNq1lZnsrDwG0raP7ToNb/t8O7v7EYhrNO9xyy58g8f0pJQ3NT0O9dFwk RXnZrq6UKplXRNHkIqBgSTrePcHr7xxhS+cxnj8yjJUsEDMUtbqGqemYmitkHKUo2A55pTHg OKCbtM9r4HPXzeGTV82gJhr0zFmeOPL6PD2cYfvuHl7uOMy2A7282pNAy9nUh3WimkATYHqm JonCchQFKUk5DglHYQaCLBwf52PTx/F7Cydx1WUTmdRQhfKsQ1oxEc8ThsOpApte2cv9T3XQ 3ZsAU3cT7xDoAIbGHy6Zxvo7fo/GuiqUkhVmJ+Wazn7HQldLGqb32bmTq4pZgyMLS1XeiHg2 vNE1sg8XuVwOwwhxMedFFZP0Qu+R0jyXSwLhMyjSkzy8sAo2JrhrrkmO0FnMuGPuz86Rs0OM VszO5SAUGttOMrkdUbWUzb2KGxug7+UHaby2i93Z74/qI7BzObIWhONjbP+84zfOopAffd58 vB+4xBlVpS1faXcoBAXL4ZWuo3z/hXf4lzd7ELk8s6MGxA0cpXBQSAV5hLe5VOiGRgSNeEBH oNiy6wS9qQI10TAfnT+JeNg9DEgpiVIaQ8kcP3vlXb73y/386tBpGoTDnJCBEzRxPLOPVIp8 cXQK0CGoGYRMgyYBGoqek8M8fHSA/+ju429sh/qPzyUSMsq+GE+jcST0DWbo3HeKI6dTzKsN UXDKT64DAzZYOQunIEfOUdEX8TsmKCrhrv0Ka+gIheEezOrJmDUtFLVRa/g4VqKXUNNcVDBc mndRsTH5TeG9LvSVMMa66J7V5zl23J0wnLHBiI9qgh9zf8bZgqayjTEjPpunVrdxU2P5M1q3 ufuczmQjFCL+fvgOzjH+c86bj0vGRQqLSq+p5rqclUQTGnnL4bnt+/n7TW+xrbuPOcEATjRI XkmkdBcAXZQXAYVCerZpTShs6Tqy6wMG+48M8vB/vM3/ZWpcd/kUd4OqafQPp3nihV18Z3MX hwZSzIuFyCmdnCORKNcqXvJ1eP9TrqBxlAB0bKXQkERNjVmmTrUUZCy7ZEsXosI3ImA4keHF rsNs33OSegOytsJRlMxjDgIpHVI5ixOJDPX1VQTM8pLnbbEvTWBUKoHlhxutYIXj/EL9jeZk P+P+qP2MqDRKeVXaSxS9OlbiFENvPEvq3X+kesn/Q83lt6IZJoXhPk7/6ntoFAh8YjJaMORt IkRJUz3n2Ecdw39VxFmRSMBv1ZkWtdz2zS1Ya5JkLTDjowsxH//745IM6MX1TynQhEYym+OV d3r43s93svfYILNCOnmhyEtPIChXOgWEhq4AKTGFQhe654RwF2YJWEoRDRq8dKifzn0nGM5k ERoUbMmO/af4zvO7kNkcMyMmGccVRBKBjoEhBEIqlCPBdtCVJKCBqenoAkCiCTeEM68U6VCA z189g7YrZxDxwkZK67JnNklk8nTsPcG2EwnqQob7zOVZACEJCMinCxw4MUwqn6csJMY+o2pE BVdwliyFonzNHdrIsi7brRpRt9QGckTbShXbFVT2o4pmonMOvNjKWBZoL4KttLdwQA9iVLWh h+rdNqTCGuojt/+nIEwQuhtJJ86wVKlye7/LCP2WLsZGKE78t3RsPt4fXKRmUQxpLO6rFQXH Ycee4/yPf3kNu3+YuFDkFUil0IRn2tcEJ6QiJgymTYijCcXu3gQB2yYqREnz0NxtPbYjaRAO P+86xryZ47n+iqn0DaZ45tf7OTqQZHrAICuLpjAHlCADWAGDOU0xasMBLKnoT1t0D2Sx0lmE JmjQBY5QKKlBQOeziybyubaPMLmhyl0Ki4uop52kcjad3X10dfcTcByk0JGeA7wYDqYpQVAo knmLd08MsTRjURcLl4XKeTWBkXOrUC7LbTF0VDnIfBY71YdTSIAIYMbr0UM1YATcMXh5Jcou YKVPY6cH0TSBHqnFCNWCGfRCUd1PzqVEd5D5NFayD6eQQgvFCcSaEGYEhI6y89i5ITQtiB6u KjnnFRKVSaFkBmHG0AJREAqZSyHtPJoZRBWyFFKnUcrCrGrBjNZjxhuJzrqS8IyFhMbNRNPA zvRR6N+PCDYjggZ2phdQGOEqnHwWaafRg1XumCq1M8fCyQ2DUuiRWoRmlL6XPnz4eP9xcdFQ FYGORT9FT1+S5944zKFj/UwMGwgdlBToQpR23QPo/OmiCVw1t5lx9VVoKA4fH+DFt4/y0t7T RDUNBxCiGDkE0oFXTyS47eQQSkHfYIp3Dp7CQYAGWilcxo3XX9RcTdsVE7ls1niCZgBbQjaX J5nMcPTEIK/t7+f1w0NoloUZEHxqwQS+0DaXKU0VYSMViWQSjf6hLK/s7OH1kwlmxYLkpfKM bwKQpfAsoekU8ja9w1ks2y49Q9lqdyEzVMU2uhhm6hTI9nWTO76b/Ml3cVLHEcEYgZpJhJoX Ep58GVowhlASa/gEuRP7yfa8g5U4jDACmPFJhFvmEm6eix6to6hJ2Kl+cn0HKZw+Qu7UXmS2 D72qmWDDbKJTFhGsm0R+uI/0vi0EaluITvsYWiDs1ncs0kfeoHBqH+HpSwm3XIayCqSP7aTQ dwA9EMVOD5M/vRchC8TmfwZ9+kcpJE6SPSXgbh8AACAASURBVLGHQFULQphYyX7S+7aS3vdr ZCFH4cQRhsTzmHUTqZl9HdnTB8gdfp3Y7N8n1DTDMzC6kWWFoRMk9r6AEa2jas71iGDMlxU+ fHyAuDQHt7cDl1Kyt7ufx17rpjGgU5AKJUEKb1ftKKRhsnhqA1/4VCtLLpuMobm/7WS2QDgW 4aWDgxjCQUiB7SgsFIZp0jwuwJx4hHg4QLZgcfx0kqHhDIZSpV09gJQgNY2Zk+u5fulHaJ3W MGKoUipODmeY+vZRGt44ROfRfqyISfvVM5k/Y4JXSCE0VV6UhCCTs9l/bID93X2IbAFCYZyC l1khvIx0KZHoBAWczhbY35vCsdxIdFHSvcborvC0BHcT7WANnWD47afJHHgFPdSMFh6HMzhM /ugW7PSnCDROQQ9GsNN9JN59kVTnRpC16OFJWM4QmUOvkT3SSO3H/ozYtKsRRgCZTZDe9yuG O/8NO1vAjE5BGFHyR3aSO/gzdPMvMGK1FE4fIfnmI4Rnf4bIpMUQCLtjtAsk924ls+dfEbEH CU2YhywkyB56g+SbT6CZEURsEnqwEYlE5pJIaZE/+Q6Jbf9IePZnCU6YCfksuZP7KfQeQSkT pyAQPQfAtnGmfZR870GGt/8DenwqgXETEHoMhEBaWdLdrzP86/9F7MqVSMf2wnI/HFnR17WF DmsONy5qfh9aG+TlZ99kxqeX0fybDuCxc6NGWL0fqJyzEfP3Afbp4/3FJdJ9uNnKvcNZdh05 zcSAjh4IIYSGrRRI976mScY3VHNP++VcNbcFQ5Rt7rGgycfmTuBjc5roePckBQQT66O01ASY NbmehbOauWxyPTOaa7EsRcaS1NdEyQVsqkM6luPZsD3BkbQlpxMZHCldrcYbraYJxleHueVj 01k6bzxv7utF0wSL5kwgGnCPRC1ThHhucqVIZnJ0HOjlZE6ycGINStMIFZMGcLPPpWfnNzSJ bikiApzSuCrmbAwrmZu9LEHoSCtH9mQnVu9RIpOupmrRZwg1zMROnabQtx8RrsEIVyNzKZIH fk12/3aCEz9BfMEfEKqbgpMbIrlzC4m3/pHc8b1EJi5GYJE6/CZDnT9FM5uov/JGwpOvwAjG yPZ0YSdOEpq4AGlnsAYPI0KzMeMtoBtl17Xj4KQt9KqZGJEql3Ilm8ROnUSZDYQmX0H1VbcS qJuCtAvooSq0QAgKNsouYMSa0M0YelUzNYtvRaZ6kKqO+mu+QKBuqnsMrBEgUNuMUX8lhb5d 2IOzCYybDlKR6+smufvnBJp/n9p5N2N4ETDvu6AY7OLBu5Zz38ZOANpXP8U/ffM2l6I8vw31 fgiL5Ltc2349LyUUzWf4rQ889zCfvWkVneDmEzx/L1M+wEV1xwNhFm99ArXli5A8Tle3xdwF U97bIpHrYmW4lX3rXmLLvdeULlfOWeXrEX36+K3GJfksSr4LoZjaUsdXbmqtcJeCVtrqKWZP rGPhrPEEDL3CMevmHdTXRPmDK6dThSIUMrl8bguXT29gSlM10YhJwDAwdY1M3mLWxFr+5IYF WI7EqNiqF7vSDEEibXFqMENzfQwly25dITRCgQATx5mMq46CgFAxeF5zXQSuwlKOBzZ0jZkT avjCNbPdsXuO4KIcUqWIKFcbcaSkJh4iEg0VOy15eC689S1mjxcLCXBspGOBlUdmkziFDEa8 AaOqAZRAMwLkTp8gu3Mzdj5P9bTPEahuRAgbPRDGrB8P4UacdBrl2NjZIVK7fwaOTdWiTxGd fjVGuBqEIDJlMcqx0Mww+YFDWEMH0cwqzKrm8oFJSmFnB3GsFEbVeLRgBCEEdiGLNXyI4Ph5 VF1+M+EJcxBm2HtmzT01MJPAsQbcA5gC3jnlSic/1Elo/K0Ex01GC8W9iZUEaydjVE3HOtWF nfo4gXHTsTP9pLtfQ2ZTxFuvwaid4B0Te4mRZmfhAhTl70Oal22DEY7QThtncQHndvCVm1bx pRd28+IVYV7+4VayWeADDISadWeZBjy377u0Lg6SUPe+py77Xn+GDQD3baTrrmtYUPR4V85Z xevKPn38duOS9inKo8Oor4rw6aume/m4RU9GRUKVUhi6gaFruBxMbtJD8bcdDQX41EensWRe C3XRALFogIBpYGgVwkBBKGgyd8o4Zk2qBY8jyoVWLuQtyAHDXdyEdnZSl6YJIkGDYrSSlBKh FU1LWjnoSAjqqsLcvHQGjrcWlYxKqlIIFbMF3Fua0DAN158hKrSbC8MtK4V38p6uY46bjlnb QvroTrIDBwhNvIz4jGsItSzACMdR+QTWqXfJp4ZA18gef4PCwG43EkwInORpRCGJwgFpYyeT 5I+/TqDpCsItCzAiNa4rRUmEHkDoAVASVSggMycRwWr0aCNo3ldFSWS6D5VPoEfq0YwgIHAK eZzhdwjOuYZQy3yEGS0HCnjz5aRzaCEdPRj0TvEDJ2+h0oOIiAnCwM2Gd7mkjOpGzOom0ic3 YWdSoBzyA8dIvvMUwaaPE//IJyAQKgvj9xEjKMrjAM188xl3p7yjstyeZ/na3HY2AtDGY9v+ jS8vaSDX9SjhVZDYspI40PXorXw9v4Zn7loEyS7ub29lzVagFaCdNZwBj6epuqae2toGbln5 Ze+GzY7H/5LFd7iZ0MvXbeaf7r2REC519+cWf4mtAMsfoeexlfR/91ZW5dew5a5FkOvi9vDX uSfxDIviOZ685yvsrIvwwJoNrOsY4JbOv+Hr+Xv5V2sz4cXuiKrEfazvOELwLyZz+H/28M1l zcBx7hctNHYmWLmgUpTk+PnfrWHFE5uo/1I7z7z+DRZcM9IcfCZ6nnf7fGYGPHv/HbSv2eTO 5Oqn2PTN29y5e/x2Wv8lwvL+DWzshBWPbOMfVi7BOMczN3OYh++4hVUbO4FWHtv2C7685Pzj 8HFhXFLorECQtx2GU3mS6TzZdI50OksmXSCTtshk8mTSBYRwk53dZGrBSJ4nMAyNxuoIM1uq aKyLEgmaGJpAqmKIp/T6A10TFPIO2XSebMZy+0nn3b4yBTJZ928gkaV3MOX+DRT/Et6/w/T2 J+gfTpOzHG9BVygh3aQ/XA0hkcpxejBNIp0nk816z5Yjn7cwhEbANLALkky6QDpTcPvPFEil cyQyec9EVhH6OhYoV8MRgNBNQg2zqfvon1Bz+c2YkWryR3dx+lePM/jGJgqJXqxcivzAQbAU uhHESZwk338Ya+go1uARVD6NUTeD0PipCAPsoWMgagmMm4oWDJeEn0KgpERJlwVWWmkK/W+h BUKYVeVzu5WSFAZ7IH8ao246RnycW9eyUY5CDwcRmu62K0qxXTh2BqeQQQs2owUCJY1T2gWk A0YwTJGLS3hfTKEZmDW1yEIGK5vFyQ2RPdKJcHSi06/AiDYgPHPh+43uV/4NWv+YeefdVh9g zdx2etZtZiA7wEvrq7hj6f9gjw2WlYet+VJJK5/gkEfQtOWhVtb0r2V3by8v3Ll89KbjC1m3 upWvLm5k2T2P0tXnVk52fZfFd7zNC91ZVHY3kftuYkNXEuwD/NXiLzHriQ4SiW6eWpCnP+v2 218ihrLoIeHxOlkk397IA2sivLR7N8unxckkejg0bBGa80fs37waWMvunl5unzeJq25t44Fv PE8OyO15njW087EzT0UafJ0vbWrlv3/2Fv5kfRtrNvz8TOLas1DsEztBqnE5+xMWVu9LVD3w eR7r8ugF80nYuoHrN3TT/dJ6Nnx1NR1JzvnMLz8wlVXJexhQit6Or7mfyW/18bX/e+CSkvIU 8O7RAf795b0cOHACTRfeJtILkFcOZiDIFz61gKsXtBAJmIwkh1Ne8pxbXvPclEUzj1axK5dK IpTg1GCS723upHPfKUK6KLHNFs0QSgqEcNx6QkMgvfa8tvFCRzUYP6GOzyydyeKPNGMaGoqy UOpLZPnRi7vZsasH2yp44bwCRwgmNlXz2WvnEIuHeWrLO+w72IeG9GSgQCK4bGYjyz+1gOZx 1YzMDzjfDlh5PFTucysEwggSappFoLaZ2LwbyB55k+GOx0nv3USwtoHQ+FlIKw+6IDrt48Tm tiECFZFBrpMBPRhDMzUcKwO67moRRaJEL/mt0rro2Aolc2iBAMIMl0YtZQE71Y9TSGDEmtCC VYCDKtigdDQzMOIbIoSGVBJ7qAeVGcCsnoEWirrz5OSwE8fRAvUY8fqSqculdHE9QoG68RjR y7AHj5LYkyP1ziYCLVcRnbYEYQZwtbf3n2/rvBTlRfQd5iHa2HbXjdSG4JoVq2ldtZRt+7/D 50w8reFMJNn5NKz+9p8zp6GWOV+7l7ZVq0ZhWQ1x4zffprv9ab654vO0PvQdXujpoOYcVORf qzo4CnX3SC3oLJxBXV7mvDJoaRlJER6/7W5Y1c7ryS8TffZbcPe3yiYmDwde2AB8iUkGmEtu hVXreP3hL3LNWfxUo8CYwhfvNHn5mR/yi373kCMsL6LwHJTw75mu3E8CuSRcms9CQW9/ih/t OMqeg70oTQN0kI5nspFEQiH+5IZWDKHjLqQuSqcWlJuiaKsu2qfK+8WigBFUR8PMmzqODa8e 4VTfMJbLuYEmXNOW24Z7TQk3R8EVXsUdqAJNRwiNmng/qVQe09BY/JFmQEMIScGWHDw+wObX DvGfXSdcC4xwI65qwgH+W2M10ViAdD7P28eGePatEyA8P4aSYMGn84LPXmuVxq/A45i68MwW ze8qn6SQPI0WimGGqjCrG2DK5eRPLyN3dBuykAIjgBFv8FIP0mjBKEbMXeWUYyMLGTQjihaI oQCjqhnpDJPrPYCVHkQLxV0TVS6HZSXRzDhmuNoV4pqGtHPIfBoVDKGcAvnTh8mdPIyyMhiR OvRgFCefxBo6ghZtRo9Wg9BHCF6kg5XqQxWGMcZNxwhXIYRA5lPIxClEcDwiGEU5lltDN10y QQRGzWT0usvIHnqF/PEgemwKVfOux4hUe/P1wcQ/nY+ivIhc/xHgbJK6unDYpWXtPMQArpvh zDLhMR5YOGXJbTz6di8zRCP3PN3JY4xORW6fcp3w56L2BsAYOYqR1OUjYcEIYWc0t/FIK2z8 0dNE7utkfedVZ9QY5KffcY1xLeZ9pas/fuEA19w248IPmuvi9nArPXev597PzGHamWMpooIS /j3Tlfu4JFxybEXBdshYkjnVYRxPm8A7A6KgFLGwSXN9hICpQ9ExXHKDl1+75m3vvkf1UEkb LlAoKYiETNqumMY/mCY//OVenu/sISoUEV2gKYWjBJbS0Us7dO/XUExyK/YDZAoOP3rjGPMm 1zJ/xniChoZSGn2JFB17T3CyP8WEmElN0EQqh7TjUFcf47r5E5ncVMuJ00nmNMV5p8rNQDc0 1yczWLDJ2xb5vOWZYySlDPXzQniCwg0PTXV3kN7/Cka0lvD4GQgjSCHZS+HkuxjxyZh10zAi dQQaZ6OFHLIHXkUPxgiOnwbSIX/6JIXESSJTriQ+YylaIIxZ1UCwYSaF3sMMd/6E6KT5IB1y fYexhk8Sm/spjOlXInQdLTQJq+8gyd3PEWiYgswMku7eSb5nN3qwytUQhI7MDWOn+zCikzEi tZ7/p7wREApkZhAnnyIYrgXD/eU6eTeCCscmd3I3AgctVEN4wkL0iOvoNqvGY1Y3k937I0Qo SvVVXyEysRUQ5Qz0D0BejIWiPDRzKcu5g2/96w4e+/I8Ov7123SygtktBvG6JbSyiq1da2g3 X2D5qq3UrwcIM3sZ3PTAD/nq03/Kwe8+yFaqzhImyT3P8o/bYtzxuY9h9HbxCrBs9ngmRdsY jYp8dOrulUSqquhc9TQH/o9ZDP/o2yP6GkldfgY8YdczmKQlHCceivOZdav56k2fB1bTvWCk Cco+/DKrtrbyQm8HyxrcZWXHw8tYfP9PWXPbXRec71xPFxtp5aW1d3H1wBYegRECYzS8Z7py H5eEi9PfVfnXqZCkHUnBcWk98lKSdaAgIWs7FBxFKFDM/C3vA5X3n/SEh/LOvnC1ACgeeu26 OdzFR/McyfFokOsun8zdty7i4TuW8EfXfYTq8bWcyENPxqZXKixHUFCCvBLkHcg6iqxD6S/n hb8GlMWeo0P0nHbto0opTvUl+PmOIyRyNqYGWUdSkAJN6DRUhRG6xqmBDCeH0hQch4JU5Gyb vHQoSJdCP5W16R1Mky1YnpmNMSxqxcAAXIGrmTipbtL7fszgaxsZfPUJEm89hQhCbN4ygk2z 0YIxQo2zqVr0FfR4Lcl3fkz/qxsZeOOHpPdvQtgp9HAtaCYIjWDtBGqv/G+EmiaSObCJgW2P M/DaE2QOPocwDfSIS1ht1kykqnU5QsuQeGsjg6/8C8ldPwU7iVEdItA0CREMuMLdskBkMGua MaLj3LGrkssfJRROPoUWsgiMm4YRrnHNjsFqzPqJKOsI6b3/yXDnv2P17kVJy5sKhdAM9GgM TJvghN8jOv0qtECE0tcEWaGBvo/wKMqXb7iDmY111LW08t3MbKbHK+my5/CNF9az8Y7FmCLM 0jt6eKzjGy5leHwh69a2c0drHXVzv1Nh0TL45F++QPumr9Johlnxq3G0cfbuOFwVo+uO62ms ClM383pYu4m1NzZ71OdVXD/V1c4aZ/4xbw7YJeruh77USjjcyE3/NkxVGOZ87n7u5gFmVlWx +BlG7auISoEVn3cDq1sfYm5dFf+4yz0pvPkTt7EcaF9/W4kyvYjdz/0ztN/HxxrKq3Jr+93Q +V3eTY5Oc175OjTjJh5bAddWCcyp17PJm6szy4/AqM/s0ZV33kGjKRBmFTP/5tdkz9WGjzHj 4ijKi6YjBZu37+O/f+9V6hIZbARKSKQSGJqg4DjEQiY//PotzJnW5JmYivJJljilUtkCR/uS NNZGiIeDGLrmLTRqpD3ay4CWbmo1QkAmb3Ho1DA9p4YYHkxy/HSGXScTvHV8mEO9abBt6jSB zcgkPjTQlcIBFs9r4f/+k6UsnN5IIpPj2Zf38vWN28GWmJpys8VxT9ebND7G4mmN1FWFGUpl eefwALuODqAciS40hCYYthyaG+LcfXMrNy2dSWNt1PObXHgLXMm85GSGyfXupzB4CidbQDoK M2wSaGgm0DAdI1ztzY/EySbI9uwh338Kadug6ZixMKGGqQTqJiECIc8MpqMKOTIn36HQfxI7 WwAhMGMRQhNmEqhp9iKcFHZqgMzRLqzBIaSSmNEIgbpG7EwKIRyCE+YRqGpytZ3efaAFCDXO 8kxEmqtRoYG0SR/biZ3qI9x8GWbVeE/7tMn1HiJzeBeOLdGCAcJNkwk1TncFggRVGKLvV0+Q 2fskVYu+Ru2iW9GCsYp5Kh/f+0HhwhTlNsmkPSrtdi6XxAjFR1Hh3TrxC1Cw5nK5URlWz0lF Pip199j6Ohs2Llu519bgyyysu5avd1vc9gElfLwnevRyJZ+u/EPAxc1ixS9TSDefQqNiIRea d4SB+yM+ejrFtIkNhExROpeiGGKaLdhs33WcH770LpdPqWHe9CbmTW2gNh5C1zRP4/BOshPu mRDJTIGhZI7mcXHCAZP5UxqYP2UcUsJQpsDh3iGO9Q5zqneYvYf72bK7l77BNCGPykkqiaY8 bUe5lCSaZzXZd2yIZ187TKZQoEY3sNG8PAqFoxR7jgzy6v5+bKkwdI0aUydqCNA0pAIdSVRT iLzFoVMJktkCjbXRMU2rayErOusVeqSa6NQriU4drawsvVJoaOEaYjOXEpt5dpulj0y40UwE gkQnLyY6efRBFIMAjNg4qua2nXfMUkEg3kQgXhkrX4yxcgWZ0Ayiky8vPyPukbRgEGqaRahp 1lnPppRAYJE68ibZg68QnvRpojOXoAUiZ0yYKLX6QeHCFOUG8fjoP6VzU2afu85Y+j4nFfmo 1N1j62uUxkacd7Fn09/RyTqu/wAzA98TPXq5kk9X/iHgkj91M6gzMRpgeDgNepEzqRSMibIV v+zq4bLpTTTXxVDKwXVEQy5v8db+U/zghZ384I0j/Og1jaXT67l16QyumDWeaRPrqYkE0DRV IiRMZHK8uOMwO7tPc93lE5k2oY6G6iiG59uuiwapmdrIgimNFGyb46eTNLy0i4ee3Ymj3NBb DQ3h5UkoASFdxzR0snmbnQd7efNALyaaG+ur3LM33KVPI2oaVAXcHa2Dm70tK2znSoGpaaRt m8NDGfK587ocR6C87HkO/pImpCrue/e8c83L15UXiTbSiV5KMKR0CjhIT9iUjsGt1GfKGQuq dO65e/ApVNgtvWd1Hdheho3wMhuL4ylGdLmNeQLOO3NbFC2NqhTXUBoCIISikDhN6t3XEaqP 8IyrCdaXHaVCVRT+YAxRPs7AzC98n+xyn1n2dxWXLCzisTAfaapi69EBorqGU/rVu5QVtoIn Xz/K0pmNmAsmURUNIXAYSGbZc6SPH7ywhy1vHqVJ1zB1eOfgAFsODPKZeeO55erpfOLySTTU xggYgkzeZvveEzz8bCcv7+vjuj0nuGnhJJbMaaKxNkY0HCIeDRAyDYQAXdOIRUK01FcT1AW2 rdxzs5UCTcN2bPJKo6UuTG08xMETg/zizSPkc3mCWnHPDhKJprkkIJWmrLIFT4EX7y+FwBSC obzi+EAWy3ZKczWm/W/RL+w1rYr+muKW3yskRjTm+TqKi7+ASibacoPFBI5iiLInGryogiLj rpu7UOzfLaMVnQTecxdFlUIWE2hGzIlAK9V1LyjwzuI+O4LJjbwqPoo7DomTGUSPNFC9eAXh llkjkiJL7VaGj/n4QDG6Oc3H7wou6bMXAprrIlw1tYZ/fUUwK+BmH7suBXcpsZVGIJXhoU07 uO5QL1fMdM0Vbx3q47Xdx9nb3U/QAFu6SXgBHaYLxTv7T/LysUH+ORbk2sUxsBRvvnuSf/5Z F329A0yLaZw4OsBjPcM89dJuZrbUMWdKPTPHV9FYHSESMhlIFHjr0Gl+3XUEy3GIGG4OhESg KwFKR5g6s5uriUeCvNJ5mO37TmFoOpoARxYXIc0TFO6zOaWV1F0nNXTPzao8k5WOliuQ60+S zmQqZuxC4kKVtAuX9oOKLXhZEBQjxMrOo3KzJdp44Zl7SsKg2EVxMXdpWlTJ5l8KZqZ44FBl MMKIPXwxtFlAUUi6rz39wxNGxd2/+whuHouiggamGNxQ0no88ezVD4+fQ6hxtnu/eMa7KJ75 4Q1wDOHIPnz4uHRcJEV5aR9JU32M+TObCERMNE2C1DxruvRI9twDefYeT9LR8w4ZdgEaISGJ Kwh6Z3CXw1rdaA1TEyxqqWXqhGpChsa7x/r5ybaD/KjjGDOjGgqNvKOwrQL9WcnB03k2vX2c XHGn6VGIawLGCYew5h21WqEFOEIwsaWGqc219A2leGPPcQYTGWoCbvyFprn+jaBpEA+bBAwd Kb2FTbhaRsFxSBUcrIKFFGVzjTQ00tJhIFkgZ0lCpZCO861sxfihSmNQUVZUaA6egqOKZqPi Dt6TZ6X7YmR9N2BAjOhLlCqVtRVRoUW467F3fjiyIvS5rP1QTKykQjsQgJAIpVMkfil6f874 EnlmsLIhzL3vaUZ60WNUHnFZUECJpMuHDx8fKC5Ss/Bsz0phajqTx9fxucsn8Ou3jrkWCSp2 4x4iuiKqKusDwvUHSDSvnkQTAltpVI+v465P///tnXt0XPV17z/nzIxmRk9LRvJDNn4bm4fM M5gmJMiBLEibjFduadog0pCuijTNLWKtNL1Ke9O7xF03S9yVFUTTXJmsVr4JcklFKPJdxA7F VmIIiBjZRgZL2JItyZZsS5bGmtHMnJnz2PePc+YhWZaMMY8k5+s18jzOb/9eM799fnvv33df x+rlCzl7Psaeg4O8uP8Ey/1gieLY3MGrCnmqFxRhQVq8pAmr7Tt9A2cRF1tReFVBNwRPMI+v fGwFa5aXc+CdYX7+5ggLfL5MCz0AikpJaSF337icirICdD298Nn3yaOTMQ72nOXocBhFtc1W JnZIsGYJIxNxogmNQDp5j23Azyyg2bt2Z9HLZMVTnEXYXnnTy3G2pOLoV4d80CmTkZlrpcko lvQbZOqwMsrGcpSL4hyIS0+Rc1ef3kU4MizFcpqYu/8QZx1P5/rwODsJJRMNllG0mT475RwF ZSnYPFWOY0Mcfq0sEUiOalCY/tqFCxfvGy6TotxZNJwf//LyYmqqNzI2EeWdE+P483yYIo4Z x44SQgQ1Q+pnL3iWE5GkKqCIYIhC0J/Hx69ZzJ/cuZ7N1y1DLDh07AzP/rqPsaiG36MgqnM3 jIKlqLbzO70QCw5lhl2n4dSoOnZ8SwTdhKVXFfCZj63i07euRkvpvHhgkCNnI6wOeDEsUFEw LIsFRUE+97HV/Mld61lcWohuGmQXdjgTnqLQ6+HoyASWZROgWgL5XhXTMDkxGmVyKkV5cX5W F2Tu3jNEJZmdRJqnKne07V1ErilKyBIZKpmdQOZgo+T6U9JKJ/t8WjrVjM1quh9kutM7PWNZ JZK+q08rmPQHSmYO0tVnlVvGZ5LpteQodsXxl5BRYlnD2IelDjQG+4fJr1xDud7Pzv/3Nqvu +Sw3lF9Zy70WHmQ4ks+KFeWX/IPUwmGihgHeAKWll+ZLGOt9mV+9BZ/aeifvvQsavS+/yADX ce+dl3BC+wpjbLCfeHElK0qvhLs9yuu7f0Gs8lNsuSGQ87z8submdxWXdShPcp6JgN/n4dYN lXzlnuuoqCghkOdFMwWPouJB8AAexeZ6cm6sURUFL/bOwBIBj5eiBflcf+0y/jp0E5+8aQXF +X5My6IgkMeyihIWlhXgy8vDsBRMy15w87Dl2HsZZ4HJ5JF26lTETlCkKHjyPJSWF7Pl1tX8 +T1VXL2omLdPjPLLw6dZ5rN3S4pi4VXAQGXBVQVUb1rGsvISCoN5lBbmU1oYoLQwjwVFAcoX FFBWmIdXAcUy8YodMOzHg5aEE+EE5Q85VQAAIABJREFUsUSWUC69W5DMYqnk3J1DOle2WIZN smcZ2d2HqYORstMHKs6CrsexUjE7cVP6DlxxFn/HFCQ5Q5I26aTft8uk83OnbVdWRlFY2MrP 3sVkw3VVJW0WchhysRWeSK5RyZnsjF/Bfm6R3ull1UH64Iyi2IY8Na18Mmr0g0f/jr9k5dq1 /OVzvQz+4nFCD4R49cyVPt4V5am7VrJ25d02Od6cMDi8exsPblIIlpVRUVFBRVkxPmUr218e mbee577+Se6//zniV2LV047w9U+GuG/X4BUQ9i6r7t1Oxcq1rPzBm4DG4OHXOdA7X//nQPgQ tffdz6O7jk9//q7m5ncf7zH5kWo7HEVYUODjntvWsry8hJ929NJxfJS8RIqJpIGScuLqLbu0 Kth+Cp9Kic9LYVGAqxeVUH3DMj5xwzJWVZaR57HjkAI+DzeuW8Q/lhXQM3SOPd2neGtwnOhk At20iKUMDN0Eh+E107i070K18Pt9BPO8lBQG2bCilHtvWc6mNUtYVlHCmfEob50Y42QkwdKg D8MpZgosKPCx6eqFrFm6gIDPk8kRbvcZVFUo8HtZUlaA1+clhse+TkxUFBI6nI1qpHLDZ8WJ 5XF2Oln3QNYybyVj6BPDiKTIK7saNVCM6HH0c0NYouMrWY43vxQjcZ7EUBeYJoGrN+EtLM9G QqE45qlcW409V2om2imtUGzFm+OqyCg0W55tVsq0M2d3YKuW9G7OfpU1FuXsKjKbh/Tybznt sw+/ZJJOCTlmr/S4fDjqouL2h2hquo8//NwGhp44BtTyB+uKMDRtlvMABlrUwDvLwby5EeQT /72ZlsJPcUvmWMBssjR2f/t27vtuNzX1zex56lNsWL2QyPHX2FYb4qFPnmDxcBf35qTbMzQN I30GwRjmQAdQ+3GyJ2Iup80GmuGFgV46gPrN2V3FtPqyb6IZs50XMdA04+LnRWat2smqt+gW WpqaWfOH10L0TR6q2kxH3S7k+/Mno5qtjdETR+gGGu9YTfTEc5nns83NrH2cIf/CQ4Wz93U+ WZmyc8yRphk5hw5nHKK8wniPdJ3OPa+ioKoqZcVBbr12GX+19Sb+5/23ctcty1m+ZhGVFcVU LihiSWkxS8qKWbKwhMryElatWczdt6+mbutN/P2ffYzPfXw965bbisKynINZqkJxvp/Vy8r4 1M2r+Mbnb+Kxms089NkbqL51BdesW8KyJaVULiyhsqzEll9axLKFRVSWFbNi0QKuv3YJn//4 Ov72/lt4ZOvN3HXTaq5eXIwlFuMRjaSo3LRhMWvXLmb92iVsWLeIdesXcfsNy6i+YTmF+f7s gDn8VWlHsd/nYVF5MdetX8zGaxZzzbrFrF2/mLXrK7hlQwUbFy8gz+/JjFf2f8l5nZ0OxdRJ jh7nfNd/EB/4DZaRRBEhOdpH+OCzTB3rxEpGAQs9Ok7k8M+Z6u0gGT6FmBpk/AW2cp5+QD9H eZBWCLkHHOxgBGbc1StKVpFlr02b4lRnZ5TrVUg7xdPfkbRI2/9hU7A7Cg1IO+8tZwymj8ts 4/RBQOMXP3iUR54/hbcozJGuDuApqm5X8AWDbHlsr31jgcbr27+NovgIFgfxKQ+ye1CzifEU ha3bDgPw8uNbUJQHOawBI7vZpChsffIAxuBLfPP+r/HmlH3nFj68kwczsjax7fUxAAZ3NnDf d7tpaG3jtsQuPr15I/d98YtsrO3kT1vaqKKbo2ec299oL48/uAlfMEjQp7D9cBRj9CidQM0d 1xC4WJuB3u0PoihbORAFwi+z1WknwMjL29ik+Aj6FIIbHwDg+vWLIHyAb29RMvVtOxwFDLsO X5BgMIiy5VEO2KwhjB3YwVbFRzAYxKc8Sq82V71htm9VUJRNbPIF+ewPD9C/51956JEDLCg4 wtbizXYuiyfuQ9nyv/nRgwrKpscYARjby5aMnCi7H3/QaeMWHtyqoGzZRhgY7n4FqGLD1aXT nk+fm4uX793xMIqisPXBLficPqXZ1WfrK1o/2x7ekhmvrY/t5sKNyxxz5NSnbFIIBj/D61F7 brYoPoJBH1u2bkFRNrGj/wrzsst7giWmiJhi2X8ty3lXJKYlZeDMhPQMjsrbx0bkyLFTcujI oLzZe1KOHBuRI/0j8s7gqAydPS+ReFKsjEhTLMt05Dj/LEtMK3OFmKYp5yZjMnAmLEeHxuRI /4gcOTYsbx0bkYM9Q/Jmz5Ac6RuWI8eG5Uj/iBw7OSanxiISS+ppCSKWKaZpyUQkIf3D43J0 cFSODo3JsaExOTZkPz8+EpbxSExM05reW8sSy7LbZ1oik5GEHBsak3cG0+XHnNej0j88IZNR zS5vmWJaplimIZaREjH1bH8tS0QsMeITMrH/pzKw7Qsy9st/FjMeFtPQJHzg3+X4P90qp//z e5KaCotYliTHT8poxw9k7JV/Fe3ccTGNlIgldvtMS8Q0xDJT9sMynbrsNmfH1cx8JpbpXK87 r+25tMS+xhJHtmWJZeoZ2emyIs64WHZfp7XBMjL9NEXEtIXZ5UzTGRvLLufUJWKJZWa/Vx8s BqQehFCLRBJdUuNorVB9g9RUIVQ3yYSI9LXVCSDVdS2yq63R1mz1u0QS3VILQk2bJBJdEnLK tw3o0tdaI4C09CRkdJ9dpqkrIjKxT6pBqG2W7u52u0xVk0zIsNSDVNW3SltDtUBIWtpb7DbV tEkk0ilVII1dEyISkZaQXVd9S5s019VIS1dkWj0XbbMkpLUGgTrpE5FEV5MA0tg5KjK6R6pA qKqV5uYG+zk10pUQ6WystvvT2Sed7a3SNarLQHu9AFLX2in7mmscORMio3vsPlbVSmt7q9SG 6qUnMUe9OWNfXVsnLXvekbZaBGqlZ6xb6qvsz+qamqW9c1j2Ndrj062LDLTWOn2eyOlzozTV h+w+17VLQhJZeXruc7nImF1Yvr2uyn5dXSf1NfZYNHdHLtLXiLTUIBCS9q5uaa5BoEr2TUz/ 9s01R221Tn1VNVLftEcSc8zNlcR7VBams3zafzOLi+W8noG5fvKm6SgEK/dCe+XJrBWO0jDn WDysWWvOqceylY29KM1x4UWl2wpM0n8vUYhlpMRMRCQVGRVt9KhoI0dEGzsmxtQ5MfVEZrHV I2fl3K+aZeBHX5GJrufFTMXE1ONy7rUfS19TlYzu+5GYibiImGIkJkU70yPaWJ+YKeebYZli JmNixMKSPHdCEqfflvhIjyTPj4iZnBLLNB1lYWbaZCYiYsYjkhw/KfGRI5KcGBIjNimmrokp ppiSXsQtEVO3+xE+KdrpHtFOvyOpyJiYybiIo5QsS8QykmLGI6KdOyGJMz2SDA+JEZ8Uy0yJ 6ShZy7Kmt0GLiqVrYibjYpn2eJjJmK1YP2g4P/RQU5ckeloFkKr6XSKi24txtb2IN1QhUC8D IiLSJ3VpBZNetGtaZE9rXWYr2dLZJY2OshkVka6mkEC17JsQ6Wmpca4LSU21fX1ta0+m/uZ9 e6QWpLZ9WETvkmqQ+n2jMrqnXqBKdg3rove12YtM475p3cnWM0eb9T5bQda0ii4i3c2hjNx0 21q6EyKSkKbqrMLc5yiLqpoG6RzWRWRUGqvTC3ytvWBSJe0DiRlyHMxRb7rv1fW7nIsH7PaH WiSSqdtWDiIifY6CaO/ptse5qkGGZdRur6OMZHSXAFLT0jND3nTZ2TGbq3x6PGulT0QGnBuB i/VVH2hz5rhKamsdpeN8F7KY63s1kKmvxxGbrqd5lrm5kniPObjTkfNZtlg7NFLBkhwbd8Z2 TSZqJ5uGyP5fVdMRMpZ9bdrunmuGUHLiaiTzx47KgYwsRVEcCg5HgkA6rFRVBHFSp4qIzVSR 06+0eWlaSKuStdArjkM3bUgRxQ4Lnd4fcloDWAap8Em0kR6MyXHMRBTLTKJ4VbwF5QSXXUug 8jpU1YcYKfTYGJYoeArLUTwBRE9gxTUUJQ/V5wNVwUppaGODmBOn8JUtgRJnpFJTxE+9TWps EDM2gaknbT9FII/gkusouPpmPPklYJokxwdInDqCael48GJMTWBo51FUP3mlFfgr7UNxqjcP O492kuTEEInTR9HPDWPpCXuc/HnkV1aRv+w6PIESLD2Gdm6A1OljJM+ftp3yHh++knIKVtxM 3sLlKKoPEYPE2An00T47l3deAF+gED0eJrCkCkVRiA3sJ698PYGFy3J8Je8/oiffogNovH0V Z4/+BIBHv3w3GD083w5V9ddTGj1DVzdUN4ZYARj9B3kCqN6ykSIMkhGg/fs8+nQ3NQ2N8J2/ 4/kfNNDeDQ17/oxyorywtx1oYE1plF/ueRqoobktxJK8v+Hvn76JDUtLiR7+FVDDjeUpfgps mniVxz5zPx3ApiMv8A9f+y7UtHLXUi+JA+MAfPHzufkmonSn6/Ge4XsXa3N4hE4g9Onb8TLI v32tHahjXYXB22/abdt8QwB6d/BIB1Q33EQpcOe3fko7/0Do777D5u4SIq98glc7oKq2ka/f s5rCmof56Y03U14UZbvTx1s25vgwLlqvl7Nv7Afgy1++y7l2iI5uqP6LKooY4+DuDqhuZp2z klXccDMAT/y3R+johvpdf8HS6En2dkBV/RdYA7z+b80AfKKqEsKHsvKmyc4ds5N8b77yjV9l DbBz/9NALesX6XTO0tfEuD0/tY2Pcs+GMr76jSY23bBiOoXKXN+rdBsbv+okc9I46szNp24I YMyYmyuJy/RZKDOez/wBK+lozJxH1mmpKMr0R2aJzbpGM9EzSu4bufZ2R46aK0slnf1t+nvp 1zNaqdgH79L/q+qMdinpENDcuhWyfoH0JwqqQ0aYLouSvULEQI8MEz/1GqnxXhRfAWrhUvTx M0x2tRI58hJi6IBgGjpW5BQer4U3uABFVRA9jhmPoPiW4M0vtUkLk5PETrzG+e7n0c72gpmy 6zNMkqffQhvej4WCt7ASxRLivS8w2fUM2uhRsAwsI442fIjznds5/9qPmDr2n5hWCsVbgHaq i/CrTxF5ey+WNmn3wUyRONvP+UPtRLv/g9TkMIo3AJZF4tgzxE68ipWMY6amiJ/sJnLoeaLv /BxJJcCbjz7WQ+TAvxPtfQkjOgoKmIkI2tBvmDr+S0w9gSTjxIfeINr9c4zoOImzPUQObMeI jtm+lw/QdTGwfz9QRdXyIobefBMIUbXSizF4mHZgy80rwDmT09H6DDv37uRvv3A/AHWhTUAp 11ZXA910U8OjX76bfKD96XaobuIbW8pBG+C1dqB2I2UEKbsKYJii5dezaZWPzhcP5tiyo/gW beTeKnjiofvp2txAXaiKJ772EE+FGuj54ZecBceOvNv142fYueMxtmzdTlQbztYzR5ujJw/S AURe28FjW1fyXYCa26j0QioO0E3btifZ6vgrNm+6Gq1/J49vO8ym/1JDHcBCf4ZTvDse4Jrb bqNC7+WFX/cDQRZfVQU8zfP/vpNtj27lydfDc9bbnx77Srt30RNH6ADuvWk5RI/zfAfQ8VOe 2nkADShadi0hoKO9A6obefTepdn2dD7HticfZvMj7UCIG1cVZeRV37R82vNpc3Mp5e9YD4zw 5l4gdDOVgdn7mp4fKtZw26b1hLt288v+KFrvDhRF4cHth+f8XmXrW+18L7zkUZWZm8+k5+a2 2VhC3yOu8E7l9xpWju/GEnFs8JZYRlK08RMS7XtZpk4dFH3qnJiJiEwe3i3Hf7hVhnb8teix iIhlSuL0URna8VU52foXEj99VMQyRRs9JsM/+0cZ/PFDEnlnjy3v3HE5vet/ysln/lYivR1i pqbsRpi6xIYOytTx1yQZOS1WKibambdkpP1/SP8/f04m3nhGzOSU6FNjMtrRJMee/JwM/uS/ yvnuFyQVPS169LSMv/oT6W+6Wwb/7zckNvK2iGVKMnxSzrz4fTn+fz4vox0/lNhwt6QiZ0U7 1ycTXT+TyZ49YsbDEht+S07+7Jsy8C8PyLnX/020iRNiRM9KtP/XcnLHN2XgXz4nU32viJiG 6JGzEn6jVc6+9D2ZGuiS5Fi/jO19QoZ+/JcyeeQlOdvxTzLUcq/Eht7M8et8ENClLW1D1yPS XI1Q3SwRERne1ZDxN4iI9LTVZ0xMEJKWzuGMlLR5oLqxU0RGHfOBbY4RERHHl2GbM0QiPW2O ycZ51LVJQiRrimlol9FIRCIJ2+YyMdAnwxMzDNORbqmvzspo2DVwQT0XbbPel/EBVNXY5qNQ c7ddV1dzpky6ja09CUn0tEyT1d4TERFdOptrc9532iEio53Njk3dtqvvG9bnqNcZ+1BzxqTS 3VKTMVGJjDo2/6zpSPTujI+jtS89Nrrsaah27Pwhu/3VjTI6Q9402dPG7FLKZ+cz1Nw1R18H pCmUM8fUSOeEyPAe+3vVsGd4zjma3n9nyntaM6Y+cubmSuPy8lm4uAhyzxfYrxFQRLC0SfTo KGZ8EjF1FK+P1OQw5w89hzdYzuI/asAbyGdq6DDhl3+Ip3gBCz/+V/jLVhA/uZ+JV1pRA0FK PvZF8iur0M4cZfzlJ1G8FZTd8SUCi9egqF4sI4kxeQYjdg4rpaF4vGBqRPp+gzbURelt91N8 /R9iJSKce7mZeN9vKLvzYYqurcbjLwQR4qfeYOKVFiwdrtpSS3DROiJHX+H8b57Fv2glpXf8 Of7SSruvgs0krKigR5k89CLn39hOcNUfUHLTVrz5V9mRt6bOxOvPEnvrn7nqMz+g+Lq7EV1D nzxJ4tQRkudP4S9dijZyyGHb9YLHC/okC259iOCSDWS2q+8rwhzY+RO+GXqEjto29G1/PH9o p6ERNSD4bvMwzC6MaDQBviBFmRBIjb2P/ymf/rv2GddW05XYy80XnEuzZfiCRRcPy7xomw0n HDOAncYr51MtSpQiimZ+5ITHXhAGa2hEEzrBYNH0XCCGRjTBjPwfc9Q7D7Solgkt7d3xKBsf eIKa5i5+8vDNM66L4i2yDzC+uxreQ/lZ+2rn2tB137QcI4Zm4M2dsEv8XvXu3sGBVBnLS1Ps +l6I77bXMSDfvyBB1XvF7/uhxCsLwQ4Ddc4SKIqCWDqp8DCJ4bdIjh3BmBpFsTREzUNMkKkI asEybHNVEit6BgUv3uJKFH8QwcKYOo+hnSdYsRpf4VUoqFi6hjl1DP+iSjxFi2xFEY8SP3OU xPAB9Ik+xEo4Fjw/qYlRUPyo/iIU1YNlGpiJKKrfi3fBUpS8AscnY2EZBlYqDL7FqP5CTD1J 8uRvEIGCVXfgKyh1/D7pZFaKHd47OUri1H6wAoieItbXherLc1SohTE5gkJhhgDXiE1gxCbw FFyFNxUGI44IBJffTGKwG1/xQrz5y1HzPsAEytGjPBR6hG6qaf/WH13aD8Qb4LLSRcwujKKi mXkYAmz51vNEavo51HuM8FSKvMJSVm640bFbX4qMmZdcrM25SYRmXBAooohZPrrYWQFvYPaE S94AFzZvjnrnQcCpw+h/lo0PPAGhZp6coSjs67KVXs50XVb5Wftq59qYefTEO3MQL+l7FeVA 6wM88HT6dYi27u9ccUUBrrK4gshhbbK92iCgR84yeeQXxAb24ytZSmBxFd78YkwtinayB7EE tagY1aMgho4eO4uJgrewAtXnZKxLnMdKRfEGSvH47bSnVtJAkib4PCiqilgGU0NvEDnwHIo3 n8CiNXgWXIViWiTOvoMZ6ca38Bq8RYtRVA9mUsOMTaEGi1Hz8jJtFsCMRdCjPQSWrsWbXwGi kwofR/EU4C9fg+IvsHdL6dPfYqGIiqnFMSeHsJQ8xAqgR8btgABFQQQ8wUXkb/wzvGWVGWeW ER3FjEfwlq7GX7EKtWAh/vINzgFDBSUviCdYQo4T6P1F0e28HolA0Ucvb0PR0jXcufSDp9b4 bYF3zVYikQjBot8nKvUivvQT4Qs/jKLD+9r3358xfd/hOOol6xQ3jQSJ0aNoJw/iL1xEyY0h /IuvQVFURE+iKEWkxodQ/YW201pLoUfOAOApqED1BGxndGwS9CRKsBjFa+82JKnZWf7y7IyC VlIj3v8GeuQ0ZZ+opWD17SjePBSxUEuWkhjuRPUG7HzcomDGw4hl4ilcgOL1OdFeKmBg6Tpi mnj8duSVOCfvRRQsK0tXrmbc+w7ExEpF8JVeR+kdf4y3sILpXmk7IEH1BUD14C1eTNE19yCm ZbfB6yMvvxzF58dXupw0kZbi8X4A5qcsAvPdlbv4iOISdlS/owh8ADc3rrK4ghBIx8ragbeW iWiTiK7hKV+Ct2ghqtePGEnMxHnMyBlQFTyBUpvp0DKQ+Biq6sVbtAjF50dSSQzDAJ8XT14A PCoYSYz4OVALUIMl4FEQ3cBMxlH9BXjyF+DxF4CYmJqGpcVAC6OWFaDkFSKSwoydA0XBW7AI j9f+mmXCiRMaqhKAQAGqoiCKgppfjsTD6OGT+ApLUPKCYBqYegJFUfEEClHyAniKF4ORwIyN k1dS4URMmVi6Zp/0zyuyQ3ERFI8PPL7s+Am24sS2btnZOKafOnfhwsWHA1dZXDEImUQSirPP UD2o/iJUj5fUuSNog8sxys5jxM+ijbxNrO91ULx4SxajKB5Mw8BMnAWlxPYtoGLqGpYWR/UF UfP8KIqKpcdt30feArzBq0D1oqgWqq8AK3aO5NABVK8fU4+jnztO/MQhrFQKtSCIqtrmLiN6 CrFMfKUrUAKFtnJTACOGMTWG4l+Kr3AhqAqKN0jw6s2kJn/BZPfPMKZG8JUsxoieQxvrw79w DYXr78RXvIjgqmqi3buJdj+HcX4znsKrMLUwxvgJPCVLKFhzJ76SJfYuzGHPhWwIclrjSno8 M5+6cOHiw4SrLK4Y0iTcmfx0qN48AuVr0SqvQxvqJPLOr/EEe0GJI9Yk3oAHb8FiexeheGx9 412MN1iKx+8HsTAT51GAQPk6PAWlgGKfSZA4/tIV+EqWoqge8OaRv2Ij5vmDJE4eIjkZtlvi 1cFj4l2wBF/RQhSPN3PQ0VtYhq9kCR6vnzTdvKnrKB6FvIXr8JYsAdWD6g1QsPo2rOgo8RO7 mepNofrLED0K1iDBRWtQPF68+WUUrNqMNTWONrKfqd5fgb8IrCSq5xz5CypQPLk8WfYhFyUn 210uhftv/45ijGcf/1+MbPgGf/P5+X0NhqGB91IiqjRe3tbAL/0h6r9y+7v+EV96Pe8/LogA cvHRxRUPxv09huX8yWUsMY2UJMPDEunfLxMHX5DJ7t0SHTgkiTP9Ej99TGJnjosej9jXanGJ n+6XxOgJMVOaiJhixCYlcXZAtNHjYibS10UlcfaExM8cFyMeEUmTrsTDEjt9VM4ffknGu9ol emy/JM4el8TZExIbPirJ8RExjZTdpolTEh/pk1TknM0plWlvQrRzQxI/3Sep6JiYpp7+QPTJ sxI71SuTb74o4/vbJPrOqxI7fVT0WFjEMux+60nRz5+W2NDb Ej74gky88R8SPX5QEmeP2/KM lEjOeRSxcslZPgwOqMvDRM8eqQ9VCYSkMzL7NX1ttdnY+UiPNNeFsmcValskHSof6Wm3+aac WPmWziz5Q9+e5gyvVO4ZjX0NVZKlg8jBZdYzb3/mkCuSkK72JjvWv6ZVMsUTfdJcWz2tjF2j Lp2t9dPOIOwauPLnAlxcWbjK4grCcris0q/Si7iIJaaREkM7L6YWdYj3rOwjc711kYNn0wiz 5njPhpmMipEIi2WkMjxWGV4rh8jPmqO8LT6HByuHq8uyTDG1iOhTY2IZyZw+WDnSHPpBLSxG bNwmA5whJ9vXuZi8PgqYkD2trdI1nF3M0koAEKoaZXi2YnqPTSTocPREupoEqqSuvjZzqK2x a0IkkibKq5HmliZbMcw4AEioXtra26W5sTnDB2TzJ1VfsLBfTj2X0p+LypUJac45ZBZq6sqW 6WwUqJGWtlapcw4KNnVNiDjEh6G6ugwHln1w0cVHGa6y+EDwYd4xX8m651Ewv4PQB1qnndgW Eenb1Srtu+xTs1V17aLPUi690Dfsce6lExMSSYiIJOxTydjMpD0O8V2jQzvaWuMs4rpDHlfd IH2z3HTbyiIkXTOUxbuu5xL7czG5kuiTlqY22dVikyU2do7OUjqtUNInjxMy6pw8TzPDVuco GRcfTbjK4orDmvHcuuCjXKba93XpzWHrnVbXZbHtzlbUmvGZlXPRjHGw0lfMMT4fISQmhqVv YEA6HdqF1q4+GRgYzS6kfbYSSVNozCjtUG7XSPeMhT6zW6hqlNEMnXiaQdRhFK1ukpHuXBoN hzKjvS8jJ60sLmYCu9R6Msykc/bnYnKz6G4KyUwaCn1gl9SGQpmdSG3rDNkTnRlqjrbZNKKL jxTeY/IjFy5ycCnEMb8l5DJHflTJ2pUr2Xz/dwF44Ja1rFzZkiH26z9os6F+4pbKCwtrx/jV 00DNfazLCX4f2fsklfd9B6hh30vfojxN8Fd9M5UBYKyfjm6o2nw957r2AFDb2Ma+XS2EgO88 8RJ2/iCNw6+0A4vI93EB3k09aWbSOftzMbmZT6J07W0HtrCuIofAw4CFq1ZRWW2/PtY/4iSM AsIHeLRsM08DDbsG+OM1H7UjkC4uwIetrVy4+ChCj0zIxESPk3Rol4xGJjKmE5G0gzk0e4KZ iE0ol2ta6U7ntAg1ZPwO6euqGuzcEwNOwpuGPaOZnYND/eckUmqVhEjWH5Imz8vBu63nkvpz MbkZ9GQSPc2KiJPUydnJJAZ2OU776mlOdhcfbbg7CxcuZoG3qJTSYJxOYPPmjZQXlVJeGiDc u5dnn93OU892A/DKMzvpDRvTykaPvUI7sGllCQCDO79N1QNPABD6g+UceGYbz748CD4fRUD3 d55mx85tPHL/E0A9X/pk+p69nbZnd7P90a/zFFD/0F0EgHDXizwF1NbcSe555cup51L6c1G5 aBzYvZMd29voBBg+wLN7D6PISKGAAAABdklEQVQBh7c/ytZvb2P37md57MFv0IG9kykae5nP rryPdoCqzeSd/E+2bd/JyBXOAOrifcCHra1cuPjIQp+Qzj37ZCDn9r2rqXqGL2G6nV5EMilI m7vtgrvqZ5bJUn9Po6KuqpN96RDS0U77bt151LV0Ov6SdOrPC/0Vl1PPpfTnonJz0sVmHmmn eXv99OvrW2VYF4nkUJ1nH7OEALv4yMGlKHfh4kpDO8DW4C3Q3M3zD98w7+WGFiWhMwuvkYFm 81tnWF213h0ENz5AdeM+9n7rznfVrIvX8z7BoSifkyrdxW8NXGXhwoULFy7mheuzcOHChQsX 88JVFi5cuHDhYl64ysKFCxcuXMwLV1m4cOHChYt54SoLFy5cuHAxL1xl4cKFCxcu5oWrLFy4 cOHCxbxwlYULFy5cuJgXrrJw4cKFCxfzwlUWLly4cOFiXrjKwoULFy5czAtXWbhw4cKFi3nh KgsXLly4cDEvXGXhwoULFy7mxf8Hjr/QRiQ5puUAAAAASUVORK5CYII= --B_3427825151_10020701-- From david.waltermire@nist.gov Fri Aug 17 09:03:57 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 62A1511E80A5; Fri, 17 Aug 2012 09:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 Fd8GAVl46quI; Fri, 17 Aug 2012 09:03:56 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id EFE0921F852D; Fri, 17 Aug 2012 09:03:55 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 Aug 2012 12:03:12 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 17 Aug 2012 12:01:37 -0400 From: "Waltermire, David A." To: David Misell , Sean Turner Date: Fri, 17 Aug 2012 12:03:31 -0400 Thread-Topic: Re: [mile] IPR and Transfer Considerations Thread-Index: Ac11eHa/XXpvwEZjSw2lLT1nSZgzqAHGJtEg Message-ID: References: <1344032465.4236.17.camel@ubuntu> <50228291.1000002@ieca.com> In-Reply-To: <50228291.1000002@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mile@ietf.org" , "dennis.groves@owasp.org" , "sacm@ietf.org" , "Baker, Jon" Subject: Re: [sacm] [mile] IPR and Transfer Considerations X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 17 Aug 2012 16:03:57 -0000 DQpEYXZpZCwNCg0KTXkgYXBvbG9naWVzIGZvciBub3QgcmVzcG9uZGluZyB0byB0aGlzIGVhcmxp ZXIuDQoNCk5JU1Qgd291bGQgbGlrZSB0byBzdWJtaXQgSW50ZXJuZXQgRHJhZnRzIChJL0RzKSBm b3IgcmVsZXZhbnQgTklTVCBwdWJsaWNhdGlvbnMgdGhhdCBhcmUgaW4gc2NvcGUgd2l0aCB0aGUg TUlMRSBvciBTQUNNIGNoYXJ0ZXJzLiAgVGhlIE5JU1QgcHVibGljYXRpb25zIGFyZSBub3Qgc3Vi amVjdCB0byB0cmFkZW1hcmsgb3IgY29weXJpZ2h0IGlzc3Vlcy4gICAgQW55dGhpbmcgTklTVCBw dWJsaXNoZXMgaXMgYXZhaWxhYmxlIGluIHRoZSBwdWJsaWMgZG9tYWluIGFjY29yZGluZyB0byBU aXRsZSAxNyBvZiB0aGUgVW5pdGVkIFN0YXRlcyBDb2RlLiAgV2Ugd291bGQgYmUgaGFwcHkgdG8g c3VibWl0IGRpc2Nsb3N1cmVzIGZvciBhbnkgTklTVCBwdWJsaWNhdGlvbnMgdGhhdCB3b3VsZCBi ZSBuZWVkZWQgdG8gcmVpdGVyYXRlIHRoaXMuDQoNClRvIGFkZHJlc3MgdGhlIHNwZWNpZmljYXRp b24gcmVmZXJlbmNlIGNvbmNlcm4sIG9uZSBvcHRpb24gd291bGQgYmUgdG8gcHVibGlzaCBleGlz dGluZyBzcGVjaWZpY2F0aW9ucyBhcyBJRVRGIGluZGl2aWR1YWwgY29udHJpYnV0aW9ucy4gIEkg aGF2ZSBiZWVuIHRvbGQgdGhhdCBpdCBtYXkgYmUgcG9zc2libGUgdG8gcHVibGlzaCBhbiBpbmZv cm1hdGlvbmFsIFJGQyBiYXNlZCBvbiB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uIHJldmlzaW9u cy4gIFRoaXMgcHJvdmlkZXMgYSBtZWFucyB0byByZWZlcmVuY2UgdGhlIGluaXRpYWwgc3VibWlz c2lvbiB3aGlsZSBhbGxvd2luZyB0aGUgc3BlY2lmaWNhdGlvbiB0byBldm9sdmUgYXMgd2VsbC4N Cg0KSSBsb29rIGZvcndhcmQgdG8gd29ya2luZyB0aHJvdWdoIHRoZXNlIGlzc3VlcyBzbyB0aGF0 IHdlIGNhbiBmb2N1cyBiYWNrIG9uIHRoZSB0ZWNobmljYWwgd29yayBhdCBoYW5kLg0KDQpTaW5j ZXJlbHksDQpEYXZlDQoNCi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0NClN1Ympl Y3Q6IFJlOiBbbWlsZV0gSVBSIGFuZCBUcmFuc2ZlciBDb25zaWRlcmF0aW9ucw0KRGF0ZTogRnJp LCAwMyBBdWcgMjAxMiAyMjoyMTowNSArMDAwMA0KRnJvbTogRGF2aWQgTWlzZWxsIDxkYXZpZC5t aXNlbGxAYnRpbnRlcm5ldC5jb20+DQpSZXBseS1UbzogRGF2aWQuTWlzZWxsQGJjcy5vcmcNCk9y Z2FuaXphdGlvbjogQ3liZXJBd2FyZQ0KVG86IFNlYW4gVHVybmVyIDx0dXJuZXJzQGllY2EuY29t Pg0KQ0M6IEJha2VyLCBKb24gPGJha2VyakBtaXRyZS5vcmc+LCBtaWxlQGlldGYub3JnIDxtaWxl QGlldGYub3JnPiwgZGVubmlzLmdyb3Zlc0Bvd2FzcC5vcmcNCg0KU2VhbiwNCg0KSSBoYWQgYW4g aW4gZGVwdGggY29udmVyc2F0aW9uIGZvbGxvd2luZyB0aGUgY29uZmVybmNlIGNhbGwgYXQgd2hp Y2ggSSByZWFzaWVkIHNvbWVvZiB0aGVzZSBpc3N1ZXMuDQoNClRvIGJlIGZyYW5rIHRoZSBNSVRS RSBJUFIgaXMgYSBtYXJrZXRpbmcgY2FtcGFpZ24gc3VwcG9ydGluZyB0aGUgZm9sbG93aW5nIGJy YW5kZWQgVGVybXMgZnJvbXRoZSBDUEUgd2ViIHNpdGUgY3BlLm1pdHJlLm9yZzthcyB3aXRobmVz c2VkIGF0IHZhcmlvdXMgc2VjdWlydHkgaW5kdWN0cnkgZXZlbnQgc2luY2UgMjAwOS4NCg0KDQpH b2luZyBmb3J3YXJkIHZvbHVudGVlciBzZWN0b3IsIElFVEYgYW5kIE9XQVNQLCBCQ1MgYW5kIElF VCB3aWxsIGFsbCBoYXZlIHNpbWlsYXIgd29ya3MgaW4gcHJvZ3Jlc3MsIGFsc28gcG90ZW50aWFs bHkgaW4gc3VwcG9ydCBvZiBOSVNUIDgwMCBiZXN0IHByYWN0aXNlIHJlY29tbWVuZGF0aW9ucy4N Cg0KSWYgd2UgYXJlIHRvIHByb2dyZXNzIHRoaXMsIHRoZSBiZXN0IGZvcm1hdCBtYXkgYmUgdG8g YWRvcHQgY3JlYXRpdmUgY29tbW9ucywgcmVuYW1lIGFuZCBhdm9pZCB0aGUgZm9sbG93aW5nIGJy YW5kZWQgdGVybXMsIHVubGVzcyB0aGV5IGNhbiBiZSBpbiBzb21lIHdheSBvcGVuZWQgIHRvIG1v cmUgdGhhbiAiZnJlZSBmb3IgIHB1YmxpYyB1c2UiLCB3aGljaCB3b3VsZCBhbGxvdyBVUyBlbmZv cmNlbWVudCBvZiBJUFIgaW4gYSB1bmlsYXRlcmFsIHdheSwgYXMgaXMgY3VycmVudGx5IGJlaW5n IGxlZ2lzdGFsdGVkIGZvci4NCg0KDQpmb3IgZXhhbXBsZSBob3cgd291bGQgSSBiZSBhYmxlIHRv IHRyYWluIENWRSB0ZXJtcyBtaXJyb2VkIHRvIE5JU1QgODAwIHNlcmllcyBiZXN0IHByYWN0aWNl IHdpdGhvdXQgcGF5aW5nIE1JVFJFIGEgcm95YWx0eS4NCg0KDQoNCkNvbmZpZ3VyYXRpb25zIChD Q0UpDQoNClZ1bG5lcmFiaWxpdGllcyAoQ1ZFKQ0KDQpTb2Z0d2FyZSBXZWFrbmVzcyBUeXBlcyAo Q1dFKQ0KDQpBdHRhY2sgUGF0dGVybnMgKENBUEVDKQ0KDQpDeWJlciBPYnNlcnZhYmxlcyAoQ3li T1gpDQoNCkxvZyBGb3JtYXQgKENFRSkNCg0KDQpTb2Z0d2FyZSBJRCBUYWdzIChTV0lEcykNCg0K TWFsd2FyZSAoTUFFQykNCg0KQ2hlY2tsaXN0IExhbmd1YWdlIChYQ0NERikNCg0KQXNzZXNzbWVu dCBMYW5ndWFnZSAoT1ZBTCkNCg0KU2VjdXJpdHkgQ29udGVudCBBdXRvbWF0aW9uIChTQ0FQKQ0K DQpNYWtpbmcgU2VjdXJpdHkgTWVhc3VyYWJsZQ0KDQoNCldoYXQgYXNzdXJhbmNlIGNhbiB5b3Ug Z2l2ZSB0aGEgbm8gSVBSIHByb3RlY3Rpb24gd2lsbCBiZSBleGVydGVkIGF0IGFueSBwb2ludCBp biB0aGUgZnV0dXJlIG9uIGJlaGFsZiBvZiBNSVRSRSBieSBVUyBnb3Zlcm5tZW50LCBob3cgY2Fu IHdlIGFzc3VyZSBhIGNyZWF0aXZlIGNvbW1vbnMgc3R5bGUgYXBwcm9hY2guDQoNCllvdXJzIEZh aXRoZnVsbHksDQoNCkRhdmUNCg0KRGF2aWQgUyBNaXNlbGwgTVNjIChJbmZvcm1hdGlvbiBTZWN1 cml0eSBSSFVMKSBNQkNTIENJU1NQDQoNCg0KT24gRnJpLCAyMDEyLTA4LTAzIGF0IDExOjExIC0w NzAwLCBTZWFuIFR1cm5lciB3cm90ZToNCj4gT24gOC8zLzEyIDg6MjcgQU0sIEJha2VyLCBKb24g d3JvdGU6DQo+ID4gRHVyaW5nIHRoZSBNSUxFIFdHIHNlc3Npb24gdGhlcmUgd2VyZSBxdWVzdGlv bnMgcmFpc2VkIHJlbGF0ZWQgdG8gTUlUUkUgSVBSLiBJIHdvdWxkIGxpa2UgdG8gbWFrZSBzdXJl IHRoYXQgdGhlIGxpc3QgaXMgYXdhcmUgdGhhdCBNSVRSRSBoYXMgYWNjb21tb2RhdGVkIGFsbCBJ UFIgcmVsYXRlZCByZXF1ZXN0cyB0aGF0IGhhdmUgYmVlbiBtYWRlIGJ5IHRoaXMgZ3JvdXAuIFRo ZXJlIGFyZSB0aHJlZSBpc3N1ZXMgdGhhdCBoYXZlIGJlZW4gcmFpc2VkOg0KPiA+DQo+ID4gMS0g U2hvcnRseSBiZWZvcmUgdGhlIFBhcmlzIG1lZXRpbmcgKElFVEYgODMpIGEgY29uY2VybiB3YXMg cmFpc2VkIGFib3V0IHRoZSB3b3JkaW5nIGluIHRoZSBkaXNjbGFpbWVyIHBvcnRpb24gb2Ygb3Vy IHRlcm1zIG9mIHVzZSBwYWdlcyBub3QgYWxpZ25pbmcgd2VsbCB3aXRoIHRoZSB3b3JkaW5nIHRo YXQgdGhhdCBJRVRGIHVzZXMuIEF0IHRoYXQgdGltZSB3ZSBtYWRlIGEgc21hbGwgY2hhbmdlIHRv IHRoZSBkaXNjbGFpbWVyIGZvciBhbGwgdGhlIHJlbGV2YW50IGVmZm9ydHMgd2Ugc3VwcG9ydC4g VG8gdGhlIGJlc3Qgb2YgbXkga25vd2xlZGdlLCB0aGlzIGlzc3VlIHdhcyBhZGRyZXNzZWQuDQo+ ID4NCj4gPiAyLSBBdCB0aGUgUGFyaXMgbWVldGluZyBpdCB3YXMgY2xlYXIgdGhhdCB0aGVyZSB3 YXMgY29uZnVzaW9uIGFib3V0IHRoZSBsaWNlbnNpbmcgb2YgQ1ZFIGFuZCBzZXZlcmFsIG90aGVy IGVmZm9ydHMuIEkgd2FzIGFza2VkLCAiSG93IG11Y2ggZG9lcyBDVkUgY29zdD8iIFRoaXMgdG9v IGhhcyBiZWVuIGFkZHJlc3NlZC4gQ1ZFIGFuZCB0aGVzZSBvdGhlciBlZmZvcnRzIGFyZSBjbGVh cmx5IGZyZWUgdG8gdXNlLg0KPiA+DQo+ID4gMy0gTGFzdGx5LCBkdXJpbmcgdGhlIE1JTEUgV0cg c2Vzc2lvbiBUdWVzZGF5IG9mIHRoaXMgd2VlaywgaXQgd2FzIG1hZGUgY2xlYXIgdGhhdCBNSVRS RSBuZWVkcyB0byBwb3N0IElQUiBkaXNjbG9zdXJlcyBmb3IgYWxsIG9mIHRoZSByZWxldmFudCBl ZmZvcnRzIHRoYXQgTUlUUkUgc3VwcG9ydHMuIEFzIG9mIEF1Z3VzdCAyLCAyMDEyIElQUiBkaXNj bG9zdXJlcyBoYXZlIGJlZW4gc3VibWl0dGVkLiBJIGRvbid0IHRoaW5rIHRoZXkgaGF2ZSBiZWVu IHBvc3RlZCBieSB0aGUgSUVURiB5ZXQuDQo+DQo+IEkgY2hlY2tlZCB3aXRoIHRoZSBzZWNyZXRh cmlhdCBhbmQgdGhleSd2ZSBiZWVuIHN1Ym1pdHRlZC4gIFRoYW5rcy4NCj4NCj4gPiBBcmUgdGhl cmUgb3RoZXIgSVBSIGNvbmNlcm5zIHRoYXQgd2UgYXJlIG5vdCBhd2FyZSBvZj8NCj4NCj4gVGhp cyBpcyBoYXJkIHRvIGFuc3dlciB3aXRob3V0IGhhdmluZyBzZWVuIHRoZSBkaXNjbG9zdXJlLg0K Pg0KPiBNSUxFIFdHOiBXaGVuIHRoZXkncmUgcG9zdGVkIHJldmlldyB0aGVtLg0KPg0KPiBzcHQN Cj4NCj4gPiBUaGVyZSB3ZXJlIGFsc28gcXVlc3Rpb25zIHJhaXNlZCBhYm91dCBNSVRSRSdzIHdp bGxpbmduZXNzIHRvIHRyYW5zZmVyIElQUiB0byB0aGUgSUVURi4gSSBhdHRlbmRlZCB0aGUgUGFy aXMgbWVldGluZyAoSUVURiA4MykgYW5kIGR1cmluZyB0aGUgU0FDTSBzaWRlIG1lZXRpbmcgd2Fz IGdpdmVuIHRoZSBvcHBvcnR1bml0eSB0byBkaXNjdXNzIE1JVFJFJ3MgcGVyc3BlY3RpdmUgb24g dGhpcyB0b3BpYy4gQXQgdGhlIHRpbWUgSSB0YWxrZWQgdGhyb3VnaCB3aGF0IE1JVFJFIHNlZXMg YXMgdGhlIGtleSBkaXN0aW5jdGlvbnMgdG8gYmUgbWFkZSB3aGVuIGNvbnNpZGVyaW5nIHRyYW5z ZmVycmluZyBhIGdpdmVuIGVmZm9ydCB0byBhbnkgb3RoZXIgb3JnYW5pemF0aW9uLiBBcyBhIHJl bWluZGVyIEkgZGlzY3Vzc2VkIHRoZSBmb2xsb3dpbmc6DQo+ID4NCj4gPiBSRUdJU1RSSUVTIFZT LiBMQU5HVUFHRVMNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4g Um91Z2hseSBzcGVha2luZywgZWZmb3J0cyBjYW4gYmUgZ3JvdXBlZCBpbnRvIHR3byBwcmltYXJ5 IGNhdGVnb3JpZXM6IHJlZ2lzdHJpZXMgb2YgbmFtZWQgb2JqZWN0cyAoZS5nLiBDVkUpIGFuZCBs YW5ndWFnZXMgZm9yIGRlZmluaW5nIHN0cnVjdHVyZWQgY29udGVudCAoZS5nLiBPVkFMKS4gQXMg YSBydWxlLCBsYW5ndWFnZXMgYXJlIGdvb2QgY2FuZGlkYXRlcyB0byBnbyB0byBmb3JtYWwgc3Rh bmRhcmRzIGJvZGllcyBhcyB0aGV5IG1hdHVyZS4gSW4gY29udHJhc3QsIHdoaWxlIHJlZ2lzdHJp ZXMgbWF5IGJlIHJlZmVycmVkIHRvIGJ5IHRoZSB3b3JrIGRldmVsb3BlZCBpbiBzdGFuZGFyZHMg Ym9kaWVzIGFzIGV4dGVybmFsIGRlcGVuZGVuY2llczsgc3RhbmRhcmRzIGJvZGllcyBkbyBub3Qg dHlwaWNhbGx5IG9wZXJhdGUgcmVnaXN0cmllcy4NCj4gPg0KPiA+IEVGRk9SVFMgSEFWRSBNVUxU SVBMRSBTVUJDT01QT05FTlRTDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gUmVnaXN0cmllcyB0ZW5kIHRvIGhhdmUgdGhyZWUg cHJpbWFyeSBzdWItY29tcG9uZW50cywgaW5jbHVkaW5nOg0KPiA+ICAgICAgIGkpIHRoZSBzeW50 YXggb2YgdGhlIG5hbWVzcGFjZSwNCj4gPiAgICAgICBpaSkgdGhlIHJlZ2lzdHJ5IG9mIG9mZmlj aWFsbHkgcmVjb2duaXplZCBvYmplY3RzIGFuZA0KPiA+ICAgICAgIGlpaSkgZGVmaW5pdGlvbnMg b2YgYWNjZXB0YWJsZSB1c2UgKHdoaWNoIG1heSBpbmNsdWRlIHByb2R1Y3QgdGVzdGluZyByZXF1 aXJlbWVudHMpLg0KPiA+IExhbmd1YWdlcyB0ZW5kIHRvIGhhdmUgZm91ciBwcmltYXJ5IHN1Yi1j b21wb25lbnRzLCBpbmNsdWRpbmc6DQo+ID4gICAgICAgaSkgdGhlIHNwZWNpZmljYXRpb24gb2Yg dGhlIGxhbmd1YWdlLA0KPiA+ICAgICAgIGlpKSByZXBvc2l0b3JpZXMgb2YgY29udGVudCB3cml0 dGVuIGluIHRoYXQgbGFuZ3VhZ2UsDQo+ID4gICAgICAgaWlpKSBhIHJlZmVyZW5jZSBpbXBsZW1l bnRhdGlvbiB0aGF0IGNhbiBiZSB1c2VkIHRvIHZlcmlmeSBib3RoIHRoZSBsYW5ndWFnZSBhbmQg Y29udGVudCBhdXRob3JlZCBpbiB0aGUgbGFuZ3VhZ2UgYW5kDQo+ID4gICAgICAgaXYpIGRlZmlu aXRpb25zIG9mIGFjY2VwdGFibGUgdXNlICh3aGljaCBtYXkgaW5jbHVkZSBwcm9kdWN0IHRlc3Rp bmcgcmVxdWlyZW1lbnRzKS4NCj4gPiBUaGVzZSBjb21wb25lbnRzIG5lZWQgdG8gYmUgY29uc2lk ZXJlZCBzZXBhcmF0ZWx5Lg0KPiA+DQo+ID4gVVNHIEVGRk9SVFMgVlMuIE1JVFJFIE1BTkFHRUQg RUZGT1JUUw0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gPiBJbiBjb25zaWRlcmluZyB0aGUgdHJhbnNpdGlvbiBvZiBNSVRSRSBl ZmZvcnRzIHRvIHN0YW5kYXJkcyBib2RpZXMgYW5kIGhvdyB0aGVzZSBkZWNpc2lvbnMgd2lsbCBi ZSBtYWRlLCBpdCBpcyBpbXBvcnRhbnQgdG8gY2xlYXJseSBkaXN0aW5ndWlzaCBiZXR3ZWVuIFVT IEdvdmVybm1lbnQgKFVTRykgZWZmb3J0cyBhbmQgZWZmb3J0cyB0aGF0IG91ciBzcG9uc29ycyBo YXZlIGRpcmVjdGVkIE1JVFJFIHRvIG9wZXJhdGUgYXMgYSBuZXV0cmFsIDNyZCBwYXJ0eSB1bmRl ciBvdXIgRkZSREMgY2hhcnRlci4NCj4gPg0KPiA+DQo+ID4gQXMgeW91IG1pZ2h0IGltYWdpbmUg dGhpcyBsZWFkcyB0byBhIHNvcnQgb2YgbWF0cml4IHRoYXQgbXVzdCBiZSBjb25zaWRlcmVkIHRv IHVsdGltYXRlbHkgZW5zdXJlIHRoYXQgYSBzdWNjZXNzZnVsIGFuZCBhcHByb3ByaWF0ZSB0cmFu c2l0aW9uIGlzIG1hZGUgZm9yIGFueSBnaXZlbiBlZmZvcnQuIE91dHNpZGUgdGhlIE1JTEUgYW5k IFNBQ00gbGlzdHMgdGhlcmUgYXJlIG1hbnkgb3JnYW5pemF0aW9ucyB0aGF0IGRlcGVuZCB1cG9u IHRoZSBlZmZvcnRzIHRoYXQgTUlUUkUgaGFzIGxlZCBmb3IgbWFueSB5ZWFycywgaW4gc29tZSBj YXNlcyBpdCBpcyBzZXZlcmFsIGh1bmRyZWQgb3IgbW9yZS4gSW4gZmFjdCwgaXQgaXMgaGFyZCB0 byBpbWFnaW5lIGFuIElORk9TRUMgcHJvZmVzc2lvbmFsIGluIHRoZSBVUyB0aGF0IGhhcyBub3Qg dXNlZCBDVkUgKGVpdGhlciBkaXJlY3RseSBvciBpbmRpcmVjdGx5KSAgaW4gdGhlaXIgY2FyZWVy IGFuZCBDVkUgaXMgdHJhbnNsYXRpb25zIGFyZSBhdmFpbGFibGUgaW4gbWFueSBvdGhlciBsYW5n dWFnZXMgdG9vLiBNSVRSRSBoYXMgYSByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhlIHN0YWJp bGl0eSBvZiB0aGVzZSBlZmZvcnRzIGFuZCBub3QgbG9zZSBzaWdodCBvZiB0aGUgY29tbXVuaXR5 IHRoYXQgZGVwZW5kcyB1cG9uIHRoZW0gdG9kYXkuDQo+ID4NCj4gPiBSZXN0IGFzc3VyZWQgdGhh dCBNSVRSRSBhbmQgb3VyIHNwb25zb3JzIHZpZXcgc3VjY2Vzc2Z1bCB0cmFuc2ZlciBvZiBzdGFu ZGFyZHMgdG8gaW50ZXJuYXRpb25hbCBib2RpZXMgYXMgdGhlIHVsdGltYXRlIGdvYWwgb2YgbXVj aCBvZiBvdXIgc3RhbmRhcmRzIHdvcmsuIE1JVFJFIGlzIGFjdGl2ZWx5IGZvbGxvd2luZyB0aGUg TUlMRSBhbmQgU0FDTSBsaXN0cywgaGFzIHJhaXNlZCBhd2FyZW5lc3Mgb2YgdGhlIHJlbGV2YW50 IElFVEYgYWN0aXZpdGllcyBpbiB0aGUgZXhpc3Rpbmcgc3RhbmRhcmRzIHJlbGF0ZWQgZm9ydW1z IHRoYXQgd2UgaG9zdCwgYW5kIGlzIGFjdGl2ZWx5IGVuZ2FnaW5nIHdpdGggb3VyIHNwb25zb3Jz IG9uIHRoZSB0b3BpYyBvZiBpbnRlcm5hdGlvbmFsIHN0YW5kYXJkcy4NCj4gPg0KPiA+IFRoYW5r cywNCj4gPg0KPiA+IEpvbg0KPiA+DQo+ID4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCj4gPiBKb25hdGhhbiBPLiBCYWtlcg0KPiA+IEcwMjIgLSBJQSBJbmR1 c3RyeSBDb2xsYWJvcmF0aW9uDQo+ID4gVGhlIE1JVFJFIENvcnBvcmF0aW9uDQo+ID4gRW1haWw6 IGJha2VyakBtaXRyZS5vcmcNCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBtaWxlIG1haWxpbmcgbGlzdA0KPiA+IG1pbGVA aWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGUN Cj4gPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBtaWxlIG1haWxpbmcgbGlzdA0KPiBtaWxlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbWlsZQ0KDQotLQ0KS2luZCBSZWdhcmRzLA0KZGF2ZQ0KRGF2 aWQgUy4gTWlzZWxsLA0KMDc3MTAzODAwNDQNCg0KDQoNCg0K From david.waltermire@nist.gov Fri Aug 17 09:30:27 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B306111E80E1 for ; Fri, 17 Aug 2012 09:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 qquuGCUX9rJx for ; Fri, 17 Aug 2012 09:30:27 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 8176A11E80DC for ; Fri, 17 Aug 2012 09:30:26 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 Aug 2012 12:29:55 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 17 Aug 2012 12:30:03 -0400 From: "Waltermire, David A." To: Stephen Hanna , Adam Montville , Luis Nunez , Omar Santos Date: Fri, 17 Aug 2012 12:30:02 -0400 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwgAGFQsxA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 17 Aug 2012 16:30:27 -0000 Steve, These are all valid concerns that I completely agree with. What I am struggling with is insuring that the work we are embarking on remains relevant in the broader context. My fear is that if we narrow our thinking too much, we may inadvertently make decisions that drift from addressing the broader set of use cases. I like the idea of working on an individual draft to address the larger context. What I am not sure about is how introduce a feedback loop that would result in minimizing this kind of risk. I guess this type of issue is something that we will need to collectively monitor and address as needed. Sincerely, Dave -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net] Sent: Wednesday, August 15, 2012 3:55 PM To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos Cc: sacm@ietf.org Subject: RE: [sacm] Proposed use cases to move forward I love broad scope. Don't get me wrong! But I'm concerned about having a use cases document and an architecture document for this working group that goes way beyond the charter and initial scope for the group. I'm concerned that this will lead to lots of discussions on the sacm list and lots of effort being spent on topics that are out of scope, diverting us from the tasks at hand and slowing our progress. I'm concerned that the working group chairs won't be able to cut off discussion of topics by saying they're out of scope for the working group. I'm concerned that we'll get sidetracked or even derailed by controversies that aren't relevant to the scope of the group. I'm concerned that by including all of security automation within our use cases and architecture, we may actually prevent the formation of other working groups that could work on those other use cases. We have plenty of work to keep us busy for years with UC1 and UC3. There's agreement that the technology needed is mature enough for IETF standardization. I suggest that we scope this working group to address only those use cases and that our use cases and architecture be limited to them. I'm sorely tempted to create an ambitious architecture for security automation that encompasses all of the use cases that we have described so far and maybe more. I understand that people have a hard time understanding how the NEA and MILE and SACM standards fit together and I would love to address that in an IETF RFC. But I have seen several grand architecture efforts die or come to nothing in IETF. IETF is filled with smart engineers with clever ideas. We're great at solving problems but if we can't agree on the problem to solve or if we choose the wrong problem, we can easily spin an intricate and pointless web. I think we'll do better if we scope our effort properly. Maybe a few people can create an individual submission describing a grand architecture and roadmap for security automation and ask people in SACM to review and provide feedback on that document. That would be a good way to get a grand architecture while still ensuring that the SACM effort keeps its focus. In IETF as in so many things, you must keep your focus or you'll never succeed. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of Waltermire, David A. > Sent: Wednesday, August 15, 2012 1:13 PM > To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos > Cc: sacm@ietf.org > Subject: Re: [sacm] Proposed use cases to move forward > > +1 on scoping the charter to UC1 and UC3. > > I think we are better served with a use cases document, and eventually > an architecture documemnt, that is broader scoped. Both of these > documents will help inform the work we will do under the charter as it > relates to the larger context. > > To this end I would suggest we focus on expanding the use case > document primarily in the areas of UC1 and UC3 for now. We can expand > the other use cases later. > > Sincerely, > Dave > > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of > > Stephen Hanna > > Sent: Wednesday, August 15, 2012 11:24 AM > > To: Adam Montville; Luis Nunez; Omar Santos > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Proposed use cases to move forward > > > > I agree. Let's work on UC1 and UC3. The other use cases are valuable > > but just doing UC1 and UC3 is plenty of work for this group for the > > next year or two (maybe five!). > > > > I saw several emails in favor of this a few weeks ago. I thought > > that it was settled. I'd like to see a revised charter and use case > > document, scoped down to focus on just UC1 and UC3. > > > > What do others think? Do we have rough consensus on this? > > If so, let's get moving. > > > > Thanks, > > > > Steve > > > > > -----Original Message----- > > > From: Adam Montville [mailto:amontville@tripwire.com] > > > Sent: Wednesday, August 15, 2012 10:30 AM > > > To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos > > > Cc: sacm@ietf.org > > > Subject: Re: [sacm] Proposed use cases to move forward > > > > > > On 8/6/12 7:27 AM, "Adam Montville" > wrote: > > > > > > > > > > > > > > >UC1 and UC3 both require assessment of endpoint state. If not for > > the > > > NEA > > > >ties in UC1, it seems a subset of UC3. So, we should be able to > > > >start with the main concern of UC3: Security Configuration > > Management. > > > > > > > > > > > > > > > > > I haven't seen much activity on this thread (there was another > > thread, > > > "Using the Frame of Reference," discussing some approaches we can > use > > > to keep us focused and meaningful). > > > > > > Are there any objections to tackling UC3 followed by UC1? Does > > anyone > > > disagree with my assertion that UC3 is a subset of UC1 and that a > > > reasonable starting point is Security Configuration Management? > > > > > > > _______________________________________________ > > sacm mailing 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 Fri Aug 17 10:34:01 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A09511E809B for ; Fri, 17 Aug 2012 10:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.934 X-Spam-Level: X-Spam-Status: No, score=-3.934 tagged_above=-999 required=5 tests=[AWL=-0.335, 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 er-E2zgympUL for ; Fri, 17 Aug 2012 10:34:00 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5B59D11E80A5 for ; Fri, 17 Aug 2012 10:34:00 -0700 (PDT) Received: from mail131-ch1-R.bigfish.com (10.43.68.239) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Fri, 17 Aug 2012 17:33:59 +0000 Received: from mail131-ch1 (localhost [127.0.0.1]) by mail131-ch1-R.bigfish.com (Postfix) with ESMTP id 90873100069; Fri, 17 Aug 2012 17:33:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -35 X-BigFish: VPS-35(zzbb2dI98dI9371I1503M542M1432I4015Izz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail131-ch1 (localhost.localdomain [127.0.0.1]) by mail131-ch1 (MessageSwitch) id 1345224837988343_20753; Fri, 17 Aug 2012 17:33:57 +0000 (UTC) Received: from CH1EHSMHS020.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail131-ch1.bigfish.com (Postfix) with ESMTP id E4F0B160045; Fri, 17 Aug 2012 17:33:57 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by CH1EHSMHS020.bigfish.com (10.43.70.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 17 Aug 2012 17:33:57 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 Aug 2012 10:35:43 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Fri, 17 Aug 2012 10:33:55 -0700 From: Adam Montville To: "Waltermire, David A." , Stephen Hanna , Luis Nunez , Omar Santos Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwgAGFQsxAAAviVgA== Date: Fri, 17 Aug 2012 17:33:55 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <262EF354E8F93549850336AB42065F43@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 17 Aug 2012 17:34:01 -0000 I like taking the scope down as well - and I think we all believe we've agreed to UC1 and UC3. I don't have an issue having the other use cases (2, 4, and 5) described in the use case document, but not fleshed out in the functional capabilities, components, and data/protocol sections. The charter can be derived from the use cases we take on, and a separate informational document can help place those use cases in the right context with respect to the "grand scheme of things." No matter how we slice it, right now we need to focus on the use cases and charter, and to focus on the use cases we would ideally need to work on setting the context. I've tried to do that (to a limited extent) with the informational document I sent to the list. Additionally, I think these efforts need to be done in parallel irrespective of any idealistic dependencies. For example, we should be able to work on a charter, a use case doc, and an informational doc all at the same time, but join the threads for a final alignment pass before submitting them. Adam On 8/17/12 9:30 AM, "Waltermire, David A." wrote: >Steve, > >These are all valid concerns that I completely agree with. What I am >struggling with is insuring that the work we are embarking on remains >relevant in the broader context. My fear is that if we narrow our >thinking too much, we may inadvertently make decisions that drift from >addressing the broader set of use cases. I like the idea of working on >an individual draft to address the larger context. What I am not sure >about is how introduce a feedback loop that would result in minimizing >this kind of risk. I guess this type of issue is something that we will >need to collectively monitor and address as needed. > >Sincerely, >Dave > > >-----Original Message----- >From: Stephen Hanna [mailto:shanna@juniper.net] >Sent: Wednesday, August 15, 2012 3:55 PM >To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos >Cc: sacm@ietf.org >Subject: RE: [sacm] Proposed use cases to move forward > >I love broad scope. Don't get me wrong! But I'm concerned about having a >use cases document and an architecture document for this working group >that goes way beyond the charter and initial scope for the group. > >I'm concerned that this will lead to lots of discussions on the sacm list >and lots of effort being spent on topics that are out of scope, diverting >us from the tasks at hand and slowing our progress. > >I'm concerned that the working group chairs won't be able to cut off >discussion of topics by saying they're out of scope for the working group. > >I'm concerned that we'll get sidetracked or even derailed by >controversies that aren't relevant to the scope of the group. > >I'm concerned that by including all of security automation within our use >cases and architecture, we may actually prevent the formation of other >working groups that could work on those other use cases. > >We have plenty of work to keep us busy for years with UC1 and UC3. >There's agreement that the technology needed is mature enough for IETF >standardization. I suggest that we scope this working group to address >only those use cases and that our use cases and architecture be limited >to them. > >I'm sorely tempted to create an ambitious architecture for security >automation that encompasses all of the use cases that we have described >so far and maybe more. I understand that people have a hard time >understanding how the NEA and MILE and SACM standards fit together and I >would love to address that in an IETF RFC. But I have seen several grand >architecture efforts die or come to nothing in IETF. IETF is filled with >smart engineers with clever ideas. We're great at solving problems but if >we can't agree on the problem to solve or if we choose the wrong problem, >we can easily spin an intricate and pointless web. > >I think we'll do better if we scope our effort properly. > >Maybe a few people can create an individual submission describing a grand >architecture and roadmap for security automation and ask people in SACM >to review and provide feedback on that document. That would be a good way >to get a grand architecture while still ensuring that the SACM effort >keeps its focus. In IETF as in so many things, you must keep your focus >or you'll never succeed. > >Thanks, > >Steve > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >> Of Waltermire, David A. >> Sent: Wednesday, August 15, 2012 1:13 PM >> To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos >> Cc: sacm@ietf.org >> Subject: Re: [sacm] Proposed use cases to move forward >>=20 >> +1 on scoping the charter to UC1 and UC3. >>=20 >> I think we are better served with a use cases document, and eventually >> an architecture documemnt, that is broader scoped. Both of these >> documents will help inform the work we will do under the charter as it >> relates to the larger context. >>=20 >> To this end I would suggest we focus on expanding the use case >> document primarily in the areas of UC1 and UC3 for now. We can expand >> the other use cases later. >>=20 >> Sincerely, >> Dave >>=20 >> > -----Original Message----- >> > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >> Of >> > Stephen Hanna >> > Sent: Wednesday, August 15, 2012 11:24 AM >> > To: Adam Montville; Luis Nunez; Omar Santos >> > Cc: sacm@ietf.org >> > Subject: Re: [sacm] Proposed use cases to move forward >> > >> > I agree. Let's work on UC1 and UC3. The other use cases are valuable >> > but just doing UC1 and UC3 is plenty of work for this group for the >> > next year or two (maybe five!). >> > >> > I saw several emails in favor of this a few weeks ago. I thought >> > that it was settled. I'd like to see a revised charter and use case >> > document, scoped down to focus on just UC1 and UC3. >> > >> > What do others think? Do we have rough consensus on this? >> > If so, let's get moving. >> > >> > Thanks, >> > >> > Steve >> > >> > > -----Original Message----- >> > > From: Adam Montville [mailto:amontville@tripwire.com] >> > > Sent: Wednesday, August 15, 2012 10:30 AM >> > > To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos >> > > Cc: sacm@ietf.org >> > > Subject: Re: [sacm] Proposed use cases to move forward >> > > >> > > On 8/6/12 7:27 AM, "Adam Montville" >> wrote: >> > > >> > > > >> > > > >> > > >UC1 and UC3 both require assessment of endpoint state. If not for >> > the >> > > NEA >> > > >ties in UC1, it seems a subset of UC3. So, we should be able to >> > > >start with the main concern of UC3: Security Configuration >> > Management. >> > > > >> > > > >> > > >> > > >> > > I haven't seen much activity on this thread (there was another >> > thread, >> > > "Using the Frame of Reference," discussing some approaches we can >> use >> > > to keep us focused and meaningful). >> > > >> > > Are there any objections to tackling UC3 followed by UC1? Does >> > anyone >> > > disagree with my assertion that UC3 is a subset of UC1 and that a >> > > reasonable starting point is Security Configuration Management? >> > > >> > >> > _______________________________________________ >> > sacm mailing 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 dcougias@netfrontiers.com Mon Aug 20 09:02:49 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBCB21F8543 for ; Mon, 20 Aug 2012 09:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.951 X-Spam-Level: X-Spam-Status: No, score=-2.951 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 x7dm3hs0adQW for ; Mon, 20 Aug 2012 09:02:49 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D82A421F8528 for ; Mon, 20 Aug 2012 09:02:45 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5703014ghb.31 for ; Mon, 20 Aug 2012 09:02:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:reply-to:to:message-id:subject:mime-version:content-type :x-priority:user-agent:x-mailer:x-zohomail-sender:x-gm-message-state; bh=ALOYkl4qhTYee7d3RHo7PAa6yFmGGf5qTWSjKgdxAcE=; b=ifXfjHJGAWopw3stMt9BLqyROWjy0W7uc0OcvQDGorkHoLCM+FLHczWXOndTWslsPT N7QgZd5SSFd0fQe+1nZm4qS/hLLL6i2sZLi/xLILoxFqKQAWOnlLDqCbNNrdARrc9m4p gLqJRZPB77bKEWopPi0uCj2R84uuKxUjApb/DrgRCftyhAub+KrHMxiXNQnFaH81NB8l GfdjL01m/Ycy1jlUrOptHZLZagwmoVh1U8gyuSoZvnb7Baj5wPi5/aj2a2Y4O9mmKiZ5 QqtKVyFn7shZj5ZFeM4Ox8dVcr2+k/m2jxpExTizobaO6QPTWn0aOHQgQKsDyt6c+MAi ZUCg== Received: by 10.68.226.167 with SMTP id rt7mr35171752pbc.146.1345478564518; Mon, 20 Aug 2012 09:02:44 -0700 (PDT) Received: from mail.zoho.com (sender1.zohomail.com. [72.5.230.103]) by mx.google.com with ESMTPS id tv2sm3555252pbc.25.2012.08.20.09.02.42 (version=SSLv3 cipher=OTHER); Mon, 20 Aug 2012 09:02:43 -0700 (PDT) Date: Mon, 20 Aug 2012 09:02:41 -0700 From: Dorian Cougias To: Message-ID: <13944c58ec8.6060514636934045424.3597909173785290824@netfrontiers.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_322547_1336514218.1345478561479" X-Priority: MEDIUM User-Agent: Zoho Mail X-Mailer: Zoho Mail X-ZohoMail-Sender: 173.11.102.17 X-Gm-Message-State: ALoCoQldvWgmDIMqVyXFo+tq++VxIqHYY8iwGAgBTWvnMNFrcqyym25wCORfWs2kjJuNlKdkq3Ss Subject: [sacm] UCF Spreadsheets available for this group to use for research purposes X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcougias@netfrontiers.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 16:02:50 -0000 ------=_Part_322547_1336514218.1345478561479 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit About a week ago, we offered anyone on this list free access to the UCF's spreadsheets and other research materials. The process for getting the materials (so that you get regular updates) is as follows: Sign up for a free account at www.unifiedcompliance.com e-mail Craig Isaacs (cisaacs@unifiedcompliance.com) the mail address you used when you signed up and let him know you are a part of the SACM group. That's it. --Additional tools in development: "Did you mean..." phrase checker <https://dev.unifiedcompliance.com/phraseChecking/> Hierarchical term browser <https://dev.unifiedcompliance.com/glossary/Glossary_OH.html#> Dorian J. Cougias Compliance Scientist Unified Compliance Framework ------=_Part_322547_1336514218.1345478561479 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
About a week ago, we offered anyone on this list free access = to the UCF's spreadsheets and other research materials.

= The process for getting the materials (so that you get regular updates) is = as follows:

Sign up for a free account at www.unif= iedcompliance.com

e-mail Craig Isaacs (cisaacs@unifiedcomp= liance.com) the mail address you used when you signed up and let him kn= ow you are a part of the SACM group.

That's it.

--Additional tools in development:

"Did you mean..." phrase checker <https://dev.unifiedcompli= ance.com/phraseChecking/>

Hierarchical term= browser <https://dev.unifiedcompliance.com/glossary/Glo= ssary_OH.html#>



Dorian J. Cougias
Compliance Scientist
Unified = Compliance Framework      
<= /div>
------=_Part_322547_1336514218.1345478561479-- From dcougias@netfrontiers.com Mon Aug 20 10:21: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 01EC721F8698 for ; Mon, 20 Aug 2012 10:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[AWL=0.447, 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 J4cCWFGoNPMM for ; Mon, 20 Aug 2012 10:21:36 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8510021F8616 for ; Mon, 20 Aug 2012 10:21:36 -0700 (PDT) Received: by dakr19 with SMTP id r19so2485476dak.31 for ; Mon, 20 Aug 2012 10:21:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:reply-to:to:message-id:subject:mime-version:content-type :x-priority:user-agent:x-mailer:x-zohomail-sender:x-gm-message-state; bh=vgDh7Ib/UgXsBt4gx9/5GItmBS7E/m6w/EkNoGFXI6Y=; b=YrF+pdOLACI0c1BjoYssOhg9NL4VBq4Tcj2fjP4OYli653Ee9SARt6Eux6P4CwgvVO sd+peOUxsLByPjqpUCPbxHSCkVr7B+7jjdJoPk7+ywxCvcQ7NZancl9dB9Ps4yKpiZLz vJlYhoTsMHq5zDMLBsH91uE4gALVZLEH9Cd31HoVAgN25L/tjVpjdxq4Np2yUvpAVWNQ MuCs4hvrWa0N8YyKm7p9GHB8W4n72viD4/Z414zOpbA3aMJMOtK3SQi8J6Fve8kXGcj4 nl+zgKPNr0ri1N8Q9xGInZ42C4WiPJYkZgmOWKg2aTsGyu6G5ayFTtCDBbFJeVyd9vSS q87w== Received: by 10.66.75.73 with SMTP id a9mr14483236paw.43.1345483295999; Mon, 20 Aug 2012 10:21:35 -0700 (PDT) Received: from mail.zoho.com (sender1.zohomail.com. [72.5.230.103]) by mx.google.com with ESMTPS id pg9sm11473902pbb.26.2012.08.20.10.21.34 (version=SSLv3 cipher=OTHER); Mon, 20 Aug 2012 10:21:35 -0700 (PDT) Date: Mon, 20 Aug 2012 10:21:33 -0700 From: Dorian Cougias To: "sacm" Message-ID: <139450dc2a8.-8712402447283240102.-5973727734786149318@netfrontiers.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_337942_1882399172.1345483293351" X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-ZohoMail-Sender: 173.11.102.17 X-Gm-Message-State: ALoCoQmcvdh4coXHI/Yf52f+FU5yLtkBulB5Avn0qx3z2uhB/vpUzKbqtsDkAaiDUiao36zfEkL4 Subject: [sacm] Change on whom to notify X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcougias@netfrontiers.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 17:21:37 -0000 ------=_Part_337942_1882399172.1345483293351 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Please e-mail sales@unifiedcompliance.com and let them know you are a part of the SACM list. Dorian J. Cougias Compliance Scientist Unified Compliance Framework ------=_Part_337942_1882399172.1345483293351 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit
Please e-mail sales@unifiedcompliance.com and let them know you are a part of the SACM list.


Dorian J. Cougias
Compliance Scientist
Unified Compliance Framework
------=_Part_337942_1882399172.1345483293351-- From Kent_Landfield@mcafee.com Mon Aug 20 12:59:25 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4798511E808A for ; Mon, 20 Aug 2012 12:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.63 X-Spam-Level: X-Spam-Status: No, score=-5.63 tagged_above=-999 required=5 tests=[AWL=-0.891, BAYES_20=-0.74, 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 lTEf5f+mgOxZ for ; Mon, 20 Aug 2012 12:59:23 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id F0C3821F84A0 for ; Mon, 20 Aug 2012 12:59:22 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 4e29_3fe4_80c4bbac_dbaa_46dd_a03f_152b8a92796c; Mon, 20 Aug 2012 14:59:21 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Mon, 20 Aug 2012 14:58:33 -0500 From: To: Date: Mon, 20 Aug 2012 14:59:36 -0500 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1/Di05WE4H3VKuQbKX+8ZBRWr2bA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC57D86A3A8C3kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 19:59:25 -0000 --_000_CC57D86A3A8C3kentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes, I agree we need to focus. It appears we have consensus on working on U= C1 and UC3. The use case document as it exists is very broad and its inten= t has expanded a great deal from the initial meeting in Paris. ;-) It is time to focus on the charter and what it is we want this working grou= p to do. We need to put a reasonable box around the effort so we can be pro= ductive. To that end, what follows is an updated version of the charter that was pos= ted just prior to the Vancouver meeting. It has taken into consideration r= equests made on the lists. Let's start discussing it as is. I know there a= re some good suggestions that I have not gotten to incorporate yet. One question that I did have is the draft charter talks about remediation. = What are other's thoughts on including that as a 'potential' for the work = to be done under SACM? Please take a look at it and let's talk about what is here. We will need t= o develop the list of deliverables and the milestones we expect to meet but= that will hopefully be driven by the base charter discussions. As a point of reference, how does the list want to see differences from one= version of the charter to the next? Let's keep it simple if possible=85 --------------------------------- Security Automation Continuous Monitoring (SACM) Proposed Working Group Charter Chairs: TBD TBD Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm Description of Working Group Securing information and the systems that store, process, and transmit that= information has become a challenging task for organizations of all sizes, = and we find that security practitioners spend most of their time on manual = processes relegating them to ineffectiveness. Security automation is the ke= y to escaping this rut. This working group will develop security automation= standards in support of information security processes and practices where= practical. These standards will support security practitioners to be bette= r utilized within their organizations by allowing them to meet the more adv= anced needs of the security community (e.g. information sharing, continuous= monitoring, remediation and response, result aggregation and analysis). Th= e initial focus of this work is to address enterprise and SOHO use cases. T= he working group will achieve this by consuming and continuing (with cooper= ation) the security automation work already performed by various organizati= ons around the world. The initial work has been fruitful, and the data formats previously publish= ed are ready for expansion on the international stage. Of particular intere= st to this working group are the security automation specifications support= ing asset, change, configuration, and vulnerability management. Of addition= al interest to this working group are the emerging security automation inte= rfaces and data formats relating to event management and continuous monitor= ing. By undertaking this work, we recognize that there are multiple categories o= f problems in the security automation domain: defining expressions for part= icular domain concepts (i.e. data formats), establishing a standards-based = foundation supporting the curation and exchange of security automation cont= ent collections in content repositories and enabling interoperability throu= gh the development and use of interfaces and communications protocols. Cont= ent based on rich data standards and protocols will provide the authoritati= ve instructions needed by data-driven tools to enable the automated collect= ion and exchange of configuration and vulnerability data pertaining to ente= rprise assets. Information produced by these tools will provide accurate an= d timely situational awareness in support of organizational decision making= . This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used for the purpose of assessing, aggregating and com= paring device states against expected values, and reporting on those result= s in a predefined or ad hoc manner. 2. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used to continuously monitor and report on the state o= f systems, composed of many different types of devices and networks, operat= ed by varying personnel, to ensure security process effectiveness in a pre-= defined or ad-hoc manner. 3. Create relationships between existing operations management standards to= enable a comprehensive view of security automation, leveraging existing wo= rk and implementations. This working group will produce the following: * An Informational document providing an overview of security automation an= d continuous monitoring to include a reference model * A Standards Track document specifying benchmark configuration representat= ion (XCCDF) * An Informational document stating guidelines / requirements for specifyin= g checking languages * Standards Track documents specifying device state checking languages (OVA= L, ECL, ACEML, =85) * A Standards Track document specifying an interrogative checking language = (OCIL) * A Standards Track document specifying platform naming, matching and appli= cability (CPE) * Standards Track documents specifying asset identification and reporting i= nformation (Asset ID, ARF) * Standards Track documents specifying interfaces and communication protoco= ls used for security automation and continuous monitoring * A Standards Track document describing the messages and network protocols = for distributing Security Automation Content (content repository) * Standards Track document describing integrating security automation and N= etwork Endpoint Assessment capabilities (if-m for SCAP?) * A Standards Track document describing protocols and data formats for secu= rely sharing dynamic network state information among security systems (if-m= ap) Goals and Milestones TBD -------------------------------------------- Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville > Date: Friday, August 17, 2012 12:33 PM To: David Waltermire >, Stephen Hanna >, Lui= s Nunez >, Omar Santo= s > Cc: "sacm@ietf.org" > Subject: Re: [sacm] Proposed use cases to move forward I like taking the scope down as well - and I think we all believe we've agreed to UC1 and UC3. I don't have an issue having the other use cases (2, 4, and 5) described in the use case document, but not fleshed out in the functional capabilities, components, and data/protocol sections. The charter can be derived from the use cases we take on, and a separate informational document can help place those use cases in the right context with respect to the "grand scheme of things." No matter how we slice it, right now we need to focus on the use cases and charter, and to focus on the use cases we would ideally need to work on setting the context. I've tried to do that (to a limited extent) with the informational document I sent to the list. Additionally, I think these efforts need to be done in parallel irrespective of any idealistic dependencies. For example, we should be able to work on a charter, a use case doc, and an informational doc all at the same time, but join the threads for a final alignment pass before submitting them. Adam On 8/17/12 9:30 AM, "Waltermire, David A." > wrote: Steve, These are all valid concerns that I completely agree with. What I am struggling with is insuring that the work we are embarking on remains relevant in the broader context. My fear is that if we narrow our thinking too much, we may inadvertently make decisions that drift from addressing the broader set of use cases. I like the idea of working on an individual draft to address the larger context. What I am not sure about is how introduce a feedback loop that would result in minimizing this kind of risk. I guess this type of issue is something that we will need to collectively monitor and address as needed. Sincerely, Dave -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net] Sent: Wednesday, August 15, 2012 3:55 PM To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos Cc: sacm@ietf.org Subject: RE: [sacm] Proposed use cases to move forward I love broad scope. Don't get me wrong! But I'm concerned about having a use cases document and an architecture document for this working group that goes way beyond the charter and initial scope for the group. I'm concerned that this will lead to lots of discussions on the sacm list and lots of effort being spent on topics that are out of scope, diverting us from the tasks at hand and slowing our progress. I'm concerned that the working group chairs won't be able to cut off discussion of topics by saying they're out of scope for the working group. I'm concerned that we'll get sidetracked or even derailed by controversies that aren't relevant to the scope of the group. I'm concerned that by including all of security automation within our use cases and architecture, we may actually prevent the formation of other working groups that could work on those other use cases. We have plenty of work to keep us busy for years with UC1 and UC3. There's agreement that the technology needed is mature enough for IETF standardization. I suggest that we scope this working group to address only those use cases and that our use cases and architecture be limited to them. I'm sorely tempted to create an ambitious architecture for security automation that encompasses all of the use cases that we have described so far and maybe more. I understand that people have a hard time understanding how the NEA and MILE and SACM standards fit together and I would love to address that in an IETF RFC. But I have seen several grand architecture efforts die or come to nothing in IETF. IETF is filled with smart engineers with clever ideas. We're great at solving problems but if we can't agree on the problem to solve or if we choose the wrong problem, we can easily spin an intricate and pointless web. I think we'll do better if we scope our effort properly. Maybe a few people can create an individual submission describing a grand architecture and roadmap for security automation and ask people in SACM to review and provide feedback on that document. That would be a good way to get a grand architecture while still ensuring that the SACM effort keeps its focus. In IETF as in so many things, you must keep your focus or you'll never succeed. Thanks, Steve -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Waltermire, David A. Sent: Wednesday, August 15, 2012 1:13 PM To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos Cc: sacm@ietf.org Subject: Re: [sacm] Proposed use cases to move forward +1 on scoping the charter to UC1 and UC3. I think we are better served with a use cases document, and eventually an architecture documemnt, that is broader scoped. Both of these documents will help inform the work we will do under the charter as it relates to the larger context. To this end I would suggest we focus on expanding the use case document primarily in the areas of UC1 and UC3 for now. We can expand the other use cases later. Sincerely, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bo= unces@ietf.org] On Behalf Of > Stephen Hanna > Sent: Wednesday, August 15, 2012 11:24 AM > To: Adam Montville; Luis Nunez; Omar Santos > Cc: sacm@ietf.org > Subject: Re: [sacm] Proposed use cases to move forward > > I agree. Let's work on UC1 and UC3. The other use cases are valuable > but just doing UC1 and UC3 is plenty of work for this group for the > next year or two (maybe five!). > > I saw several emails in favor of this a few weeks ago. I thought > that it was settled. I'd like to see a revised charter and use case > document, scoped down to focus on just UC1 and UC3. > > What do others think? Do we have rough consensus on this? > If so, let's get moving. > > Thanks, > > Steve > > > -----Original Message----- > > From: Adam Montville [mailto:amontville@tripwire.com] > > Sent: Wednesday, August 15, 2012 10:30 AM > > To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Proposed use cases to move forward > > > > On 8/6/12 7:27 AM, "Adam Montville" > wrote: > > > > > > > > > > >UC1 and UC3 both require assessment of endpoint state. If not for > the > > NEA > > >ties in UC1, it seems a subset of UC3. So, we should be able to > > >start with the main concern of UC3: Security Configuration > Management. > > > > > > > > > > > > I haven't seen much activity on this thread (there was another > thread, > > "Using the Frame of Reference," discussing some approaches we can use > > to keep us focused and meaningful). > > > > Are there any objections to tackling UC3 followed by UC1? Does > anyone > > disagree with my assertion that UC3 is a subset of UC1 and that a > > reasonable starting point is Security Configuration Management? > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_CC57D86A3A8C3kentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Yes, I agre= e we need to focus. It appears we have consensus on working on UC1 and UC3.=  The use case document as it exists is very broad and its intent has = expanded a great deal from the initial meeting in Paris. ;-)

=
It is time to focus on the charter and what it is we want this w= orking group to do. We need to put a reasonable box around the effort so we= can be productive.

To that end, what follows is a= n updated version of the charter that was posted just prior to the Vancouve= r meeting.  It has taken into consideration requests made on the lists= .  Let's start discussing it as is. I know there are some good suggest= ions that I have not gotten to incorporate yet.

On= e question that I did have is the draft charter talks about remediation. &n= bsp;What are other's thoughts on including that as a 'potential' for the wo= rk to be done under SACM?

Please take a look at it= and let's talk about what is here.  We will need to develop the list = of deliverables and the milestones we expect to meet but that will hopefull= y be driven by the base charter discussions.

As a = point of reference, how does the list want to see differences from one vers= ion of the charter to the next?  Let's keep it simple if possible=85

---------------------------------
Se= curity Automation Continuous Monitoring (SACM)

Pro= posed Working Group Charter

Chairs:
TBD<= /div>
TBD

Security Area Directors:
&= nbsp;    Stephen Farrell <stephen.farrell@cs.tcd.ie>
<= div>     Sean Turner <turners@ieca.com>

=
Security Area Advisor:
     Sean Turner= <turners@ieca.com>

Mailing Lists:
     General Discussion: sacm@ietf.org
  &nb= sp;  To Subscribe:           http://www.ietf.= org/mailman/listinfo/sacm
     Archive:   &nb= sp;            http://www.ietf.org/mail-archi= ve/web/sacm

Description of Working Group

Securing information and the systems that store, process, a= nd transmit that information has become a challenging task for organization= s of all sizes, and we find that security practitioners spend most of their= time on manual processes relegating them to ineffectiveness. Security auto= mation is the key to escaping this rut. This working group will develop sec= urity automation standards in support of information security processes and= practices where practical. These standards will support security practitio= ners to be better utilized within their organizations by allowing them to m= eet the more advanced needs of the security community (e.g. information sha= ring, continuous monitoring, remediation and response, result aggregation a= nd analysis). The initial focus of this work is to address enterprise and S= OHO use cases. The working group will achieve this by consuming and continu= ing (with cooperation) the security automation work already performed by va= rious organizations around the world.

The initial = work has been fruitful, and the data formats previously published are ready= for expansion on the international stage. Of particular interest to this w= orking group are the security automation specifications supporting asset, c= hange, configuration, and vulnerability management. Of additional interest = to this working group are the emerging security automation interfaces and d= ata formats relating to event management and continuous monitoring.

By undertaking this work, we recognize that there are mul= tiple categories of problems in the security automation domain: defining ex= pressions for particular domain concepts (i.e. data formats), establishing = a standards-based foundation supporting the curation and exchange of securi= ty automation content collections in content repositories and enabling inte= roperability through the development and use of interfaces and communicatio= ns protocols. Content based on rich data standards and protocols will provi= de the authoritative instructions needed by data-driven tools to enable the= automated collection and exchange of configuration and vulnerability data = pertaining to enterprise assets. Information produced by these tools will p= rovide accurate and timely situational awareness in support of organization= al decision making. 

This working group will = provide solutions to these categories of problems and the main areas of foc= us for this working group are described as follows:

1. Define, either by normative reference, adoption, or creation, a set of= standards that can be used for the purpose of assessing, aggregating and c= omparing device states against expected values, and reporting on those resu= lts in a predefined or ad hoc manner. 

2. Def= ine, either by normative reference, adoption, or creation, a set of standar= ds that can be used to continuously monitor and report on the state of syst= ems, composed of many different types of devices and networks, operated by = varying personnel, to ensure security process effectiveness in a pre-define= d or ad-hoc manner. 

3. Create relationships = between existing operations management standards to enable a comprehensive = view of security automation, leveraging existing work and implementations.<= /div>

This working group will produce the following:

* An Informational document providing an overview of = security automation and continuous monitoring to include a reference model<= /div>
* A Standards Track document specifying benchmark configuration r= epresentation (XCCDF)
* An Informational document stating guideli= nes / requirements for specifying checking languages
* Standards = Track documents specifying device state checking languages (OVAL, ECL, ACEM= L, =85)
* A Standards Track document specifying an interrogative = checking language (OCIL)
* A Standards Track document specifying = platform naming, matching and applicability (CPE)
* Standards Tra= ck documents specifying asset identification and reporting information (Ass= et ID, ARF)
* Standards Track documents specifying interfaces and= communication protocols used for security automation and continuous monito= ring 
* A Standards Track document describing the messages a= nd network protocols for distributing Security Automation Content  (co= ntent repository)
* Standards Track document describing integrati= ng security automation and Network Endpoint Assessment capabilities (if-m f= or SCAP?)
* A Standards Track document describing protocols and d= ata formats for securely sharing dynamic network state information among se= curity systems (if-map)

Goals and Milestones
=

TBD
-----------------------------------------= ---


Thanks.

Kent Landfield

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

From: Adam Montville <amontville@tripwire.com>
Date: Friday, August 17, 2012 12:33 P= M
To: David Waltermire <david.waltermire@nist.gov>,= Stephen Hanna <shanna@juniper.net= >, Luis Nunez <lnunez@c= 3isecurity.com>, Omar Santos <osantos@cisco.com>
Cc: = "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Proposed use cases to move forward
=

I like taking the scope down as well - and I think we all beli= eve we've
agreed to UC1 and UC3.  I don't have an issue= having the other use cases
(2, 4, and 5) described in the use ca= se document, but not fleshed out in
the functional capabilities, = components, and data/protocol sections.  The
charter ca= n be derived from the use cases we take on, and a separate
inform= ational document can help place those use cases in the right context
<= div>with respect to the "grand scheme of things."

<= /div>
No matter how we slice it, right now we need to focus on the use = cases and
charter, and to focus on the use cases we would ideally= need to work on
setting the context.  I've tried to do= that (to a limited extent) with the
informational document I sen= t to the list.

Additionally, I think these efforts= need to be done in parallel
irrespective of any idealistic depen= dencies.  For example, we should be
able to work on a c= harter, a use case doc, and an informational doc all at
the same = time, but join the threads for a final alignment pass before
subm= itting them.

Adam

On 8/17= /12 9:30 AM, "Waltermire, David A." <david.waltermire@nist.gov>
wrote:

St= eve,

These are all valid concerns that I completel= y agree with.  What I am
struggling with is insuring th= at the work we are embarking on remains
relevant in the broader c= ontext.  My fear is that if we narrow our
thinking too = much, we may inadvertently make decisions that drift from
address= ing the broader set of use cases.  I like the idea of working on<= /div>
an individual draft to address the larger context.  Wha= t I am not sure
about is how introduce a feedback loop that would= result in minimizing
this kind of risk.  I guess this = type of issue is something that we will
need to collectively moni= tor and address as needed.

Sincerely,
Da= ve


-----Original Message-----
=
From: Stephen Hanna [mailto:shan= na@juniper.net]
Sent: Wednesday, August 15, 2012 3:55 PM
To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos
Sub= ject: RE: [sacm] Proposed use cases to move forward

I love broad scope. Don't get me wrong! But I'm concerned about having a<= /div>
use cases document and an architecture document for this working = group
that goes way beyond the charter and initial scope for the = group.

I'm concerned that this will lead to lots o= f discussions on the sacm list
and lots of effort being spent on = topics that are out of scope, diverting
us from the tasks at hand= and slowing our progress.

I'm concerned that the = working group chairs won't be able to cut off
discussion of topic= s by saying they're out of scope for the working group.

I'm concerned that we'll get sidetracked or even derailed by
controversies that aren't relevant to the scope of the group.
<= br>
I'm concerned that by including all of security automation wi= thin our use
cases and architecture, we may actually prevent the = formation of other
working groups that could work on those other = use cases.

We have plenty of work to keep us busy = for years with UC1 and UC3.
There's agreement that the technology= needed is mature enough for IETF
standardization. I suggest that= we scope this working group to address
only those use cases and = that our use cases and architecture be limited
to them.

I'm sorely tempted to create an ambitious architecture for = security
automation that encompasses all of the use cases that we= have described
so far and maybe more. I understand that people h= ave a hard time
understanding how the NEA and MILE and SACM stand= ards fit together and I
would love to address that in an IETF RFC= . But I have seen several grand
architecture efforts die or come = to nothing in IETF. IETF is filled with
smart engineers with clev= er ideas. We're great at solving problems but if
we can't agree o= n the problem to solve or if we choose the wrong problem,
we can = easily spin an intricate and pointless web.

I thin= k we'll do better if we scope our effort properly.

Maybe a few people can create an individual submission describing a grand<= /div>
architecture and roadmap for security automation and ask people i= n SACM
to review and provide feedback on that document. That woul= d be a good way
to get a grand architecture while still ensuring = that the SACM effort
keeps its focus. In IETF as in so many thing= s, you must keep your focus
or you'll never succeed.
Thanks,

Steve

-----Original Messag= e-----
Of Waltermire, David A.
Se= nt: Wednesday, August 15, 2012 1:13 PM
To: Stephen Hanna; Adam M= ontville; Luis Nunez; Omar Santos
Subject: Re: [sacm] Proposed use cases = to move forward
+1 on scoping the charter to UC1= and UC3.
I think we are better served with a use ca= ses document, and eventually
an architecture documemnt, that is = broader scoped.  Both of these
documents will help inf= orm the work we will do under the charter as it
relates to the l= arger context.
To this end I would suggest we focus = on expanding the use case
document primarily in the areas of UC1= and UC3 for now.  We can expand
the other use cases l= ater.
Sincerely,
Dave
> -----Original Message-----
Of<= /div>
> Stephen Hanna
> Sent: Wednesday, August 15, 2= 012 11:24 AM
> To: Adam Montville; Luis Nunez; Omar Santos<= div> > Subject: Re: [sacm] Proposed use cases to move forward
= >
> I agree. Let's work on UC1 and UC3. The other use cas= es are valuable
> but just doing UC1 and UC3 is plenty of wor= k for this group for the
> next year or two (maybe five!).
>
> I saw several emails in favor of this a few w= eeks ago. I thought
> that it was settled. I'd like to see a = revised charter and use case
> document, scoped down to focus= on just UC1 and UC3.
>
> What do others think?= Do we have rough consensus on this?
> If so, let's get movin= g.
>
> Thanks,
>
> = Steve
>
> > -----Original Message-----
=
> > From: Adam Montville [mailto:amontville@tripwire.com]
> > Sent: Wednes= day, August 15, 2012 10:30 AM
> > To: Adam Montville; Step= hen Hanna; Luis Nunez; Omar Santos
> > Cc: sacm@ietf.org
> > Subject: Re: [sacm= ] Proposed use cases to move forward
> >
> &= gt; On 8/6/12 7:27 AM, "Adam Montville" <amontville@tripwire.com>
wrote:
> >
> > >
> > >
=
> > >UC1 and UC3 both require assessment of endpoint state. = If not for
> the
> > NEA
> >= ; >ties in UC1, it seems a subset of UC3.  So, we should be ab= le to
> > >start with the main concern of UC3: Security= Configuration
> Management.
> > >
<= div> > > >
> >
> >
&g= t; > I haven't seen much activity on this thread (there was another
> thread,
> > "Using the Frame of Reference= ," discussing some approaches we can
use
> &g= t; to keep us focused and meaningful).
> >
>= > Are there any objections to tackling UC3 followed by UC1?  = Does
> anyone
> > disagree with my assertion= that UC3 is a subset of UC1 and that a
> > reasonable sta= rting point is Security Configuration Management?
> >
>
> _______________________________________________=
> sacm mailing list
=
_______________________________________________
sacm maili= ng list
=


=



______= _________________________________________
sacm mailing list
=

--_000_CC57D86A3A8C3kentlandfieldmcafeecom_-- From Kent_Landfield@mcafee.com Mon Aug 20 13:07:30 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9CF11E8098 for ; Mon, 20 Aug 2012 13:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.086, 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 DYHfHajfyqxc for ; Mon, 20 Aug 2012 13:07:28 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id D771C11E808A for ; Mon, 20 Aug 2012 13:07:27 -0700 (PDT) Received: from DALEXHT1.corp.nai.org (unknown [10.64.5.51]) by dalsmrelay2.nai.com with smtp id 4e25_4db7_109c3294_3c04_46b8_98f2_41ef8b588058; Mon, 20 Aug 2012 15:07:27 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT1.corp.nai.org ([::1]) with mapi; Mon, 20 Aug 2012 15:06:32 -0500 From: To: Date: Mon, 20 Aug 2012 15:07:35 -0500 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1/D0pe92YHUFIuRMO1g6Uh6dqflQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC5802923A92Akentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 20:07:30 -0000 --_000_CC5802923A92Akentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In addition to the remediation question=85. I know we talked about the app= licability of this work being targeted at the enterprise. SOHO can be an e= xtension of the enterprise but I get the feeling from rereading traffic tha= t SOHO should not be included in the charterapplicability and we should foc= us ONLY on the enterprise=85 Thoughts? Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Kent Landfield > Date: Monday, August 20, 2012 2:59 PM To: "sacm@ietf.org" > Subject: Re: [sacm] Proposed use cases to move forward Yes, I agree we need to focus. It appears we have consensus on working on U= C1 and UC3. The use case document as it exists is very broad and its inten= t has expanded a great deal from the initial meeting in Paris. ;-) It is time to focus on the charter and what it is we want this working grou= p to do. We need to put a reasonable box around the effort so we can be pro= ductive. To that end, what follows is an updated version of the charter that was pos= ted just prior to the Vancouver meeting. It has taken into consideration r= equests made on the lists. Let's start discussing it as is. I know there a= re some good suggestions that I have not gotten to incorporate yet. One question that I did have is the draft charter talks about remediation. = What are other's thoughts on including that as a 'potential' for the work = to be done under SACM? Please take a look at it and let's talk about what is here. We will need t= o develop the list of deliverables and the milestones we expect to meet but= that will hopefully be driven by the base charter discussions. As a point of reference, how does the list want to see differences from one= version of the charter to the next? Let's keep it simple if possible=85 --------------------------------- Security Automation Continuous Monitoring (SACM) Proposed Working Group Charter Chairs: TBD TBD Security Area Directors: Stephen Farrell > Sean Turner > Security Area Advisor: Sean Turner > Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm Description of Working Group Securing information and the systems that store, process, and transmit that= information has become a challenging task for organizations of all sizes, = and we find that security practitioners spend most of their time on manual = processes relegating them to ineffectiveness. Security automation is the ke= y to escaping this rut. This working group will develop security automation= standards in support of information security processes and practices where= practical. These standards will support security practitioners to be bette= r utilized within their organizations by allowing them to meet the more adv= anced needs of the security community (e.g. information sharing, continuous= monitoring, remediation and response, result aggregation and analysis). Th= e initial focus of this work is to address enterprise and SOHO use cases. T= he working group will achieve this by consuming and continuing (with cooper= ation) the security automation work already performed by various organizati= ons around the world. The initial work has been fruitful, and the data formats previously publish= ed are ready for expansion on the international stage. Of particular intere= st to this working group are the security automation specifications support= ing asset, change, configuration, and vulnerability management. Of addition= al interest to this working group are the emerging security automation inte= rfaces and data formats relating to event management and continuous monitor= ing. By undertaking this work, we recognize that there are multiple categories o= f problems in the security automation domain: defining expressions for part= icular domain concepts (i.e. data formats), establishing a standards-based = foundation supporting the curation and exchange of security automation cont= ent collections in content repositories and enabling interoperability throu= gh the development and use of interfaces and communications protocols. Cont= ent based on rich data standards and protocols will provide the authoritati= ve instructions needed by data-driven tools to enable the automated collect= ion and exchange of configuration and vulnerability data pertaining to ente= rprise assets. Information produced by these tools will provide accurate an= d timely situational awareness in support of organizational decision making= . This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used for the purpose of assessing, aggregating and com= paring device states against expected values, and reporting on those result= s in a predefined or ad hoc manner. 2. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used to continuously monitor and report on the state o= f systems, composed of many different types of devices and networks, operat= ed by varying personnel, to ensure security process effectiveness in a pre-= defined or ad-hoc manner. 3. Create relationships between existing operations management standards to= enable a comprehensive view of security automation, leveraging existing wo= rk and implementations. This working group will produce the following: * An Informational document providing an overview of security automation an= d continuous monitoring to include a reference model * A Standards Track document specifying benchmark configuration representat= ion (XCCDF) * An Informational document stating guidelines / requirements for specifyin= g checking languages * Standards Track documents specifying device state checking languages (OVA= L, ECL, ACEML, =85) * A Standards Track document specifying an interrogative checking language = (OCIL) * A Standards Track document specifying platform naming, matching and appli= cability (CPE) * Standards Track documents specifying asset identification and reporting i= nformation (Asset ID, ARF) * Standards Track documents specifying interfaces and communication protoco= ls used for security automation and continuous monitoring * A Standards Track document describing the messages and network protocols = for distributing Security Automation Content (content repository) * Standards Track document describing integrating security automation and N= etwork Endpoint Assessment capabilities (if-m for SCAP?) * A Standards Track document describing protocols and data formats for secu= rely sharing dynamic network state information among security systems (if-m= ap) Goals and Milestones TBD -------------------------------------------- Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville > Date: Friday, August 17, 2012 12:33 PM To: David Waltermire >, Stephen Hanna >, Lui= s Nunez >, Omar Santo= s > Cc: "sacm@ietf.org" > Subject: Re: [sacm] Proposed use cases to move forward I like taking the scope down as well - and I think we all believe we've agreed to UC1 and UC3. I don't have an issue having the other use cases (2, 4, and 5) described in the use case document, but not fleshed out in the functional capabilities, components, and data/protocol sections. The charter can be derived from the use cases we take on, and a separate informational document can help place those use cases in the right context with respect to the "grand scheme of things." No matter how we slice it, right now we need to focus on the use cases and charter, and to focus on the use cases we would ideally need to work on setting the context. I've tried to do that (to a limited extent) with the informational document I sent to the list. Additionally, I think these efforts need to be done in parallel irrespective of any idealistic dependencies. For example, we should be able to work on a charter, a use case doc, and an informational doc all at the same time, but join the threads for a final alignment pass before submitting them. Adam On 8/17/12 9:30 AM, "Waltermire, David A." > wrote: Steve, These are all valid concerns that I completely agree with. What I am struggling with is insuring that the work we are embarking on remains relevant in the broader context. My fear is that if we narrow our thinking too much, we may inadvertently make decisions that drift from addressing the broader set of use cases. I like the idea of working on an individual draft to address the larger context. What I am not sure about is how introduce a feedback loop that would result in minimizing this kind of risk. I guess this type of issue is something that we will need to collectively monitor and address as needed. Sincerely, Dave -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net] Sent: Wednesday, August 15, 2012 3:55 PM To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos Cc: sacm@ietf.org Subject: RE: [sacm] Proposed use cases to move forward I love broad scope. Don't get me wrong! But I'm concerned about having a use cases document and an architecture document for this working group that goes way beyond the charter and initial scope for the group. I'm concerned that this will lead to lots of discussions on the sacm list and lots of effort being spent on topics that are out of scope, diverting us from the tasks at hand and slowing our progress. I'm concerned that the working group chairs won't be able to cut off discussion of topics by saying they're out of scope for the working group. I'm concerned that we'll get sidetracked or even derailed by controversies that aren't relevant to the scope of the group. I'm concerned that by including all of security automation within our use cases and architecture, we may actually prevent the formation of other working groups that could work on those other use cases. We have plenty of work to keep us busy for years with UC1 and UC3. There's agreement that the technology needed is mature enough for IETF standardization. I suggest that we scope this working group to address only those use cases and that our use cases and architecture be limited to them. I'm sorely tempted to create an ambitious architecture for security automation that encompasses all of the use cases that we have described so far and maybe more. I understand that people have a hard time understanding how the NEA and MILE and SACM standards fit together and I would love to address that in an IETF RFC. But I have seen several grand architecture efforts die or come to nothing in IETF. IETF is filled with smart engineers with clever ideas. We're great at solving problems but if we can't agree on the problem to solve or if we choose the wrong problem, we can easily spin an intricate and pointless web. I think we'll do better if we scope our effort properly. Maybe a few people can create an individual submission describing a grand architecture and roadmap for security automation and ask people in SACM to review and provide feedback on that document. That would be a good way to get a grand architecture while still ensuring that the SACM effort keeps its focus. In IETF as in so many things, you must keep your focus or you'll never succeed. Thanks, Steve -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Waltermire, David A. Sent: Wednesday, August 15, 2012 1:13 PM To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos Cc: sacm@ietf.org Subject: Re: [sacm] Proposed use cases to move forward +1 on scoping the charter to UC1 and UC3. I think we are better served with a use cases document, and eventually an architecture documemnt, that is broader scoped. Both of these documents will help inform the work we will do under the charter as it relates to the larger context. To this end I would suggest we focus on expanding the use case document primarily in the areas of UC1 and UC3 for now. We can expand the other use cases later. Sincerely, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bo= unces@ietf.org] On Behalf Of > Stephen Hanna > Sent: Wednesday, August 15, 2012 11:24 AM > To: Adam Montville; Luis Nunez; Omar Santos > Cc: sacm@ietf.org > Subject: Re: [sacm] Proposed use cases to move forward > > I agree. Let's work on UC1 and UC3. The other use cases are valuable > but just doing UC1 and UC3 is plenty of work for this group for the > next year or two (maybe five!). > > I saw several emails in favor of this a few weeks ago. I thought > that it was settled. I'd like to see a revised charter and use case > document, scoped down to focus on just UC1 and UC3. > > What do others think? Do we have rough consensus on this? > If so, let's get moving. > > Thanks, > > Steve > > > -----Original Message----- > > From: Adam Montville [mailto:amontville@tripwire.com] > > Sent: Wednesday, August 15, 2012 10:30 AM > > To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Proposed use cases to move forward > > > > On 8/6/12 7:27 AM, "Adam Montville" > wrote: > > > > > > > > > > >UC1 and UC3 both require assessment of endpoint state. If not for > the > > NEA > > >ties in UC1, it seems a subset of UC3. So, we should be able to > > >start with the main concern of UC3: Security Configuration > Management. > > > > > > > > > > > > I haven't seen much activity on this thread (there was another > thread, > > "Using the Frame of Reference," discussing some approaches we can use > > to keep us focused and meaningful). > > > > Are there any objections to tackling UC3 followed by UC1? Does > anyone > > disagree with my assertion that UC3 is a subset of UC1 and that a > > reasonable starting point is Security Configuration Management? > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_CC5802923A92Akentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
In addition= to the remediation question=85.  I know we talked about the applicabi= lity of this work being targeted at the enterprise.  SOHO can be an ex= tension of the enterprise but I get the feeling from rereading traffic that= SOHO should not be included in the charterapplicability and we should focu= s ONLY on the enterprise=85  

Thoughts?
=

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 = ;
Mobile: +1.= 817.637.8026Web: www.mcafee.com
=
From: <Landfield= >, Kent Landfield <Kent_= Landfield@McAfee.com>
Date: Monday, August 20, 2012 2:59 PM
To:= "sacm@ietf.org" <= ;sacm@ietf.org>
Subject: Re: [sacm] Proposed use cases to move for= ward

Yes, I agree = we need to focus. It appears we have consensus on working on UC1 and UC3. &= nbsp;The use case document as it exists is very broad and its intent has ex= panded a great deal from the initial meeting in Paris. ;-)

It is time to focus on the charter and what it is we want this wor= king group to do. We need to put a reasonable box around the effort so we c= an be productive.

To that end, what follows is an = updated version of the charter that was posted just prior to the Vancouver = meeting.  It has taken into consideration requests made on the lists. =  Let's start discussing it as is. I know there are some good suggestio= ns that I have not gotten to incorporate yet.

One questio= n that I did have is the draft charter talks about remediation.  What = are other's thoughts on including that as a 'potential' for the work to be = done under SACM?

Please take a look at it and let'= s talk about what is here.  We will need to develop the list of delive= rables and the milestones we expect to meet but that will hopefully be driv= en by the base charter discussions.

As a point of = reference, how does the list want to see differences from one version of th= e charter to the next?  Let's keep it simple if possible=85
=
---------------------------------
Security Au= tomation Continuous Monitoring (SACM)

Proposed Wor= king Group Charter

Chairs:
TBD
TBD

Security Area Directors:
  &nb= sp;  Stephen Farrell <= stephen.farrell@cs.tcd.ie>
     Sean Turner= <turners@ieca.com>

Security Area Advisor:
     Sean T= urner <turners@ieca.com>

Mailing Lists:
     General D= iscussion: sacm@ietf.org
&nb= sp;    To Subscribe:           http://www.ietf.org/mailman/= listinfo/sacm
     Archive:     &nbs= p;          http://www.ietf.org/mail-archive/web/sacm
Description of Working Group

Securing = information and the systems that store, process, and transmit that informat= ion has become a challenging task for organizations of all sizes, and we fi= nd that security practitioners spend most of their time on manual processes= relegating them to ineffectiveness. Security automation is the key to escaping this rut. This= working group will develop security automation standards in support of inf= ormation security processes and practices where practical. These standards = will support security practitioners to be better utilized within their organizations by allowing them to meet = the more advanced needs of the security community (e.g. information sharing= , continuous monitoring, remediation and response, result aggregation and a= nalysis). The initial focus of this work is to address enterprise and SOHO use cases. The working group will a= chieve this by consuming and continuing (with cooperation) the security aut= omation work already performed by various organizations around the world.

The initial work has been fruitful, and the data fo= rmats previously published are ready for expansion on the international sta= ge. Of particular interest to this working group are the security automatio= n specifications supporting asset, change, configuration, and vulnerability management. Of additional interest to this working group= are the emerging security automation interfaces and data formats relating = to event management and continuous monitoring.

By = undertaking this work, we recognize that there are multiple categories of p= roblems in the security automation domain: defining expressions for particu= lar domain concepts (i.e. data formats), establishing a standards-based fou= ndation supporting the curation and exchange of security automation content collections in content reposit= ories and enabling interoperability through the development and use of inte= rfaces and communications protocols. Content based on rich data standards a= nd protocols will provide the authoritative instructions needed by data-driven tools to enable the automated collectio= n and exchange of configuration and vulnerability data pertaining to enterp= rise assets. Information produced by these tools will provide accurate and = timely situational awareness in support of organizational decision making. 

= This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows:=

1. Define, either by normative reference, adoptio= n, or creation, a set of standards that can be used for the purpose of asse= ssing, aggregating and comparing device states against expected values, and= reporting on those results in a predefined or ad hoc manner. 

2. Define, either by normative refe= rence, adoption, or creation, a set of standards that can be used to contin= uously monitor and report on the state of systems, composed of many differe= nt types of devices and networks, operated by varying personnel, to ensure security process effectiveness in a pre-defined or ad-hoc manner.&n= bsp;

3. Create relationships between existing oper= ations management standards to enable a comprehensive view of security auto= mation, leveraging existing work and implementations.

<= div>This working group will produce the following:

* An Informational document providing an overview of security automation a= nd continuous monitoring to include a reference model
* A Standar= ds Track document specifying benchmark configuration representation (XCCDF)=
* An Informational document stating guidelines / requirements fo= r specifying checking languages
* Standards Track documents speci= fying device state checking languages (OVAL, ECL, ACEML, =85)
* A= Standards Track document specifying an interrogative checking language (OC= IL)
* A Standards Track document specifying platform naming, matc= hing and applicability (CPE)
* Standards Track documents specifyi= ng asset identification and reporting information (Asset ID, ARF)
* Standards Track documents specifying interfaces and communication protoc= ols used for security automation and continuous monitoring 
= * A Standards Track document describing the messages and network protocols = for distributing Security Automation Content  (content repository)
* Standards Track document describing integrating security automatio= n and Network Endpoint Assessment capabilities (if-m for SCAP?)
*= A Standards Track document describing protocols and data formats for secur= ely sharing dynamic network state information among security systems (if-ma= p)

Goals and Milestones

T= BD
--------------------------------------------


Thanks.

Kent Landfield
=
McAfee |= An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.c= om

From: Adam Montville <amontville@tripwire.com>
Date: Friday, August 17, 2012 12:33 PM
To: David Waltermire <david.waltermire@nist.gov>, Stephen Hanna <shanna@juniper.net>, Luis Nunez <= ;lnunez@c3isecurity.com>, Omar Santos <osantos@cisco.com= >
Cc: "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Proposed use cases to move forward

I like takin= g the scope down as well - and I think we all believe we've
agree= d to UC1 and UC3.  I don't have an issue having the other use cas= es
(2, 4, and 5) described in the use case document, but not fles= hed out in
the functional capabilities, components, and data/prot= ocol sections.  The
charter can be derived from the use= cases we take on, and a separate
informational document can help= place those use cases in the right context
with respect to the &= quot;grand scheme of things."

No matter how w= e slice it, right now we need to focus on the use cases and
chart= er, and to focus on the use cases we would ideally need to work on
setting the context.  I've tried to do that (to a limited exten= t) with the
informational document I sent to the list.
=
Additionally, I think these efforts need to be done in paral= lel
irrespective of any idealistic dependencies.  For e= xample, we should be
able to work on a charter, a use case doc, a= nd an informational doc all at
the same time, but join the thread= s for a final alignment pass before
submitting them.
Adam

On 8/17/12 9:30 AM, "Walter= mire, David A." <david= .waltermire@nist.gov>
wrote:

Steve,

=
These are all valid concerns that I completely agree with.  = What I am
struggling with is insuring that the work we are embark= ing on remains
relevant in the broader context.  My fea= r is that if we narrow our
thinking too much, we may inadvertentl= y make decisions that drift from
addressing the broader set of us= e cases.  I like the idea of working on
an individual d= raft to address the larger context.  What I am not sure
about is how introduce a feedback loop that would result in minimizing
this kind of risk.  I guess this type of issue is somethin= g that we will
need to collectively monitor and address as needed= .

Sincerely,
Dave


-----Original Message-----
From: Stephen Hanna = [mailto:shanna@juniper.net]
=
Sent: Wednesday, August 15, 2012 3:55 PM
To: Waltermire, Dav= id A.; Adam Montville; Luis Nunez; Omar Santos
Subject: RE: [sacm] Proposed= use cases to move forward

I love broad scope. Don= 't get me wrong! But I'm concerned about having a
use cases docum= ent and an architecture document for this working group
that goes= way beyond the charter and initial scope for the group.

I'm concerned that this will lead to lots of discussions on the sacm= list
and lots of effort being spent on topics that are out of sc= ope, diverting
us from the tasks at hand and slowing our progress= .

I'm concerned that the working group chairs won'= t be able to cut off
discussion of topics by saying they're out o= f scope for the working group.

I'm concerned that = we'll get sidetracked or even derailed by
controversies that aren= 't relevant to the scope of the group.

I'm concern= ed that by including all of security automation within our use
ca= ses and architecture, we may actually prevent the formation of other
<= div>working groups that could work on those other use cases.

=
We have plenty of work to keep us busy for years with UC1 and UC= 3.
There's agreement that the technology needed is mature enough = for IETF
standardization. I suggest that we scope this working gr= oup to address
only those use cases and that our use cases and ar= chitecture be limited
to them.

I'm sorel= y tempted to create an ambitious architecture for security
automa= tion that encompasses all of the use cases that we have described
so far and maybe more. I understand that people have a hard time
understanding how the NEA and MILE and SACM standards fit together and I
would love to address that in an IETF RFC. But I have seen several= grand
architecture efforts die or come to nothing in IETF. IETF = is filled with
smart engineers with clever ideas. We're great at = solving problems but if
we can't agree on the problem to solve or= if we choose the wrong problem,
we can easily spin an intricate = and pointless web.

I think we'll do better if we s= cope our effort properly.

Maybe a few people can c= reate an individual submission describing a grand
architecture an= d roadmap for security automation and ask people in SACM
to revie= w and provide feedback on that document. That would be a good way
to get a grand architecture while still ensuring that the SACM effort
keeps its focus. In IETF as in so many things, you must keep your foc= us
or you'll never succeed.

Thanks,

Steve

-----Original Message-----
From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf<= /div>
Of Waltermire, David A.
Sent: Wednesday, August 15, 201= 2 1:13 PM
To: Stephen Hanna; Adam Montville; Luis Nunez; Omar San= tos
<= div>Subject: Re: [sacm] Proposed use cases to move forward
=
+1 on scoping the charter to UC1 and UC3.
I t= hink we are better served with a use cases document, and eventually
an architecture documemnt, that is broader scoped.  Both of th= ese
documents will help inform the work we will do under the char= ter as it
relates to the larger context.
To = this end I would suggest we focus on expanding the use case
docum= ent primarily in the areas of UC1 and UC3 for now.  We can expand=
the other use cases later.
Sincerely,
=
Dave
> -----Original Message-----
Of
> Stephen Hanna
> Sent: = Wednesday, August 15, 2012 11:24 AM
> To: Adam Montville; Luis= Nunez; Omar Santos
> Subject: Re: [sacm] Proposed use cases to mov= e forward
>
> I agree. Let's work on UC1 and UC3.= The other use cases are valuable
> but just doing UC1 and UC3= is plenty of work for this group for the
> next year or two (= maybe five!).
>
> I saw several emails in favor o= f this a few weeks ago. I thought
> that it was settled. I'd l= ike to see a revised charter and use case
> document, scoped d= own to focus on just UC1 and UC3.
>
> What do oth= ers think? Do we have rough consensus on this?
> If so, let's = get moving.
>
> Thanks,
>
= > Steve
>
> > -----Original Message-----
> > From: Adam Montville [mailto:amontville@tripwire.com]
> > Sent: Wedne= sday, August 15, 2012 10:30 AM
> > To: Adam Montville; Step= hen Hanna; Luis Nunez; Omar Santos
> > Subject: Re: [sacm] = Proposed use cases to move forward
> >
> > = On 8/6/12 7:27 AM, "Adam Montville" <amontville@tripwire.com>
wrote:
> >
> > >
> > >
>= ; > >UC1 and UC3 both require assessment of endpoint state. If not fo= r
> the
> > NEA
> > >ties i= n UC1, it seems a subset of UC3.  So, we should be able to
<= div>> > >start with the main concern of UC3: Security Configuratio= n
> Management.
> > >
> > &= gt;
> >
> >
> > I haven't s= een much activity on this thread (there was another
> thread,<= /div>
> > "Using the Frame of Reference," discussing so= me approaches we can
use
> > to keep us focused a= nd meaningful).
> >
> > Are there any objec= tions to tackling UC3 followed by UC1?  Does
> anyon= e
> > disagree with my assertion that UC3 is a subset of UC= 1 and that a
> > reasonable starting point is Security Conf= iguration Management?
> >
>
> ___= ____________________________________________
> sacm mailing li= st
<= div>> https://www= .ietf.org/mailman/listinfo/sacm
_____________________________= __________________
sacm mailing list
=





____________________________________________= ___
sacm mailing list

=
--_000_CC5802923A92Akentlandfieldmcafeecom_-- From anton.chuvakin@gmail.com Mon Aug 20 13:42:43 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3458821F84DD for ; Mon, 20 Aug 2012 13:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjeukxsWISYs for ; Mon, 20 Aug 2012 13:42:42 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 230F221F84C8 for ; Mon, 20 Aug 2012 13:42:41 -0700 (PDT) Received: by weyu54 with SMTP id u54so4796746wey.31 for ; Mon, 20 Aug 2012 13:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=nNIoUF1FY3A8tQ45OtRn2aSv/Ajv26VPsczcsv9Q8YE=; b=fDYzNLW2s6ArkMo9KoEdmlPNqKXlhmkaZltdn20kG2zhrdTG2i4gS0YUxR5IzEq0/L EAJx9Nd4my121ZTTB0fZnQZiGlcBUs+wdGCIkoxl/BWcr958vikb2T3WZn0vONs06JA3 Zd560SebK/CT69/Rrb7RPA+rgWf0rEYPZldXAfqU9TE5H3o4Jw9fklhsAdkEziq3jjkL g6ZtVCnzNBdKSulTyH8pKrd6OOxRdSj2LwUFOAg5z24tOXnMhBnHO8SKvpmWEI3anpvN zXih/b/Szkmy5gl9gddcR8e0WCCVXTnDeQrKHPRZUCwtepwAbwkiDNLJeO1PrEfHuc2F jvKQ== Received: by 10.216.74.21 with SMTP id w21mr8029216wed.77.1345495361226; Mon, 20 Aug 2012 13:42:41 -0700 (PDT) MIME-Version: 1.0 Sender: anton.chuvakin@gmail.com Received: by 10.223.62.138 with HTTP; Mon, 20 Aug 2012 13:42:10 -0700 (PDT) In-Reply-To: <10469770.153890.1345048209584.JavaMail.root@vms170025> References: <10469770.153890.1345048209584.JavaMail.root@vms170025> From: Anton Chuvakin Date: Mon, 20 Aug 2012 13:42:10 -0700 X-Google-Sender-Auth: E8yXkkJGnL45zwu2iHndSCmY1fU Message-ID: To: david.oliva@verizon.net Content-Type: text/plain; charset=ISO-8859-1 Cc: shanna@juniper.net, sacm@ietf.org Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 20:42:43 -0000 > For UC3, I cannot see which spec in SCAP 1.2 to associate with network > events. The only thing close to a spec that approaches this criterion is > the Common Events Enumeration (CEE) that Dr. Chuvakin is working on. > In a short question to Dr. Chuvakin about the possibility of CEE and SCAP > working together he replied "CEE can work with SCAP via OVAL, CPE, AI and > ARF to report events identifying the affected assets in a standard way". If CEE is part > of a future SACM version, then yes. Well, CEE (now in beta at http://cee.mitre.org/language/1.0-beta1/) can and should definitely be used by SACM. There is nothing (in my view) that makes it not usable by SACM, EMAP, etc, etc. However, if SACM turns to reinventing/redefining its own log/event standard, than it will have one very angry and nasty enemy :-) -- Dr. Anton Chuvakin Site: http://www.chuvakin.org Twitter: @anton_chuvakin Work: http://www.linkedin.com/in/chuvakin From david.oliva@verizon.net Tue Aug 21 05:53: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 E7A0121F8652 for ; Tue, 21 Aug 2012 05:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[AWL=0.427, 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 KoXhiQ4DV+R4 for ; Tue, 21 Aug 2012 05:53:34 -0700 (PDT) Received: from vms173009pub.verizon.net (vms173009pub.verizon.net [206.46.173.9]) by ietfa.amsl.com (Postfix) with ESMTP id 898E321F8644 for ; Tue, 21 Aug 2012 05:53:34 -0700 (PDT) Received: from vms170025pub.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 ESMTPA id <0M9300H09VSUYRE2@vms173009.mailsrvcs.net> for sacm@ietf.org; Tue, 21 Aug 2012 07:53:19 -0500 (CDT) Received: from 96.241.55.45 ([96.241.55.45]) by vms170025 (Verizon Webmail) with HTTP; Tue, 21 Aug 2012 07:53:18 -0500 (CDT) Date: Tue, 21 Aug 2012 07:53:18 -0500 (CDT) From: david.oliva@verizon.net To: sacm@ietf.org Message-id: <24832099.591869.1345553598252.JavaMail.root@vms170025> 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.55.45] Subject: [sacm] SACM recommendations for SOHO-as-Enterprise-Extension environments X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 12:53:36 -0000
&nb= sp;

SACM recommendations for SOHO-as-Ente= rprise-Extension environments

The notion of SOHO as an extension of the enterprise is perhaps a good use= case for SACM.

While it may be tr= ue that some security controls cannot be extended to the SOHO (such as phys= ical security), the enterprise may consider VPN software, vulnerability and= configuration scanners as compensating mechanism for SOHO use under certai= n circumstances.  The CCE com= ponent of SACM would then be used with enterprise governance values applied= to the VPN (or whatever other software mechanism the SOHO user is willing = to allow).  The value of this= use case is to enable business enterprises to allow employees a viable opt= ion when wheather and other phenomena affect their environment.<= /FONT>

David Oliva
 
 
On 08/20/12, Ke= nt_Landfield@McAfee.com wrote:
 
In addi= tion to the remediation question=E2=80=A6.  I know we talked about the= applicability of this work being targeted at the enterprise.  SOHO ca= n be an extension of the enterprise but I get the feeling from rereading tr= affic that SOHO should not be included in the charterapplicability and we s= hould focus ONLY on the enterprise=E2=80=A6  

Thoughts?

Kent Landfield

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

From: <Landfield>, Kent Landfield <Kent_Landfi= eld@McAfee.com>
Date: Mo= nday, August 20, 2012 2:59 PM
To: "sa= cm@ietf.org" <sacm@ietf.org>
S= ubject: Re: [sacm] Proposed use cases to move forward
=
Yes, I agree we need to focus. It appears = we have consensus on working on UC1 and UC3.  The use case document as= it exists is very broad and its intent has expanded a great deal from the = initial meeting in Paris. ;-)

It is time to focus = on the charter and what it is we want this working group to do. We need to = put a reasonable box around the effort so we can be productive.
<= BR>
To that end, what follows is an updated version of the charte= r that was posted just prior to the Vancouver meeting.  It has taken i= nto consideration requests made on the lists.  Let's start discussing = it as is. I know there are some good suggestions that I have not gotten to = incorporate yet.

One question that I did have is t= he draft charter talks about remediation.  What are other's thoughts o= n including that as a 'potential' for the work to be done under SACM?
=

Please take a look at it and let's talk about what is h= ere.  We will need to develop the list of deliverables and the milesto= nes we expect to meet but that will hopefully be driven by the base charter= discussions.

As a point of reference, how does th= e list want to see differences from one version of the charter to the next?=  Let's keep it simple if possible=E2=80=A6

<= DIV>---------------------------------
Security Automation Continu= ous Monitoring (SACM)

Proposed Working Group Chart= er

Chairs:
TBD
TBD
<= BR>
Security Area Directors:
     Stephe= n Farrell <stephen.farrell@cs.tcd.ie>
  &nbs= p;  Sean Turner <turners@ieca.com>

Sec= urity Area Advisor:
     Sean Turner <turners@iec= a.com>

Mailing Lists:
  &nbs= p;  General Discussion: sacm@ietf.org
     To S= ubscribe:           http://www.ietf.org/mailman/listinf= o/sacm
     Archive:       &nbs= p;        http://www.ietf.org/mail-archive/web/sacm

Description of Working Group

= Securing information and the systems that store, process, and transmit that= information has become a challenging task for organizations of all sizes, = and we find that security practitioners spend most of their time on manual = processes relegating them to ineffectiveness. Security automation is the ke= y to escaping this rut. This working group will develop security automation= standards in support of information security processes and practices where= practical. These standards will support security practitioners to be bette= r utilized within their organizations by allowing them to meet the more adv= anced needs of the security community (e.g. information sharing, continuous= monitoring, remediation and response, result aggregation and analysis). Th= e initial focus of this work is to address enterprise and SOHO use cases. T= he working group will achieve this by consuming and continuing (with cooper= ation) the security automation work already performed by various organizati= ons around the world.

The initial work has been fr= uitful, and the data formats previously published are ready for expansion o= n the international stage. Of particular interest to this working group are= the security automation specifications supporting asset, change, configura= tion, and vulnerability management. Of additional interest to this working = group are the emerging security automation interfaces and data formats rela= ting to event management and continuous monitoring.

By undertaking this work, we recognize that there are multiple categories= of problems in the security automation domain: defining expressions for pa= rticular domain concepts (i.e. data formats), establishing a standards-base= d foundation supporting the curation and exchange of security automation co= ntent collections in content repositories and enabling interoperability thr= ough the development and use of interfaces and communications protocols. Co= ntent based on rich data standards and protocols will provide the authorita= tive instructions needed by data-driven tools to enable the automated colle= ction and exchange of configuration and vulnerability data pertaining to en= terprise assets. Information produced by these tools will provide accurate = and timely situational awareness in support of organizational decision maki= ng. 

This working group will provide solution= s to these categories of problems and the main areas of focus for this work= ing group are described as follows:

1. Define, eit= her by normative reference, adoption, or creation, a set of standards that = can be used for the purpose of assessing, aggregating and comparing device = states against expected values, and reporting on those results in a predefi= ned or ad hoc manner. 

2. Define, either by n= ormative reference, adoption, or creation, a set of standards that can be u= sed to continuously monitor and report on the state of systems, composed of= many different types of devices and networks, operated by varying personne= l, to ensure security process effectiveness in a pre-defined or ad-hoc mann= er. 

3. Create relationships between existing= operations management standards to enable a comprehensive view of security= automation, leveraging existing work and implementations.

This working group will produce the following:

* An Informational document providing an overview of security automat= ion and continuous monitoring to include a reference model
* A St= andards Track document specifying benchmark configuration representation (X= CCDF)
* An Informational document stating guidelines / requiremen= ts for specifying checking languages
* Standards Track documents = specifying device state checking languages (OVAL, ECL, ACEML, =E2=80=A6)
* A Standards Track document specifying an interrogative checking l= anguage (OCIL)
* A Standards Track document specifying platform n= aming, matching and applicability (CPE)
* Standards Track documen= ts specifying asset identification and reporting information (Asset ID, ARF= )
* Standards Track documents specifying interfaces and communica= tion protocols used for security automation and continuous monitoring =
* A Standards Track document describing the messages and network= protocols for distributing Security Automation Content  (content repo= sitory)
* Standards Track document describing integrating securit= y automation and Network Endpoint Assessment capabilities (if-m for SCAP?)<= /DIV>
* A Standards Track document describing protocols and data format= s for securely sharing dynamic network state information among security sys= tems (if-map)

Goals and Milestones

<= /DIV>
TBD
--------------------------------------------
<= DIV>

Thanks.

Kent Landfie= ld
<= /SPAN>
McAfee | An Intel Com= panyDirect: +1.972.= 963.7096 Mobile: +1.817= .637.8026
Web: <= /STRONG>www.mcafee.com

From: Adam Montville <<= A class=3DparsedEmail href=3D"mailto:amontville@tripwire.com" target=3D_bla= nk>amontville@tripwire.com>
Dat= e: Friday, August 17, 2012 12:33 PM
To: David Waltermire <david.waltermire@nist.gov>= ;, Stephen Hanna <shanna@juniper.net>, Luis Nunez <lnunez@c3= isecurity.com>, Omar Santos <osantos@cisco.com>
Cc: "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Proposed use cas= es to move forward

I like taking the scope down as well - and I t= hink we all believe we've
agreed to UC1 and UC3.  I don= 't have an issue having the other use cases
(2, 4, and 5) describ= ed in the use case document, but not fleshed out in
the functiona= l capabilities, components, and data/protocol sections.  The
charter can be derived from the use cases we take on, and a separate<= /DIV>
informational document can help place those use cases in the righ= t context
with respect to the "grand scheme of things."

No matter how we slice it, right now we need to focus on th= e use cases and
charter, and to focus on the use cases we would i= deally need to work on
setting the context.  I've tried= to do that (to a limited extent) with the
informational document= I sent to the list.

Additionally, I think these e= fforts need to be done in parallel
irrespective of any idealistic= dependencies.  For example, we should be
able to work = on a charter, a use case doc, and an informational doc all at
the= same time, but join the threads for a final alignment pass before
submitting them.

Adam

O= n 8/17/12 9:30 AM, "Waltermire, David A." <david.waltermire@nist= .gov>
wrote:

Steve,

These are all val= id concerns that I completely agree with.  What I am
st= ruggling with is insuring that the work we are embarking on remains
relevant in the broader context.  My fear is that if we narrow= our
thinking too much, we may inadvertently make decisions that = drift from
addressing the broader set of use cases.  I = like the idea of working on
an individual draft to address the la= rger context.  What I am not sure
about is how introduc= e a feedback loop that would result in minimizing
this kind of ri= sk.  I guess this type of issue is something that we will
need to collectively monitor and address as needed.

=
Sincerely,
Dave


----= -Original Message-----
From: Stephen Hanna [mailto:shanna@juniper.= net]
Sent: Wednesday, August 15, 2012 3:55 PM
To: W= altermire, David A.; Adam Montville; Luis Nunez; Omar Santos
Subject: RE: [sacm] Proposed use cases to move forwar= d

I love broad scope. Don't get me wrong! But I'm = concerned about having a
use cases document and an architecture d= ocument for this working group
that goes way beyond the charter a= nd initial scope for the group.

I'm concerned that= this will lead to lots of discussions on the sacm list
and lots = of effort being spent on topics that are out of scope, diverting
= us from the tasks at hand and slowing our progress.

I'm concerned that the working group chairs won't be able to cut off
discussion of topics by saying they're out of scope for the working g= roup.

I'm concerned that we'll get sidetracked or = even derailed by
controversies that aren't relevant to the scope = of the group.

I'm concerned that by including all = of security automation within our use
cases and architecture, we = may actually prevent the formation of other
working groups that c= ould work on those other use cases.

We have plenty= of work to keep us busy for years with UC1 and UC3.
There's agre= ement that the technology needed is mature enough for IETF
standa= rdization. I suggest that we scope this working group to address
= only those use cases and that our use cases and architecture be limited
to them.

I'm sorely tempted to create an am= bitious architecture for security
automation that encompasses all= of the use cases that we have described
so far and maybe more. I= understand that people have a hard time
understanding how the NE= A and MILE and SACM standards fit together and I
would love to ad= dress that in an IETF RFC. But I have seen several grand
architec= ture efforts die or come to nothing in IETF. IETF is filled with
= smart engineers with clever ideas. We're great at solving problems but if
we can't agree on the problem to solve or if we choose the wrong p= roblem,
we can easily spin an intricate and pointless web.
<= DIV>
I think we'll do better if we scope our effort properly.=

Maybe a few people can create an individual submi= ssion describing a grand
architecture and roadmap for security au= tomation and ask people in SACM
to review and provide feedback on= that document. That would be a good way
to get a grand architect= ure while still ensuring that the SACM effort
keeps its focus. In= IETF as in so many things, you must keep your focus
or you'll ne= ver succeed.

Thanks,

Stev= e

--= ---Original Message-----
Of Waltermire, David A.<= /DIV>
Sent: Wednesday, August 15, 2012 1:13 PM
To: Stephen Ha= nna; Adam Montville; Luis Nunez; Omar Santos
Cc: sacm@ietf.org
Subject: Re: [sacm] Proposed use cases to move forward
+1 on scoping the charter to UC1 and UC3.
I thi= nk we are better served with a use cases document, and eventually
an architecture documemnt, that is broader scoped.  Both of thes= e
documents will help inform the work we will do under the charte= r as it
relates to the larger context.
To th= is end I would suggest we focus on expanding the use case
documen= t primarily in the areas of UC1 and UC3 for now.  We can expand
the other use cases later.
Sincerely,
Dave
> -----Original Message-----
Of
> Stephen Hanna
> Sent: Wedn= esday, August 15, 2012 11:24 AM
> To: Adam Montville; Luis Nun= ez; Omar Santos
> Subject: Re: = [sacm] Proposed use cases to move forward
>
> I a= gree. Let's work on UC1 and UC3. The other use cases are valuable
> but just doing UC1 and UC3 is plenty of work for this group for the
> next year or two (maybe five!).
>
>= I saw several emails in favor of this a few weeks ago. I thought
> that it was settled. I'd like to see a revised charter and use case
> document, scoped down to focus on just UC1 and UC3.
>
> What do others think? Do we have rough consensus on th= is?
> If so, let's get moving.
>
> T= hanks,
>
> Steve
>
> &g= t; -----Original Message-----
> > From: Adam Montville [mailto:amontville@tripwire.com]
> > Sent: Wednesday, A= ugust 15, 2012 10:30 AM
> > To: Adam Montville; Stephen Han= na; Luis Nunez; Omar Santos
&= gt; > Subject: Re: [sacm] Proposed use cases to move forward
&= gt; >
> > On 8/6/12 7:27 AM, "Adam Montville" <am= ontville@tripwire.com>
wrote:
> >
> > >
> > >
> > >UC1 and U= C3 both require assessment of endpoint state. If not for
> the=
> > NEA
> > >ties in UC1, it seems a su= bset of UC3.  So, we should be able to
> > >st= art with the main concern of UC3: Security Configuration
> Man= agement.
> > >
> > >
> &= gt;
> >
> > I haven't seen much activity on= this thread (there was another
> thread,
> > = "Using the Frame of Reference," discussing some approaches we can
use
> > to keep us focused and meaningful).
>= >
> > Are there any objections to tackling UC3 followed= by UC1?  Does
> anyone
> > disagree= with my assertion that UC3 is a subset of UC1 and that a
> &g= t; reasonable starting point is Security Configuration Management?
> >
>
> _________________________________= ______________
> sacm mailing list
> sacm@ietf.org<= /DIV>
_______= ________________________________________
sacm mailing list
<= DIV>sa= cm@ietf.org
<= /BLOCKQUOTE>



=

_____________________________________________= __
sacm mailing list



______________= _________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm
From amontville@tripwire.com Tue Aug 21 06:16:01 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C541B21F865C for ; Tue, 21 Aug 2012 06:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.268 X-Spam-Level: X-Spam-Status: No, score=-5.268 tagged_above=-999 required=5 tests=[AWL=1.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3] 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 rzzXo8Mp4RaS for ; Tue, 21 Aug 2012 06:16:01 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC5221F85C7 for ; Tue, 21 Aug 2012 06:16:01 -0700 (PDT) Received: from mail14-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 Aug 2012 13:16:00 +0000 Received: from mail14-tx2 (localhost [127.0.0.1]) by mail14-tx2-R.bigfish.com (Postfix) with ESMTP id 9B0E2E04C7 for ; Tue, 21 Aug 2012 13:16:00 +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: -5 X-BigFish: VPS-5(zzbb2dI98dI9371I1432I4015Izz1202hzz8275bhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail14-tx2 (localhost.localdomain [127.0.0.1]) by mail14-tx2 (MessageSwitch) id 1345554958481018_30262; Tue, 21 Aug 2012 13:15:58 +0000 (UTC) Received: from TX2EHSMHS014.bigfish.com (unknown [10.9.14.240]) by mail14-tx2.bigfish.com (Postfix) with ESMTP id 71DA02000A3 for ; Tue, 21 Aug 2012 13:15:58 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by TX2EHSMHS014.bigfish.com (10.9.99.114) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 Aug 2012 13:15:58 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 8BBB923211DD for ; Tue, 21 Aug 2012 06:14:58 -0700 (PDT) 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 EDAAD23211D9; Tue, 21 Aug 2012 06:14:57 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Aug 2012 06:17:38 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Tue, 21 Aug 2012 06:15:55 -0700 From: Adam Montville To: "dcougias@netfrontiers.com" , "sacm@ietf.org" Thread-Topic: [sacm] UCF Spreadsheets available for this group to use for research purposes Thread-Index: AQHNfu1DkH6f6NlziEmAbI78hwwfFZdkQFOA Date: Tue, 21 Aug 2012 13:15:55 +0000 Message-ID: In-Reply-To: <13944c58ec8.6060514636934045424.3597909173785290824@netfrontiers.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <463D523C606A994E974D7C1C61026660@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: aa6d0e2e-0d30-4242-9cc7-ad37a235c300 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: Re: [sacm] UCF Spreadsheets available for this group to use for research purposes X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 13:16:01 -0000 Thanks, Dorian! On 8/20/12 9:02 AM, "Dorian Cougias" wrote: >About a week ago, we offered anyone on this list free access to the UCF's >spreadsheets and other research materials. > > >The process for getting the materials (so that you get regular updates) >is as follows: > > >Sign up for a free account at www.unifiedcompliance.com > > >e-mail Craig Isaacs (cisaacs@unifiedcompliance.com) the mail address you >used when you signed up and let him know you are a part of the SACM group. > > >That's it. > > >--Additional tools in development: > > >"Did you mean..." phrase checker > > > >Hierarchical term browser > > > > > > >Dorian J. Cougias >Compliance Scientist >Unified Compliance Framework > > > > > From amontville@tripwire.com Tue Aug 21 06:21:25 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162AE21F8634 for ; Tue, 21 Aug 2012 06:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.942 X-Spam-Level: X-Spam-Status: No, score=-3.942 tagged_above=-999 required=5 tests=[AWL=-0.343, 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 ayNGjROxKbRB for ; Tue, 21 Aug 2012 06:21:24 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 4E38421F8628 for ; Tue, 21 Aug 2012 06:21:24 -0700 (PDT) Received: from mail123-co1-R.bigfish.com (10.243.78.250) by CO1EHSOBE011.bigfish.com (10.243.66.74) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 Aug 2012 13:21:23 +0000 Received: from mail123-co1 (localhost [127.0.0.1]) by mail123-co1-R.bigfish.com (Postfix) with ESMTP id 94A9DA80303 for ; Tue, 21 Aug 2012 13:21:23 +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: -4 X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1202hzz8275bh8275dhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail123-co1 (localhost.localdomain [127.0.0.1]) by mail123-co1 (MessageSwitch) id 1345555281329211_15580; Tue, 21 Aug 2012 13:21:21 +0000 (UTC) Received: from CO1EHSMHS022.bigfish.com (unknown [10.243.78.231]) by mail123-co1.bigfish.com (Postfix) with ESMTP id 43E75B8004F for ; Tue, 21 Aug 2012 13:21:21 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CO1EHSMHS022.bigfish.com (10.243.66.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 Aug 2012 13:21:21 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 0F86623211DD for ; Tue, 21 Aug 2012 06:20:22 -0700 (PDT) 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 6D19B23211D9; Tue, 21 Aug 2012 06:20:21 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Aug 2012 06:23:02 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Tue, 21 Aug 2012 06:21:19 -0700 From: Adam Montville To: Anton Chuvakin , "david.oliva@verizon.net" Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: AQHNewM88Ifx3EnyRsGzJUOVORn/rZdjp9wAgAChzoA= Date: Tue, 21 Aug 2012 13:21:18 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <3A793270788FCD4386F3DD2C6BD90AE3@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: 39c6c458-a0de-4044-b6bd-76c610c43412 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: "shanna@juniper.net" , "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 13:21:25 -0000 On 8/20/12 1:42 PM, "Anton Chuvakin" wrote: >>For UC3, I cannot see which spec in SCAP 1.2 to associate with network >>events. The only thing close to a spec that approaches this criterion is >>the Common Events Enumeration (CEE) that Dr. Chuvakin is working on. There isn't one, and from the "traditional" security automation world (a la NIST/MITRE/etc.), we have CEE. From outside that universe, there are others - CEF, XDAS come to mind. >>In a short question to Dr. Chuvakin about the possibility of CEE and SCAP >>working together he replied "CEE can work with SCAP via OVAL, CPE, AI and >>ARF to report events identifying the affected assets in a standard way". >> If CEE is part >>of a future SACM version, then yes. > >Well, CEE (now in beta at http://cee.mitre.org/language/1.0-beta1/) >can and should definitely be used by SACM. There is nothing (in my >view) that makes it not usable by SACM, EMAP, etc, etc. I agree, Anton.=20 > >However, if SACM turns to reinventing/redefining its own log/event >standard, than it will have one very angry and nasty enemy :-) With CEE, CEF, and XDAS out there, it doesn't make any sense to create something else (caveat: http://xkcd.com/927/). From amontville@tripwire.com Tue Aug 21 06:32: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 60D6521F8634 for ; Tue, 21 Aug 2012 06:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.434 X-Spam-Level: X-Spam-Status: No, score=-5.434 tagged_above=-999 required=5 tests=[AWL=1.165, 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 d3Ip4dZvxgYJ for ; Tue, 21 Aug 2012 06:32:08 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC7D21F8644 for ; Tue, 21 Aug 2012 06:32:08 -0700 (PDT) Received: from mail274-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 Aug 2012 13:32:07 +0000 Received: from mail274-tx2 (localhost [127.0.0.1]) by mail274-tx2-R.bigfish.com (Postfix) with ESMTP id BB03E3401FF for ; Tue, 21 Aug 2012 13:32:07 +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: VPS-3(zzbb2dI98dI9371Izz1202hzz8275bhz2dh2a8h668h839h946he5bhf0ah107ah) Received: from mail274-tx2 (localhost.localdomain [127.0.0.1]) by mail274-tx2 (MessageSwitch) id 134555590274607_15952; Tue, 21 Aug 2012 13:31:42 +0000 (UTC) Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.239]) by mail274-tx2.bigfish.com (Postfix) with ESMTP id 1A5DE740099 for ; Tue, 21 Aug 2012 13:31:28 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 Aug 2012 13:31:27 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 6ECD723211DD for ; Tue, 21 Aug 2012 06:30:27 -0700 (PDT) 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 D01F323211D9; Tue, 21 Aug 2012 06:30:26 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Aug 2012 06:33:07 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Tue, 21 Aug 2012 06:31:24 -0700 From: Adam Montville To: "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwgAGFQsxAAAviVgACqobYAAABHYYAAFclbAA== Date: Tue, 21 Aug 2012 13:31:24 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="Windows-1252" Content-ID: <00F2110D8D0D3C49A0D7003930F9C2E1@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: 289152ad-f214-4c15-a1bf-2ac734d466d1 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: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 13:32:11 -0000 On 8/20/12 1:07 PM, "Kent_Landfield@McAfee.com" wrote: >In addition to the remediation question=8A. I know we talked about the >applicability of this work being targeted at the enterprise. SOHO can be >an extension of the enterprise but I get the feeling from rereading >traffic that SOHO should not be included in the charterapplicability and >we should focus ONLY on the enterprise=8A I would like to keep initial on the enterprise, only because I don't feel that we've completed the necessary work there for real automated configuration assessments, let alone continuous monitoring. Still, SOHO (and the related BYOD issues) is a hard problem, and we could keep it there - it's important for every enterprise of size, really, and could be equally important for the "little guy." I don't object to the SOHO language in the most recent charter proposal you send out, Kent. The deliverables are still the same, really. From lnunez@c3isecurity.com Tue Aug 21 06:41:44 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D78021F8661 for ; Tue, 21 Aug 2012 06:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.622 X-Spam-Level: X-Spam-Status: No, score=-3.622 tagged_above=-999 required=5 tests=[AWL=-0.023, 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 Wd64rud+-PeK for ; Tue, 21 Aug 2012 06:41:43 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 917A121F8564 for ; Tue, 21 Aug 2012 06:41:43 -0700 (PDT) Received: by ghbg16 with SMTP id g16so6414906ghb.31 for ; Tue, 21 Aug 2012 06:41:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ikq8dczDaq6+Fve7llBJROZ7LDhyFESIKd88t7l0W3M=; b=nLEgFuKTC9x0JGbQ3xfuYfCInNDeqdiaYV2JvosOUCVdkFiJ0uX1HKm3iQXW7kJr6D 2+zUShDKlKAnIL5DrBDcFIvytYG7L/548L+I0YPnn9etZ2wqOdRxMIJwz86Z+8mR6CE0 bxrPnxLHMD/BMSIo03vVao1OsyAkUSgBJBGTPoWnFbRis4EVLM3C+m0/6m0vyMbsYDW8 MAmPu6sIFEP/F68wVrE06r2cAwwAVoGAIuzTChje9PoTcLuFEFCkBcOOwQJwPZwENcsK Vz32Rz5TShMmVhsWnl/cloTXCRFWQfInvSE5QIv1hQ/bVKrrZ2lweK1v1BaAN8ghPVaO /1Wg== Received: by 10.236.161.195 with SMTP id w43mr25404824yhk.42.1345556503028; Tue, 21 Aug 2012 06:41:43 -0700 (PDT) Received: from [192.168.1.22] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id k22sm1183950ann.1.2012.08.21.06.41.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Aug 2012 06:41:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Luis Nunez In-Reply-To: Date: Tue, 21 Aug 2012 09:41:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adam Montville X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlXKrzb5AW4q+4HY4gChdplnBZTLpw6nG9cC5MA9s+zGSGrNFMzS5Ck6OCXMVyWeKwy2r+l Cc: "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 13:41:44 -0000 I agree with Adam. We first need a foundation from which to expand the = uses cases. The Enterprise use case could be the basis for others: = SOHO, Data Center, Virtualization, Mobile, etc. -ln On Aug 21, 2012, at 9:31 AM, Adam Montville wrote: > On 8/20/12 1:07 PM, "Kent_Landfield@McAfee.com" > wrote: >=20 >> In addition to the remediation question=8A. I know we talked about = the >> applicability of this work being targeted at the enterprise. SOHO = can be >> an extension of the enterprise but I get the feeling from rereading >> traffic that SOHO should not be included in the charterapplicability = and >> we should focus ONLY on the enterprise=8A >=20 >=20 >=20 > I would like to keep initial on the enterprise, only because I don't = feel > that we've completed the necessary work there for real automated > configuration assessments, let alone continuous monitoring. >=20 > Still, SOHO (and the related BYOD issues) is a hard problem, and we = could > keep it there - it's important for every enterprise of size, really, = and > could be equally important for the "little guy." >=20 > I don't object to the SOHO language in the most recent charter = proposal > you send out, Kent. The deliverables are still the same, really. >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From amontville@tripwire.com Tue Aug 21 07:11:24 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C857C21F86A4 for ; Tue, 21 Aug 2012 07:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[AWL=-0.361, 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 w7E+ftzb8jSR for ; Tue, 21 Aug 2012 07:11:23 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 365B621F86A2 for ; Tue, 21 Aug 2012 07:11:23 -0700 (PDT) Received: from mail128-co1-R.bigfish.com (10.243.78.250) by CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 Aug 2012 14:11:22 +0000 Received: from mail128-co1 (localhost [127.0.0.1]) by mail128-co1-R.bigfish.com (Postfix) with ESMTP id 17F532047B for ; Tue, 21 Aug 2012 14:11:22 +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: -42 X-BigFish: VPS-42(zzbb2dI98dI9371I1503M168aJ542M1432I1455M4015Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h946he5bhf0ah107ah) Received: from mail128-co1 (localhost.localdomain [127.0.0.1]) by mail128-co1 (MessageSwitch) id 1345558279450760_21087; Tue, 21 Aug 2012 14:11:19 +0000 (UTC) Received: from CO1EHSMHS010.bigfish.com (unknown [10.243.78.238]) by mail128-co1.bigfish.com (Postfix) with ESMTP id 62A64A80046 for ; Tue, 21 Aug 2012 14:11:19 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CO1EHSMHS010.bigfish.com (10.243.66.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 Aug 2012 14:11:19 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id BB7D823211DD for ; Tue, 21 Aug 2012 07:10:19 -0700 (PDT) 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 0F47623211D8; Tue, 21 Aug 2012 07:10:19 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Aug 2012 07:13:00 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Tue, 21 Aug 2012 07:11:17 -0700 From: Adam Montville To: "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwgAGFQsxAAAviVgACqobYAABd1KwA= Date: Tue, 21 Aug 2012 14:11:16 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="Windows-1252" Content-ID: <8DEBB46A1A24C345BA320299D150D948@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: 077ee10e-7685-4819-9796-dedd3e245fed 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: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 14:11:25 -0000 On 8/20/12 12:59 PM, "Kent_Landfield@McAfee.com" wrote: >One question that I did have is the draft charter talks about >remediation. What are other's thoughts on including that as a >'potential' for the work to be done under SACM? I would like to see it included. We may need to rethink some of the work that has already been done in this area. Maybe we start by providing some way to standardize the minimum set of information that should be represented in manual remediation instructions before we move on to automated remediation - essentially, walk before we run. > >--------------------------------- >Security Automation Continuous Monitoring (SACM) > > >Proposed Working Group Charter > > >Chairs: >TBD >TBD > > >Security Area Directors: > Stephen Farrell > Sean Turner > > >Security Area Advisor: > Sean Turner > > >Mailing Lists: > General Discussion: sacm@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/sacm > Archive: http://www.ietf.org/mail-archive/web/sacm > > >Description of Working Group > > >Securing information and the systems that store, process, and transmit >that information has become a challenging task for organizations of all >sizes, and we find that security practitioners spend most of their time >on manual processes relegating them to > ineffectiveness. Security automation is the key to escaping this rut. >This working group will develop security automation standards in support >of information security processes and practices where practical. These >standards will support security practitioners > to be better utilized within their organizations by allowing them to >meet the more advanced needs of the security community (e.g. information >sharing, continuous monitoring, remediation and response, result >aggregation and analysis). The initial focus of this > work is to address enterprise and SOHO use cases. The working group will >achieve this by consuming and continuing (with cooperation) the security >automation work already performed by various organizations around the >world. > > >The initial work has been fruitful, and the data formats previously >published are ready for expansion on the international stage. Of >particular interest to this working group are the security automation >specifications supporting asset, change, configuration, > and vulnerability management. Of additional interest to this working >group are the emerging security automation interfaces and data formats >relating to event management and continuous monitoring. > > >By undertaking this work, we recognize that there are multiple categories >of problems in the security automation domain: defining expressions for >particular domain concepts (i.e. data formats), establishing a >standards-based foundation supporting the curation > and exchange of security automation content collections in content >repositories and enabling interoperability through the development and >use of interfaces and communications protocols. Content based on rich >data standards and protocols will provide the authoritative > instructions needed by data-driven tools to enable the automated >collection and exchange of configuration and vulnerability data >pertaining to enterprise assets. Information produced by these tools will >provide accurate and timely situational awareness in > support of organizational decision making. > > >This working group will provide solutions to these categories of problems >and the main areas of focus for this working group are described as >follows: > > >1. Define, either by normative reference, adoption, or creation, a set of >standards that can be used for the purpose of assessing, aggregating and >comparing device states against expected values, and reporting on those >results in a predefined or ad hoc > manner. >=20 > > >2. Define, either by normative reference, adoption, or creation, a set of >standards that can be used to continuously monitor and report on the >state of systems, composed of many different types of devices and >networks, operated by varying personnel, to > ensure security process effectiveness in a pre-defined or ad-hoc manner. > > >3. Create relationships between existing operations management standards >to enable a comprehensive view of security automation, leveraging >existing work and implementations. At some point I believe we had a 4 and 5 here as well. I can't remember, were those recommended to be removed? Otherwise, I agree with the three "main" areas of focus. > > >This working group will produce the following: > > >* An Informational document providing an overview of security automation >and continuous monitoring to include a reference model Is this a reference to the use case document or something else (I.e. the informational document I've talked about in the past)? >* A Standards Track document specifying benchmark configuration >representation (XCCDF) >* An Informational document stating guidelines / requirements for >specifying checking languages >* Standards Track documents specifying device state checking languages >(OVAL, ECL, ACEML, =8A) >* A Standards Track document specifying an interrogative checking >language (OCIL) >* A Standards Track document specifying platform naming, matching and >applicability (CPE) >* Standards Track documents specifying asset identification and reporting >information (Asset ID, ARF) >* Standards Track documents specifying interfaces and communication >protocols used for security automation and continuous monitoring >* A Standards Track document describing the messages and network >protocols for distributing Security Automation Content (content >repository) I would remove the word "network" from "network protocols." >* Standards Track document describing integrating security automation and >Network Endpoint Assessment capabilities (if-m for SCAP?) >* A Standards Track document describing protocols and data formats for >securely sharing dynamic network state information among security systems >(if-map) I was working on some thought exercises yesterday for the Use Case document, and I think we might have some gaps in existing capabilities that we should address (either through normative reference or by creating something new): 1. Do we need a way to identify, express, and perhaps score patches in a way that differs from vulnerabilities? This may be something akin to CPE - perhaps an extension to it. 2. Should we consider breaking apart the constituents of a technical control checking system in a way that allows us to talk about security and non-security related system objects? There are almost certainly ties to other areas of IETF and perhaps other SDOs here, but I can use OVAL as a frame of reference. OVAL talks about definitions, tests, objects, states, and values (ultimately assigned to states). Is there a need to talk about objects, and their applicable range of states, outside the context of what we would generically call a test? 3. Do we need a way to talk about assets in a non-identifying way? I'm thinking things like criticality, classification (I.e. level of secrecy), and other properties that may not necessarily be used for the purposes of identification? 4. Do we need to consider documents dealing with targeting issues? These four points essentially speak to functional components that may be lacking in the existing set of specifications/formats. It is my expectation that the Use Case document will identify and highlight such gaps, where we know we need certain functional capabilities (security configuration management including configuration assessment and remediation, asset characterization/management, and vulnerability assessment, perhaps among others). > > >Goals and Milestones > > >TBD >-------------------------------------------- > > > > > >Thanks. > > >Kent Landfield > >McAfee | An Intel Company >Direct: +1.972.963.7096 >Mobile: +1.817.637.8026 >Web: www.mcafee.com > > > > > >From: Adam Montville >Date: Friday, August 17, 2012 12:33 PM >To: David Waltermire , Stephen Hanna >, Luis Nunez , > Omar Santos >Cc: "sacm@ietf.org" >Subject: Re: [sacm] Proposed use cases to move forward > > > >>I like taking the scope down as well - and I think we all believe we've >>agreed to UC1 and UC3. I don't have an issue having the other use cases >>(2, 4, and 5) described in the use case document, but not fleshed out in >>the functional capabilities, components, and data/protocol sections. The >>charter can be derived from the use cases we take on, and a separate >>informational document can help place those use cases in the right >>context >>with respect to the "grand scheme of things." >> >> >>No matter how we slice it, right now we need to focus on the use cases >>and >>charter, and to focus on the use cases we would ideally need to work on >>setting the context. I've tried to do that (to a limited extent) with >>the >>informational document I sent to the list. >> >> >>Additionally, I think these efforts need to be done in parallel >>irrespective of any idealistic dependencies. For example, we should be >>able to work on a charter, a use case doc, and an informational doc all >>at >>the same time, but join the threads for a final alignment pass before >>submitting them. >> >> >>Adam >> >> >>On 8/17/12 9:30 AM, "Waltermire, David A." >>wrote: >> >> >>>Steve, >>> >>> >>>These are all valid concerns that I completely agree with. What I am >>>struggling with is insuring that the work we are embarking on remains >>>relevant in the broader context. My fear is that if we narrow our >>>thinking too much, we may inadvertently make decisions that drift from >>>addressing the broader set of use cases. I like the idea of working on >>>an individual draft to address the larger context. What I am not sure >>>about is how introduce a feedback loop that would result in minimizing >>>this kind of risk. I guess this type of issue is something that we will >>>need to collectively monitor and address as needed. >>> >>> >>>Sincerely, >>>Dave >>> >>> >>> >>> >>>-----Original Message----- >>>From: Stephen Hanna [mailto:shanna@juniper.net] >>>Sent: Wednesday, August 15, 2012 3:55 PM >>>To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos >>>Cc: sacm@ietf.org >>>Subject: RE: [sacm] Proposed use cases to move forward >>> >>> >>>I love broad scope. Don't get me wrong! But I'm concerned about having a >>>use cases document and an architecture document for this working group >>>that goes way beyond the charter and initial scope for the group. >>> >>> >>>I'm concerned that this will lead to lots of discussions on the sacm >>>list >>>and lots of effort being spent on topics that are out of scope, >>>diverting >>>us from the tasks at hand and slowing our progress. >>> >>> >>>I'm concerned that the working group chairs won't be able to cut off >>>discussion of topics by saying they're out of scope for the working >>>group. >>> >>> >>>I'm concerned that we'll get sidetracked or even derailed by >>>controversies that aren't relevant to the scope of the group. >>> >>> >>>I'm concerned that by including all of security automation within our >>>use >>>cases and architecture, we may actually prevent the formation of other >>>working groups that could work on those other use cases. >>> >>> >>>We have plenty of work to keep us busy for years with UC1 and UC3. >>>There's agreement that the technology needed is mature enough for IETF >>>standardization. I suggest that we scope this working group to address >>>only those use cases and that our use cases and architecture be limited >>>to them. >>> >>> >>>I'm sorely tempted to create an ambitious architecture for security >>>automation that encompasses all of the use cases that we have described >>>so far and maybe more. I understand that people have a hard time >>>understanding how the NEA and MILE and SACM standards fit together and I >>>would love to address that in an IETF RFC. But I have seen several grand >>>architecture efforts die or come to nothing in IETF. IETF is filled with >>>smart engineers with clever ideas. We're great at solving problems but >>>if >>>we can't agree on the problem to solve or if we choose the wrong >>>problem, >>>we can easily spin an intricate and pointless web. >>> >>> >>>I think we'll do better if we scope our effort properly. >>> >>> >>>Maybe a few people can create an individual submission describing a >>>grand >>>architecture and roadmap for security automation and ask people in SACM >>>to review and provide feedback on that document. That would be a good >>>way >>>to get a grand architecture while still ensuring that the SACM effort >>>keeps its focus. In IETF as in so many things, you must keep your focus >>>or you'll never succeed. >>> >>> >>>Thanks, >>> >>> >>>Steve >>> >>> >>>>-----Original Message----- >>>>From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >>>>Of Waltermire, David A. >>>>Sent: Wednesday, August 15, 2012 1:13 PM >>>>To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos >>>>Cc: sacm@ietf.org >>>>Subject: Re: [sacm] Proposed use cases to move forward >>>>+1 on scoping the charter to UC1 and UC3. >>>>I think we are better served with a use cases document, and eventually >>>>an architecture documemnt, that is broader scoped. Both of these >>>>documents will help inform the work we will do under the charter as it >>>>relates to the larger context. >>>>To this end I would suggest we focus on expanding the use case >>>>document primarily in the areas of UC1 and UC3 for now. We can expand >>>>the other use cases later. >>>>Sincerely, >>>>Dave >>>>> -----Original Message----- >>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >>>>Of >>>>> Stephen Hanna >>>>> Sent: Wednesday, August 15, 2012 11:24 AM >>>>> To: Adam Montville; Luis Nunez; Omar Santos >>>>> Cc: sacm@ietf.org >>>>> Subject: Re: [sacm] Proposed use cases to move forward >>>>> >>>>> I agree. Let's work on UC1 and UC3. The other use cases are valuable >>>>> but just doing UC1 and UC3 is plenty of work for this group for the >>>>> next year or two (maybe five!). >>>>> >>>>> I saw several emails in favor of this a few weeks ago. I thought >>>>> that it was settled. I'd like to see a revised charter and use case >>>>> document, scoped down to focus on just UC1 and UC3. >>>>> >>>>> What do others think? Do we have rough consensus on this? >>>>> If so, let's get moving. >>>>> >>>>> Thanks, >>>>> >>>>> Steve >>>>> >>>>> > -----Original Message----- >>>>> > From: Adam Montville [mailto:amontville@tripwire.com] >>>>> > Sent: Wednesday, August 15, 2012 10:30 AM >>>>> > To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos >>>>> > Cc: sacm@ietf.org >>>>> > Subject: Re: [sacm] Proposed use cases to move forward >>>>> > >>>>> > On 8/6/12 7:27 AM, "Adam Montville" >>>>wrote: >>>>> > >>>>> > > >>>>> > > >>>>> > >UC1 and UC3 both require assessment of endpoint state. If not for >>>>> the >>>>> > NEA >>>>> > >ties in UC1, it seems a subset of UC3. So, we should be able to >>>>> > >start with the main concern of UC3: Security Configuration >>>>> Management. >>>>> > > >>>>> > > >>>>> > >>>>> > >>>>> > I haven't seen much activity on this thread (there was another >>>>> thread, >>>>> > "Using the Frame of Reference," discussing some approaches we can >>>>use >>>>> > to keep us focused and meaningful). >>>>> > >>>>> > Are there any objections to tackling UC3 followed by UC1? Does >>>>> anyone >>>>> > disagree with my assertion that UC3 is a subset of UC1 and that a >>>>> > reasonable starting point is Security Configuration Management? >>>>> > >>>>> >>>>> _______________________________________________ >>>>> sacm mailing list >>>>> sacm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>_______________________________________________ >>>>sacm mailing list >>>>sacm@ietf.org >>>>https://www.ietf.org/mailman/listinfo/sacm >>> >>> >>> >>> >> >> >> >> >> >> >>_______________________________________________ >>sacm mailing list >>sacm@ietf.org >>https://www.ietf.org/mailman/listinfo/sacm >> >> >> >> > From amontville@tripwire.com Tue Aug 21 07:13: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 9D97421F854E for ; Tue, 21 Aug 2012 07:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[AWL=-0.353, 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 AjZjQ1DE8g3J for ; Tue, 21 Aug 2012 07:13:53 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0A12421F845B for ; Tue, 21 Aug 2012 07:13:52 -0700 (PDT) Received: from mail69-ch1-R.bigfish.com (10.43.68.244) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 Aug 2012 14:13:52 +0000 Received: from mail69-ch1 (localhost [127.0.0.1]) by mail69-ch1-R.bigfish.com (Postfix) with ESMTP id 709354E02EC for ; Tue, 21 Aug 2012 14:13:52 +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: VPS-3(zzbb2dI98dI9371Izz1202hzz8275bhz2dh2a8h668h839h946he5bhf0ah107ah) Received: from mail69-ch1 (localhost.localdomain [127.0.0.1]) by mail69-ch1 (MessageSwitch) id 1345558430533831_22937; Tue, 21 Aug 2012 14:13:50 +0000 (UTC) Received: from CH1EHSMHS023.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail69-ch1.bigfish.com (Postfix) with ESMTP id 7EC6B4C00C0 for ; Tue, 21 Aug 2012 14:13:50 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 Aug 2012 14:13:47 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 923BB23211E0 for ; Tue, 21 Aug 2012 07:12:47 -0700 (PDT) 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 00DD823211D8; Tue, 21 Aug 2012 07:12:47 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Aug 2012 07:15:28 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Tue, 21 Aug 2012 07:13:45 -0700 From: Adam Montville To: "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwgAGFQsxAAAviVgACqobYAABeLE4A= Date: Tue, 21 Aug 2012 14:13:44 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="Windows-1252" Content-ID: <8838A490D249214AA4138C9D3D40AB97@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: 77712a9a-2d3e-44eb-8471-83a28153c388 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: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 14:13:53 -0000 On 8/20/12 12:59 PM, "Kent_Landfield@McAfee.com" wrote: >As a point of reference, how does the list want to see differences from >one version of the charter to the next? Let's keep it simple if possible= =8A Do more experienced IETFers have any suggestions? It seems that we'll just have to keep track of these things from "round to round" in the e-mail list. Kent just sent out a proposal, it'll have a period of comment/review, then he'll probably post another draft. =20 From Kent_Landfield@mcafee.com Tue Aug 21 07:15: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 530E121F867D for ; Tue, 21 Aug 2012 07:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.082, 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 zo+Wwqbw7jQa for ; Tue, 21 Aug 2012 07:15:08 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 8464321F8647 for ; Tue, 21 Aug 2012 07:15:08 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 4e25_5812_036f3cbd_7eb2_4468_b8d9_59d120394dce; Tue, 21 Aug 2012 09:14:55 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Tue, 21 Aug 2012 09:13:00 -0500 From: To: , Date: Tue, 21 Aug 2012 09:14:04 -0500 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1/pxIx/YCVuyaAQnui8q5Owegztg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC5900B13A9E4kentlandfieldmcafeecom_" MIME-Version: 1.0 Cc: sacm@ietf.org Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 14:15:09 -0000 --_000_CC5900B13A9E4kentlandfieldmcafeecom_ Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable So are we talking about removing the SOHO aspects from the charter for now?= I have no problem with that as it would help us to focus on the base ente= rprise capabilities. If that's the direction, we could recharter down the = road once we are successful with the enterprise uses. I would personally rather have this charter more focused on what we are act= ually going to work on now and we can decide if we need to expand it in the= future=85 Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Luis Nunez > Date: Tuesday, August 21, 2012 8:41 AM To: Adam Montville = > Cc: Kent Landfield >, "sacm@ietf.org" > Subject: Re: [sacm] Proposed use cases to move forward I agree with Adam. We first need a foundation from which to expand the use= s cases. The Enterprise use case could be the basis for others: SOHO, Data= Center, Virtualization, Mobile, etc. -ln On Aug 21, 2012, at 9:31 AM, Adam Montville wrote: On 8/20/12 1:07 PM, "Kent_Landfield@McAfee.com" > wrote: In addition to the remediation question=8A. I know we talked about the applicability of this work being targeted at the enterprise. SOHO can be an extension of the enterprise but I get the feeling from rereading traffic that SOHO should not be included in the charterapplicability and we should focus ONLY on the enterprise=8A I would like to keep initial on the enterprise, only because I don't feel that we've completed the necessary work there for real automated configuration assessments, let alone continuous monitoring. Still, SOHO (and the related BYOD issues) is a hard problem, and we could keep it there - it's important for every enterprise of size, really, and could be equally important for the "little guy." I don't object to the SOHO language in the most recent charter proposal you send out, Kent. The deliverables are still the same, really. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_CC5900B13A9E4kentlandfieldmcafeecom_ Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
So are we t= alking about removing the SOHO aspects from the charter for now?  I ha= ve no problem with that as it would help us to focus on the base enterprise= capabilities.  If that's the direction, we could recharter down the r= oad once we are successful with the enterprise uses.

I would personally rather have this charter more focused on what we= are actually going to work on now and we can decide if we need to expand i= t in the future=85

Kent Landfield

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

Fro= m: Luis Nunez <lnunez@= c3isecurity.com>
Date: T= uesday, August 21, 2012 8:41 AM
To: Adam Montville <amontvil= le@tripwire.com>
Cc: Ken= t Landfield <Kent_Landfield= @McAfee.com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Proposed use cases= to move forward

I agree with Adam.  We first nee= d a foundation from which to expand the uses cases.  The Enterpri= se use case could be the basis for others: SOHO, Data Center, Virtualizatio= n, Mobile, etc.

-ln

On Au= g 21, 2012, at 9:31 AM, Adam Montville wrote:

On 8/20/12 1:07 PM, "= Kent_Landfield@McAfee.com&= quot;
In addition to the remediation question=8A.=   I know we talked about the
applicability of this wor= k being targeted at the enterprise.  SOHO can be
an ex= tension of the enterprise but I get the feeling from rereading
t= raffic that SOHO should not be included in the charterapplicability and
we should focus ONLY on the enterprise=8A
<= /div>
I would like to keep initial on the ente= rprise, only because I don't feel
that we've completed the neces= sary work there for real automated
configuration assessments, le= t alone continuous monitoring.
Still, SOHO (and the = related BYOD issues) is a hard problem, and we could
keep it the= re - it's important for every enterprise of size, really, and
co= uld be equally important for the "little guy."
<= div> I don't object to the SOHO language in the most recent charter proposa= l
you send out, Kent.  The deliverables are still the = same, really.
______________= _________________________________
sacm mailing list
<= a href=3D"mailto:sacm@ietf.org">sacm@ietf.org


--_000_CC5900B13A9E4kentlandfieldmcafeecom_-- From amontville@tripwire.com Tue Aug 21 07:21: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 F011121F86B9 for ; Tue, 21 Aug 2012 07:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.945 X-Spam-Level: X-Spam-Status: No, score=-3.945 tagged_above=-999 required=5 tests=[AWL=-0.346, 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 0OpUDZvd4300 for ; Tue, 21 Aug 2012 07:21:15 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2B83C21F86B4 for ; Tue, 21 Aug 2012 07:21:15 -0700 (PDT) Received: from mail59-va3-R.bigfish.com (10.7.14.240) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 Aug 2012 14:21:13 +0000 Received: from mail59-va3 (localhost [127.0.0.1]) by mail59-va3-R.bigfish.com (Postfix) with ESMTP id 3DC6A2200FE for ; Tue, 21 Aug 2012 14:21:13 +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: VPS-3(zzbb2dI98dI9371Izz1202hzz8275bhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail59-va3 (localhost.localdomain [127.0.0.1]) by mail59-va3 (MessageSwitch) id 1345558863608506_21203; Tue, 21 Aug 2012 14:21:03 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.239]) by mail59-va3.bigfish.com (Postfix) with ESMTP id 889F92000A1 for ; Tue, 21 Aug 2012 14:21:03 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 Aug 2012 14:21:01 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id A2A7823211DD for ; Tue, 21 Aug 2012 07:20:01 -0700 (PDT) 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 0D3E723211D8; Tue, 21 Aug 2012 07:20:01 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Aug 2012 07:22:42 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Tue, 21 Aug 2012 07:20:59 -0700 From: Adam Montville To: "Kent_Landfield@McAfee.com" , "lnunez@c3isecurity.com" Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwgAGFQsxAAAviVgACqobYAAABHYYAAFclbAAAPBpYAAAEh+gD//4yQAA== Date: Tue, 21 Aug 2012 14:20:59 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.16.97.35] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <3CBBB3995F99A94A9F6B94DEBFDC8D7B@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: 0ed8c9d8-bacf-4834-9cce-b82f3d099ec6 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] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 14:21:16 -0000 On 8/21/12 7:14 AM, "Kent_Landfield@McAfee.com" wrote: >So are we talking about removing the SOHO aspects from the charter for >now? I am not, but I am not opposed to its removal. It depends on what others feel. As I tried to convey, perhaps poorly, whether the term "SOHO" is included in the prose of the charter seems inconsequential to the documents we want to deliver - at their core, they are still the same documents. That said, if taking SOHO out seems to be the right thing to do, I'm not opposed to its removal. From shanna@juniper.net Tue Aug 21 07:46: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 7D1A021F86A4 for ; Tue, 21 Aug 2012 07:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.554 X-Spam-Level: X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 rhgbu1E6DNvF for ; Tue, 21 Aug 2012 07:46:05 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id EE5BB21F853E for ; Tue, 21 Aug 2012 07:46:02 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUDOfKcZTnHxTQRoSAHbpdPsQZPVWnN+0@postini.com; Tue, 21 Aug 2012 07:46:05 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 21 Aug 2012 07:45:15 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 21 Aug 2012 10:44:55 -0400 From: Stephen Hanna To: Adam Montville , "Kent_Landfield@McAfee.com" , "lnunez@c3isecurity.com" Date: Tue, 21 Aug 2012 10:44:53 -0400 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwgAGFQsxAAAviVgACqobYAAABHYYAAFclbAAAPBpYAAAEh+gD//4yQAP//+3Ow 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 14:46:06 -0000 I favor removing the SOHO use cases from the charter and focusing only on enterprise use cases for now. SOHO adds many complications, both technical and political. We should walk first before we try to run. There's plenty of value in standards for enterprise security automation and plenty of work for us to do just in addressing the enterprise use cases. If we design in extensibility, these standards can be extended later to cover SOHO. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Tuesday, August 21, 2012 10:21 AM > To: Kent_Landfield@McAfee.com; lnunez@c3isecurity.com > Cc: sacm@ietf.org > Subject: Re: [sacm] Proposed use cases to move forward >=20 > On 8/21/12 7:14 AM, "Kent_Landfield@McAfee.com" > wrote: >=20 > >So are we talking about removing the SOHO aspects from the charter for > >now? >=20 >=20 >=20 > I am not, but I am not opposed to its removal. It depends on what > others > feel. As I tried to convey, perhaps poorly, whether the term "SOHO" is > included in the prose of the charter seems inconsequential to the > documents we want to deliver - at their core, they are still the same > documents. >=20 > That said, if taking SOHO out seems to be the right thing to do, I'm > not > opposed to its removal. >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From lnunez@c3isecurity.com Tue Aug 21 07:48:00 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9E221F8505 for ; Tue, 21 Aug 2012 07:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.621 X-Spam-Level: X-Spam-Status: No, score=-3.621 tagged_above=-999 required=5 tests=[AWL=-0.022, 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 FBIXdITCTY2V for ; Tue, 21 Aug 2012 07:48:00 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B92E021F84A5 for ; Tue, 21 Aug 2012 07:47:59 -0700 (PDT) Received: by ggnh4 with SMTP id h4so6497712ggn.31 for ; Tue, 21 Aug 2012 07:47:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=NOxF8hFpM3o+TGFo8xawEUktxVQ1OphKwYYletwXEEs=; b=NWrdVavWq8Naj6Upv+/Og53/Z07owWu8FzO5K19eC3/Ul/HkNSuFZuJLOVuEYJXDwk M3NJJf2uB9U9iJilEZ1NeuDPOrbtQz5c6AHY6WyqXsTAVtIyQ2ZaqYqvu0Vs3Ry08MIN +GOWiDRpjBPQQWw3/VBBEcQUM/o/5xTsWQsRYQSHzGGO+Bz0iFqt28nV6nMp/U8JGxyU 6jHotIOD06vykp/CmqyfncZdpTXfiSQhlcXQmgs5EdiwFQR93DXQM+P+v9xYMEplSzvn Uy8OW29UXnlbnBNIxmxsI4rlyFqmtec1NmLGXiZBPvwo2sDKwFqiJ8FQ4KN9pWr7VdY0 /Upg== Received: by 10.100.83.2 with SMTP id g2mr7897114anb.15.1345560475923; Tue, 21 Aug 2012 07:47:55 -0700 (PDT) Received: from [192.168.1.22] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id r25sm2834487yhi.13.2012.08.21.07.47.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Aug 2012 07:47:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Luis Nunez In-Reply-To: Date: Tue, 21 Aug 2012 10:47:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <541D5010-911B-452E-9AC9-7BC9F200F85D@c3isecurity.com> References: To: Adam Montville X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnlt+36MRT3fhbQffImriWT/9azJtsFJW7/C6xwrE1Fa7qZCiQXSli0dtS1r5WLLRegAFKq Cc: "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 14:48:00 -0000 I would suggest removing SOHO for focus and clarity. I think we can = expand and extend the Enterprise to include(connect) to SOHO later. =20 thanks. -ln On Aug 21, 2012, at 10:20 AM, Adam Montville wrote: > On 8/21/12 7:14 AM, "Kent_Landfield@McAfee.com" > wrote: >=20 >> So are we talking about removing the SOHO aspects from the charter = for >> now? >=20 >=20 >=20 > I am not, but I am not opposed to its removal. It depends on what = others > feel. As I tried to convey, perhaps poorly, whether the term "SOHO" = is > included in the prose of the charter seems inconsequential to the > documents we want to deliver - at their core, they are still the same > documents. >=20 > That said, if taking SOHO out seems to be the right thing to do, I'm = not > opposed to its removal. >=20 >=20 >=20 From shanna@juniper.net Tue Aug 21 07:55:18 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4827C21F865C for ; Tue, 21 Aug 2012 07:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 0TUoqWpB56cW for ; Tue, 21 Aug 2012 07:55:16 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id A905D21F8686 for ; Tue, 21 Aug 2012 07:55:16 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUDOhU63esi5wyPOCC7wjFJZ26XLNMn8S@postini.com; Tue, 21 Aug 2012 07:55:16 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 21 Aug 2012 07:54:52 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Aug 2012 07:54:16 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 21 Aug 2012 10:53:55 -0400 From: Stephen Hanna To: Adam Montville , "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Date: Tue, 21 Aug 2012 10:53:54 -0400 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwgAGFQsxAAAviVgACqobYAABd1KwAAAOIbcA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 14:55:18 -0000 In the current charter, I see 3 areas of focus, 2 Informational documents, and at least 9 Standards Track documents. That's more than one Working Group should be taking on at one time. We need to focus on narrowing our scope not expanding it. Remediation is a great topic but we should not work on it in this (proposed) working group at this time. Instead, we should include hooks for sending remediation instructions (like the NEA Working Group did in PA-TNC) and encourage others to create and experiment with various remediation systems. When they have found something that works, we can bring it into SACM or just publish it straight as an RFC. At least, that's my view. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Tuesday, August 21, 2012 10:11 AM > To: Kent_Landfield@McAfee.com; sacm@ietf.org > Subject: Re: [sacm] Proposed use cases to move forward > > On 8/20/12 12:59 PM, "Kent_Landfield@McAfee.com" > wrote: > >One question that I did have is the draft charter talks about > >remediation. What are other's thoughts on including that as a > >'potential' for the work to be done under SACM? > > > > I would like to see it included. We may need to rethink some of the > work > that has already been done in this area. Maybe we start by providing > some > way to standardize the minimum set of information that should be > represented in manual remediation instructions before we move on to > automated remediation - essentially, walk before we run. > > > > > > >--------------------------------- > >Security Automation Continuous Monitoring (SACM) > > > > > >Proposed Working Group Charter > > > > > >Chairs: > >TBD > >TBD > > > > > >Security Area Directors: > > Stephen Farrell > > Sean Turner > > > > > >Security Area Advisor: > > Sean Turner > > > > > >Mailing Lists: > > General Discussion: sacm@ietf.org > > To Subscribe: http://www.ietf.org/mailman/listinfo/sacm > > Archive: http://www.ietf.org/mail-archive/web/sacm > > > > > >Description of Working Group > > > > > >Securing information and the systems that store, process, and transmit > >that information has become a challenging task for organizations of > all > >sizes, and we find that security practitioners spend most of their > time > >on manual processes relegating them to > > ineffectiveness. Security automation is the key to escaping this rut. > >This working group will develop security automation standards in > support > >of information security processes and practices where practical. These > >standards will support security practitioners > > to be better utilized within their organizations by allowing them to > >meet the more advanced needs of the security community (e.g. > information > >sharing, continuous monitoring, remediation and response, result > >aggregation and analysis). The initial focus of this > > work is to address enterprise and SOHO use cases. The working group > will > >achieve this by consuming and continuing (with cooperation) the > security > >automation work already performed by various organizations around the > >world. > > > > > >The initial work has been fruitful, and the data formats previously > >published are ready for expansion on the international stage. Of > >particular interest to this working group are the security automation > >specifications supporting asset, change, configuration, > > and vulnerability management. Of additional interest to this working > >group are the emerging security automation interfaces and data formats > >relating to event management and continuous monitoring. > > > > > >By undertaking this work, we recognize that there are multiple > categories > >of problems in the security automation domain: defining expressions > for > >particular domain concepts (i.e. data formats), establishing a > >standards-based foundation supporting the curation > > and exchange of security automation content collections in content > >repositories and enabling interoperability through the development and > >use of interfaces and communications protocols. Content based on rich > >data standards and protocols will provide the authoritative > > instructions needed by data-driven tools to enable the automated > >collection and exchange of configuration and vulnerability data > >pertaining to enterprise assets. Information produced by these tools > will > >provide accurate and timely situational awareness in > > support of organizational decision making. > > > > > >This working group will provide solutions to these categories of > problems > >and the main areas of focus for this working group are described as > >follows: > > > > > >1. Define, either by normative reference, adoption, or creation, a set > of > >standards that can be used for the purpose of assessing, aggregating > and > >comparing device states against expected values, and reporting on > those > >results in a predefined or ad hoc > > manner. > > > > > > > >2. Define, either by normative reference, adoption, or creation, a set > of > >standards that can be used to continuously monitor and report on the > >state of systems, composed of many different types of devices and > >networks, operated by varying personnel, to > > ensure security process effectiveness in a pre-defined or ad-hoc > manner. > > > > > >3. Create relationships between existing operations management > standards > >to enable a comprehensive view of security automation, leveraging > >existing work and implementations. > > > > At some point I believe we had a 4 and 5 here as well. I can't > remember, > were those recommended to be removed? > > Otherwise, I agree with the three "main" areas of focus. > > > > > > > > >This working group will produce the following: > > > > > >* An Informational document providing an overview of security > automation > >and continuous monitoring to include a reference model > > > Is this a reference to the use case document or something else (I.e. > the > informational document I've talked about in the past)? > > > > >* A Standards Track document specifying benchmark configuration > >representation (XCCDF) > >* An Informational document stating guidelines / requirements for > >specifying checking languages > >* Standards Track documents specifying device state checking languages > >(OVAL, ECL, ACEML, =A9) > >* A Standards Track document specifying an interrogative checking > >language (OCIL) > >* A Standards Track document specifying platform naming, matching and > >applicability (CPE) > >* Standards Track documents specifying asset identification and > reporting > >information (Asset ID, ARF) > >* Standards Track documents specifying interfaces and communication > >protocols used for security automation and continuous monitoring > >* A Standards Track document describing the messages and network > >protocols for distributing Security Automation Content (content > >repository) > > > I would remove the word "network" from "network protocols." > > > >* Standards Track document describing integrating security automation > and > >Network Endpoint Assessment capabilities (if-m for SCAP?) > >* A Standards Track document describing protocols and data formats for > >securely sharing dynamic network state information among security > systems > >(if-map) > > > > I was working on some thought exercises yesterday for the Use Case > document, and I think we might have some gaps in existing capabilities > that we should address (either through normative reference or by > creating > something new): > > 1. Do we need a way to identify, express, and perhaps score patches in > a > way that differs from vulnerabilities? This may be something akin to > CPE > - perhaps an extension to it. > > 2. Should we consider breaking apart the constituents of a technical > control checking system in a way that allows us to talk about security > and > non-security related system objects? There are almost certainly ties > to > other areas of IETF and perhaps other SDOs here, but I can use OVAL as > a > frame of reference. OVAL talks about definitions, tests, objects, > states, > and values (ultimately assigned to states). Is there a need to talk > about > objects, and their applicable range of states, outside the context of > what > we would generically call a test? > > 3. Do we need a way to talk about assets in a non-identifying way? I'm > thinking things like criticality, classification (I.e. level of > secrecy), > and other properties that may not necessarily be used for the purposes > of > identification? > > 4. Do we need to consider documents dealing with targeting issues? > > These four points essentially speak to functional components that may > be > lacking in the existing set of specifications/formats. It is my > expectation that the Use Case document will identify and highlight such > gaps, where we know we need certain functional capabilities (security > configuration management including configuration assessment and > remediation, asset characterization/management, and vulnerability > assessment, perhaps among others). > > > > > > > > > >Goals and Milestones > > > > > >TBD > >-------------------------------------------- > > > > > > > > > > > >Thanks. > > > > > >Kent Landfield > > > >McAfee | An Intel Company > >Direct: +1.972.963.7096 > >Mobile: +1.817.637.8026 > >Web: www.mcafee.com > > > > > > > > > > > >From: Adam Montville > >Date: Friday, August 17, 2012 12:33 PM > >To: David Waltermire , Stephen Hanna > >, Luis Nunez , > > Omar Santos > >Cc: "sacm@ietf.org" > >Subject: Re: [sacm] Proposed use cases to move forward > > > > > > > >>I like taking the scope down as well - and I think we all believe > we've > >>agreed to UC1 and UC3. I don't have an issue having the other use > cases > >>(2, 4, and 5) described in the use case document, but not fleshed out > in > >>the functional capabilities, components, and data/protocol sections. > The > >>charter can be derived from the use cases we take on, and a separate > >>informational document can help place those use cases in the right > >>context > >>with respect to the "grand scheme of things." > >> > >> > >>No matter how we slice it, right now we need to focus on the use > cases > >>and > >>charter, and to focus on the use cases we would ideally need to work > on > >>setting the context. I've tried to do that (to a limited extent) > with > >>the > >>informational document I sent to the list. > >> > >> > >>Additionally, I think these efforts need to be done in parallel > >>irrespective of any idealistic dependencies. For example, we should > be > >>able to work on a charter, a use case doc, and an informational doc > all > >>at > >>the same time, but join the threads for a final alignment pass before > >>submitting them. > >> > >> > >>Adam > >> > >> > >>On 8/17/12 9:30 AM, "Waltermire, David A." > > >>wrote: > >> > >> > >>>Steve, > >>> > >>> > >>>These are all valid concerns that I completely agree with. What I > am > >>>struggling with is insuring that the work we are embarking on > remains > >>>relevant in the broader context. My fear is that if we narrow our > >>>thinking too much, we may inadvertently make decisions that drift > from > >>>addressing the broader set of use cases. I like the idea of working > on > >>>an individual draft to address the larger context. What I am not > sure > >>>about is how introduce a feedback loop that would result in > minimizing > >>>this kind of risk. I guess this type of issue is something that we > will > >>>need to collectively monitor and address as needed. > >>> > >>> > >>>Sincerely, > >>>Dave > >>> > >>> > >>> > >>> > >>>-----Original Message----- > >>>From: Stephen Hanna [mailto:shanna@juniper.net] > >>>Sent: Wednesday, August 15, 2012 3:55 PM > >>>To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos > >>>Cc: sacm@ietf.org > >>>Subject: RE: [sacm] Proposed use cases to move forward > >>> > >>> > >>>I love broad scope. Don't get me wrong! But I'm concerned about > having a > >>>use cases document and an architecture document for this working > group > >>>that goes way beyond the charter and initial scope for the group. > >>> > >>> > >>>I'm concerned that this will lead to lots of discussions on the sacm > >>>list > >>>and lots of effort being spent on topics that are out of scope, > >>>diverting > >>>us from the tasks at hand and slowing our progress. > >>> > >>> > >>>I'm concerned that the working group chairs won't be able to cut off > >>>discussion of topics by saying they're out of scope for the working > >>>group. > >>> > >>> > >>>I'm concerned that we'll get sidetracked or even derailed by > >>>controversies that aren't relevant to the scope of the group. > >>> > >>> > >>>I'm concerned that by including all of security automation within > our > >>>use > >>>cases and architecture, we may actually prevent the formation of > other > >>>working groups that could work on those other use cases. > >>> > >>> > >>>We have plenty of work to keep us busy for years with UC1 and UC3. > >>>There's agreement that the technology needed is mature enough for > IETF > >>>standardization. I suggest that we scope this working group to > address > >>>only those use cases and that our use cases and architecture be > limited > >>>to them. > >>> > >>> > >>>I'm sorely tempted to create an ambitious architecture for security > >>>automation that encompasses all of the use cases that we have > described > >>>so far and maybe more. I understand that people have a hard time > >>>understanding how the NEA and MILE and SACM standards fit together > and I > >>>would love to address that in an IETF RFC. But I have seen several > grand > >>>architecture efforts die or come to nothing in IETF. IETF is filled > with > >>>smart engineers with clever ideas. We're great at solving problems > but > >>>if > >>>we can't agree on the problem to solve or if we choose the wrong > >>>problem, > >>>we can easily spin an intricate and pointless web. > >>> > >>> > >>>I think we'll do better if we scope our effort properly. > >>> > >>> > >>>Maybe a few people can create an individual submission describing a > >>>grand > >>>architecture and roadmap for security automation and ask people in > SACM > >>>to review and provide feedback on that document. That would be a > good > >>>way > >>>to get a grand architecture while still ensuring that the SACM > effort > >>>keeps its focus. In IETF as in so many things, you must keep your > focus > >>>or you'll never succeed. > >>> > >>> > >>>Thanks, > >>> > >>> > >>>Steve > >>> > >>> > >>>>-----Original Message----- > >>>>From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf > >>>>Of Waltermire, David A. > >>>>Sent: Wednesday, August 15, 2012 1:13 PM > >>>>To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos > >>>>Cc: sacm@ietf.org > >>>>Subject: Re: [sacm] Proposed use cases to move forward > >>>>+1 on scoping the charter to UC1 and UC3. > >>>>I think we are better served with a use cases document, and > eventually > >>>>an architecture documemnt, that is broader scoped. Both of these > >>>>documents will help inform the work we will do under the charter as > it > >>>>relates to the larger context. > >>>>To this end I would suggest we focus on expanding the use case > >>>>document primarily in the areas of UC1 and UC3 for now. We can > expand > >>>>the other use cases later. > >>>>Sincerely, > >>>>Dave > >>>>> -----Original Message----- > >>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf > >>>>Of > >>>>> Stephen Hanna > >>>>> Sent: Wednesday, August 15, 2012 11:24 AM > >>>>> To: Adam Montville; Luis Nunez; Omar Santos > >>>>> Cc: sacm@ietf.org > >>>>> Subject: Re: [sacm] Proposed use cases to move forward > >>>>> > >>>>> I agree. Let's work on UC1 and UC3. The other use cases are > valuable > >>>>> but just doing UC1 and UC3 is plenty of work for this group for > the > >>>>> next year or two (maybe five!). > >>>>> > >>>>> I saw several emails in favor of this a few weeks ago. I thought > >>>>> that it was settled. I'd like to see a revised charter and use > case > >>>>> document, scoped down to focus on just UC1 and UC3. > >>>>> > >>>>> What do others think? Do we have rough consensus on this? > >>>>> If so, let's get moving. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Steve > >>>>> > >>>>> > -----Original Message----- > >>>>> > From: Adam Montville [mailto:amontville@tripwire.com] > >>>>> > Sent: Wednesday, August 15, 2012 10:30 AM > >>>>> > To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos > >>>>> > Cc: sacm@ietf.org > >>>>> > Subject: Re: [sacm] Proposed use cases to move forward > >>>>> > > >>>>> > On 8/6/12 7:27 AM, "Adam Montville" > >>>>wrote: > >>>>> > > >>>>> > > > >>>>> > > > >>>>> > >UC1 and UC3 both require assessment of endpoint state. If not > for > >>>>> the > >>>>> > NEA > >>>>> > >ties in UC1, it seems a subset of UC3. So, we should be able > to > >>>>> > >start with the main concern of UC3: Security Configuration > >>>>> Management. > >>>>> > > > >>>>> > > > >>>>> > > >>>>> > > >>>>> > I haven't seen much activity on this thread (there was another > >>>>> thread, > >>>>> > "Using the Frame of Reference," discussing some approaches we > can > >>>>use > >>>>> > to keep us focused and meaningful). > >>>>> > > >>>>> > Are there any objections to tackling UC3 followed by UC1? Does > >>>>> anyone > >>>>> > disagree with my assertion that UC3 is a subset of UC1 and that > a > >>>>> > reasonable starting point is Security Configuration Management? > >>>>> > > >>>>> > >>>>> _______________________________________________ > >>>>> sacm mailing list > >>>>> sacm@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sacm > >>>>_______________________________________________ > >>>>sacm mailing list > >>>>sacm@ietf.org > >>>>https://www.ietf.org/mailman/listinfo/sacm > >>> > >>> > >>> > >>> > >> > >> > >> > >> > >> > >> > >>_______________________________________________ > >>sacm mailing list > >>sacm@ietf.org > >>https://www.ietf.org/mailman/listinfo/sacm > >> > >> > >> > >> > > > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From amontville@tripwire.com Tue Aug 21 07:58: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 827FF21F869D for ; Tue, 21 Aug 2012 07:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.937 X-Spam-Level: X-Spam-Status: No, score=-3.937 tagged_above=-999 required=5 tests=[AWL=-0.338, 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 6OPZVgMyqeuv for ; Tue, 21 Aug 2012 07:58:09 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9BA21F866C for ; Tue, 21 Aug 2012 07:58:02 -0700 (PDT) Received: from mail207-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 Aug 2012 14:58:02 +0000 Received: from mail207-va3 (localhost [127.0.0.1]) by mail207-va3-R.bigfish.com (Postfix) with ESMTP id 513644043A for ; Tue, 21 Aug 2012 14:58:02 +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: -42 X-BigFish: VPS-42(zzbb2dI98dI9371I1503M168aJ542M1432I1455M4015Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h946hd25he5bhf0ah107ah) Received: from mail207-va3 (localhost.localdomain [127.0.0.1]) by mail207-va3 (MessageSwitch) id 1345561079967999_19807; Tue, 21 Aug 2012 14:57:59 +0000 (UTC) Received: from VA3EHSMHS007.bigfish.com (unknown [10.7.14.247]) by mail207-va3.bigfish.com (Postfix) with ESMTP id E86D72C004A for ; Tue, 21 Aug 2012 14:57:59 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by VA3EHSMHS007.bigfish.com (10.7.99.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 Aug 2012 14:57:59 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id BCCC323211E0 for ; Tue, 21 Aug 2012 07:56:58 -0700 (PDT) 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 0E08B23211D9; Tue, 21 Aug 2012 07:56:58 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Aug 2012 07:59:39 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Tue, 21 Aug 2012 07:57:56 -0700 From: Adam Montville To: Stephen Hanna Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwgAGFQsxAAAviVgACqobYAABd1KwAAAOIbcAAAvwn5 Date: Tue, 21 Aug 2012 14:57:55 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: 1baf3b3b-89a0-43fd-9d33-5aa8f8218b46 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: "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 14:58:11 -0000 On Aug 21, 2012, at 7:55 AM, "Stephen Hanna" wrote: > In the current charter, I see 3 areas of focus, 2 Informational > documents, and at least 9 Standards Track documents. That's more > than one Working Group should be taking on at one time. We need > to focus on narrowing our scope not expanding it. For the sake of playing devil's advocate, if we have deliverables and miles= tones (implying order), what warrants "to much" work? =20 >=20 > Remediation is a great topic but we should not work on it in > this (proposed) working group at this time. Instead, we should > include hooks for sending remediation instructions (like the > NEA Working Group did in PA-TNC) and encourage others to create > and experiment with various remediation systems. When they have > found something that works, we can bring it into SACM or just > publish it straight as an RFC. >=20 > At least, that's my view. >=20 > Thanks, >=20 > Steve >=20 >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Adam Montville >> Sent: Tuesday, August 21, 2012 10:11 AM >> To: Kent_Landfield@McAfee.com; sacm@ietf.org >> Subject: Re: [sacm] Proposed use cases to move forward >>=20 >> On 8/20/12 12:59 PM, "Kent_Landfield@McAfee.com" >> wrote: >>> One question that I did have is the draft charter talks about >>> remediation. What are other's thoughts on including that as a >>> 'potential' for the work to be done under SACM? >>=20 >>=20 >>=20 >> I would like to see it included. We may need to rethink some of the >> work >> that has already been done in this area. Maybe we start by providing >> some >> way to standardize the minimum set of information that should be >> represented in manual remediation instructions before we move on to >> automated remediation - essentially, walk before we run. >>=20 >>=20 >>=20 >>>=20 >>> --------------------------------- >>> Security Automation Continuous Monitoring (SACM) >>>=20 >>>=20 >>> Proposed Working Group Charter >>>=20 >>>=20 >>> Chairs: >>> TBD >>> TBD >>>=20 >>>=20 >>> Security Area Directors: >>> Stephen Farrell >>> Sean Turner >>>=20 >>>=20 >>> Security Area Advisor: >>> Sean Turner >>>=20 >>>=20 >>> Mailing Lists: >>> General Discussion: sacm@ietf.org >>> To Subscribe: http://www.ietf.org/mailman/listinfo/sacm >>> Archive: http://www.ietf.org/mail-archive/web/sacm >>>=20 >>>=20 >>> Description of Working Group >>>=20 >>>=20 >>> Securing information and the systems that store, process, and transmit >>> that information has become a challenging task for organizations of >> all >>> sizes, and we find that security practitioners spend most of their >> time >>> on manual processes relegating them to >>> ineffectiveness. Security automation is the key to escaping this rut. >>> This working group will develop security automation standards in >> support >>> of information security processes and practices where practical. These >>> standards will support security practitioners >>> to be better utilized within their organizations by allowing them to >>> meet the more advanced needs of the security community (e.g. >> information >>> sharing, continuous monitoring, remediation and response, result >>> aggregation and analysis). The initial focus of this >>> work is to address enterprise and SOHO use cases. The working group >> will >>> achieve this by consuming and continuing (with cooperation) the >> security >>> automation work already performed by various organizations around the >>> world. >>>=20 >>>=20 >>> The initial work has been fruitful, and the data formats previously >>> published are ready for expansion on the international stage. Of >>> particular interest to this working group are the security automation >>> specifications supporting asset, change, configuration, >>> and vulnerability management. Of additional interest to this working >>> group are the emerging security automation interfaces and data formats >>> relating to event management and continuous monitoring. >>>=20 >>>=20 >>> By undertaking this work, we recognize that there are multiple >> categories >>> of problems in the security automation domain: defining expressions >> for >>> particular domain concepts (i.e. data formats), establishing a >>> standards-based foundation supporting the curation >>> and exchange of security automation content collections in content >>> repositories and enabling interoperability through the development and >>> use of interfaces and communications protocols. Content based on rich >>> data standards and protocols will provide the authoritative >>> instructions needed by data-driven tools to enable the automated >>> collection and exchange of configuration and vulnerability data >>> pertaining to enterprise assets. Information produced by these tools >> will >>> provide accurate and timely situational awareness in >>> support of organizational decision making. >>>=20 >>>=20 >>> This working group will provide solutions to these categories of >> problems >>> and the main areas of focus for this working group are described as >>> follows: >>>=20 >>>=20 >>> 1. Define, either by normative reference, adoption, or creation, a set >> of >>> standards that can be used for the purpose of assessing, aggregating >> and >>> comparing device states against expected values, and reporting on >> those >>> results in a predefined or ad hoc >>> manner. >>>=20 >>>=20 >>>=20 >>> 2. Define, either by normative reference, adoption, or creation, a set >> of >>> standards that can be used to continuously monitor and report on the >>> state of systems, composed of many different types of devices and >>> networks, operated by varying personnel, to >>> ensure security process effectiveness in a pre-defined or ad-hoc >> manner. >>>=20 >>>=20 >>> 3. Create relationships between existing operations management >> standards >>> to enable a comprehensive view of security automation, leveraging >>> existing work and implementations. >>=20 >>=20 >>=20 >> At some point I believe we had a 4 and 5 here as well. I can't >> remember, >> were those recommended to be removed? >>=20 >> Otherwise, I agree with the three "main" areas of focus. >>=20 >>=20 >>=20 >>>=20 >>>=20 >>> This working group will produce the following: >>>=20 >>>=20 >>> * An Informational document providing an overview of security >> automation >>> and continuous monitoring to include a reference model >>=20 >>=20 >> Is this a reference to the use case document or something else (I.e. >> the >> informational document I've talked about in the past)? >>=20 >>=20 >>=20 >>> * A Standards Track document specifying benchmark configuration >>> representation (XCCDF) >>> * An Informational document stating guidelines / requirements for >>> specifying checking languages >>> * Standards Track documents specifying device state checking languages >>> (OVAL, ECL, ACEML, =8A) >>> * A Standards Track document specifying an interrogative checking >>> language (OCIL) >>> * A Standards Track document specifying platform naming, matching and >>> applicability (CPE) >>> * Standards Track documents specifying asset identification and >> reporting >>> information (Asset ID, ARF) >>> * Standards Track documents specifying interfaces and communication >>> protocols used for security automation and continuous monitoring >>> * A Standards Track document describing the messages and network >>> protocols for distributing Security Automation Content (content >>> repository) >>=20 >>=20 >> I would remove the word "network" from "network protocols." >>=20 >>=20 >>> * Standards Track document describing integrating security automation >> and >>> Network Endpoint Assessment capabilities (if-m for SCAP?) >>> * A Standards Track document describing protocols and data formats for >>> securely sharing dynamic network state information among security >> systems >>> (if-map) >>=20 >>=20 >>=20 >> I was working on some thought exercises yesterday for the Use Case >> document, and I think we might have some gaps in existing capabilities >> that we should address (either through normative reference or by >> creating >> something new): >>=20 >> 1. Do we need a way to identify, express, and perhaps score patches in >> a >> way that differs from vulnerabilities? This may be something akin to >> CPE >> - perhaps an extension to it. >>=20 >> 2. Should we consider breaking apart the constituents of a technical >> control checking system in a way that allows us to talk about security >> and >> non-security related system objects? There are almost certainly ties >> to >> other areas of IETF and perhaps other SDOs here, but I can use OVAL as >> a >> frame of reference. OVAL talks about definitions, tests, objects, >> states, >> and values (ultimately assigned to states). Is there a need to talk >> about >> objects, and their applicable range of states, outside the context of >> what >> we would generically call a test? >>=20 >> 3. Do we need a way to talk about assets in a non-identifying way? I'm >> thinking things like criticality, classification (I.e. level of >> secrecy), >> and other properties that may not necessarily be used for the purposes >> of >> identification? >>=20 >> 4. Do we need to consider documents dealing with targeting issues? >>=20 >> These four points essentially speak to functional components that may >> be >> lacking in the existing set of specifications/formats. It is my >> expectation that the Use Case document will identify and highlight such >> gaps, where we know we need certain functional capabilities (security >> configuration management including configuration assessment and >> remediation, asset characterization/management, and vulnerability >> assessment, perhaps among others). >>=20 >>=20 >>=20 >>=20 >>>=20 >>>=20 >>> Goals and Milestones >>>=20 >>>=20 >>> TBD >>> -------------------------------------------- >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Thanks. >>>=20 >>>=20 >>> Kent Landfield >>>=20 >>> McAfee | An Intel Company >>> Direct: +1.972.963.7096 >>> Mobile: +1.817.637.8026 >>> Web: www.mcafee.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> From: Adam Montville >>> Date: Friday, August 17, 2012 12:33 PM >>> To: David Waltermire , Stephen Hanna >>> , Luis Nunez , >>> Omar Santos >>> Cc: "sacm@ietf.org" >>> Subject: Re: [sacm] Proposed use cases to move forward >>>=20 >>>=20 >>>=20 >>>> I like taking the scope down as well - and I think we all believe >> we've >>>> agreed to UC1 and UC3. I don't have an issue having the other use >> cases >>>> (2, 4, and 5) described in the use case document, but not fleshed out >> in >>>> the functional capabilities, components, and data/protocol sections. >> The >>>> charter can be derived from the use cases we take on, and a separate >>>> informational document can help place those use cases in the right >>>> context >>>> with respect to the "grand scheme of things." >>>>=20 >>>>=20 >>>> No matter how we slice it, right now we need to focus on the use >> cases >>>> and >>>> charter, and to focus on the use cases we would ideally need to work >> on >>>> setting the context. I've tried to do that (to a limited extent) >> with >>>> the >>>> informational document I sent to the list. >>>>=20 >>>>=20 >>>> Additionally, I think these efforts need to be done in parallel >>>> irrespective of any idealistic dependencies. For example, we should >> be >>>> able to work on a charter, a use case doc, and an informational doc >> all >>>> at >>>> the same time, but join the threads for a final alignment pass before >>>> submitting them. >>>>=20 >>>>=20 >>>> Adam >>>>=20 >>>>=20 >>>> On 8/17/12 9:30 AM, "Waltermire, David A." >> >>>> wrote: >>>>=20 >>>>=20 >>>>> Steve, >>>>>=20 >>>>>=20 >>>>> These are all valid concerns that I completely agree with. What I >> am >>>>> struggling with is insuring that the work we are embarking on >> remains >>>>> relevant in the broader context. My fear is that if we narrow our >>>>> thinking too much, we may inadvertently make decisions that drift >> from >>>>> addressing the broader set of use cases. I like the idea of working >> on >>>>> an individual draft to address the larger context. What I am not >> sure >>>>> about is how introduce a feedback loop that would result in >> minimizing >>>>> this kind of risk. I guess this type of issue is something that we >> will >>>>> need to collectively monitor and address as needed. >>>>>=20 >>>>>=20 >>>>> Sincerely, >>>>> Dave >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Stephen Hanna [mailto:shanna@juniper.net] >>>>> Sent: Wednesday, August 15, 2012 3:55 PM >>>>> To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos >>>>> Cc: sacm@ietf.org >>>>> Subject: RE: [sacm] Proposed use cases to move forward >>>>>=20 >>>>>=20 >>>>> I love broad scope. Don't get me wrong! But I'm concerned about >> having a >>>>> use cases document and an architecture document for this working >> group >>>>> that goes way beyond the charter and initial scope for the group. >>>>>=20 >>>>>=20 >>>>> I'm concerned that this will lead to lots of discussions on the sacm >>>>> list >>>>> and lots of effort being spent on topics that are out of scope, >>>>> diverting >>>>> us from the tasks at hand and slowing our progress. >>>>>=20 >>>>>=20 >>>>> I'm concerned that the working group chairs won't be able to cut off >>>>> discussion of topics by saying they're out of scope for the working >>>>> group. >>>>>=20 >>>>>=20 >>>>> I'm concerned that we'll get sidetracked or even derailed by >>>>> controversies that aren't relevant to the scope of the group. >>>>>=20 >>>>>=20 >>>>> I'm concerned that by including all of security automation within >> our >>>>> use >>>>> cases and architecture, we may actually prevent the formation of >> other >>>>> working groups that could work on those other use cases. >>>>>=20 >>>>>=20 >>>>> We have plenty of work to keep us busy for years with UC1 and UC3. >>>>> There's agreement that the technology needed is mature enough for >> IETF >>>>> standardization. I suggest that we scope this working group to >> address >>>>> only those use cases and that our use cases and architecture be >> limited >>>>> to them. >>>>>=20 >>>>>=20 >>>>> I'm sorely tempted to create an ambitious architecture for security >>>>> automation that encompasses all of the use cases that we have >> described >>>>> so far and maybe more. I understand that people have a hard time >>>>> understanding how the NEA and MILE and SACM standards fit together >> and I >>>>> would love to address that in an IETF RFC. But I have seen several >> grand >>>>> architecture efforts die or come to nothing in IETF. IETF is filled >> with >>>>> smart engineers with clever ideas. We're great at solving problems >> but >>>>> if >>>>> we can't agree on the problem to solve or if we choose the wrong >>>>> problem, >>>>> we can easily spin an intricate and pointless web. >>>>>=20 >>>>>=20 >>>>> I think we'll do better if we scope our effort properly. >>>>>=20 >>>>>=20 >>>>> Maybe a few people can create an individual submission describing a >>>>> grand >>>>> architecture and roadmap for security automation and ask people in >> SACM >>>>> to review and provide feedback on that document. That would be a >> good >>>>> way >>>>> to get a grand architecture while still ensuring that the SACM >> effort >>>>> keeps its focus. In IETF as in so many things, you must keep your >> focus >>>>> or you'll never succeed. >>>>>=20 >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>>=20 >>>>> Steve >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> Behalf >>>>>> Of Waltermire, David A. >>>>>> Sent: Wednesday, August 15, 2012 1:13 PM >>>>>> To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos >>>>>> Cc: sacm@ietf.org >>>>>> Subject: Re: [sacm] Proposed use cases to move forward >>>>>> +1 on scoping the charter to UC1 and UC3. >>>>>> I think we are better served with a use cases document, and >> eventually >>>>>> an architecture documemnt, that is broader scoped. Both of these >>>>>> documents will help inform the work we will do under the charter as >> it >>>>>> relates to the larger context. >>>>>> To this end I would suggest we focus on expanding the use case >>>>>> document primarily in the areas of UC1 and UC3 for now. We can >> expand >>>>>> the other use cases later. >>>>>> Sincerely, >>>>>> Dave >>>>>>> -----Original Message----- >>>>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> Behalf >>>>>> Of >>>>>>> Stephen Hanna >>>>>>> Sent: Wednesday, August 15, 2012 11:24 AM >>>>>>> To: Adam Montville; Luis Nunez; Omar Santos >>>>>>> Cc: sacm@ietf.org >>>>>>> Subject: Re: [sacm] Proposed use cases to move forward >>>>>>>=20 >>>>>>> I agree. Let's work on UC1 and UC3. The other use cases are >> valuable >>>>>>> but just doing UC1 and UC3 is plenty of work for this group for >> the >>>>>>> next year or two (maybe five!). >>>>>>>=20 >>>>>>> I saw several emails in favor of this a few weeks ago. I thought >>>>>>> that it was settled. I'd like to see a revised charter and use >> case >>>>>>> document, scoped down to focus on just UC1 and UC3. >>>>>>>=20 >>>>>>> What do others think? Do we have rough consensus on this? >>>>>>> If so, let's get moving. >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> Steve >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Adam Montville [mailto:amontville@tripwire.com] >>>>>>>> Sent: Wednesday, August 15, 2012 10:30 AM >>>>>>>> To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos >>>>>>>> Cc: sacm@ietf.org >>>>>>>> Subject: Re: [sacm] Proposed use cases to move forward >>>>>>>>=20 >>>>>>>> On 8/6/12 7:27 AM, "Adam Montville" >>>>>> wrote: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> UC1 and UC3 both require assessment of endpoint state. If not >> for >>>>>>> the >>>>>>>> NEA >>>>>>>>> ties in UC1, it seems a subset of UC3. So, we should be able >> to >>>>>>>>> start with the main concern of UC3: Security Configuration >>>>>>> Management. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I haven't seen much activity on this thread (there was another >>>>>>> thread, >>>>>>>> "Using the Frame of Reference," discussing some approaches we >> can >>>>>> use >>>>>>>> to keep us focused and meaningful). >>>>>>>>=20 >>>>>>>> Are there any objections to tackling UC3 followed by UC1? Does >>>>>>> anyone >>>>>>>> disagree with my assertion that UC3 is a subset of UC1 and that >> a >>>>>>>> reasonable starting point is Security Configuration Management? >>>>>>>>=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 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From Kent_Landfield@mcafee.com Tue Aug 21 08:00:18 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD0E21F86DF for ; Tue, 21 Aug 2012 08:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.078, 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 JLPlNhhYXXKZ for ; Tue, 21 Aug 2012 08:00:17 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 765B121F866C for ; Tue, 21 Aug 2012 08:00:17 -0700 (PDT) Received: from DALEXHT1.corp.nai.org (unknown [10.64.5.51]) by dalsmrelay2.nai.com with smtp id 4e25_70f0_5e009032_dbb5_4e90_8030_d5e8761233fe; Tue, 21 Aug 2012 10:00:13 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT1.corp.nai.org ([::1]) with mapi; Tue, 21 Aug 2012 09:58:56 -0500 From: To: , Date: Tue, 21 Aug 2012 09:59:59 -0500 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1/rXwpJe0LoXuSQdasBPCwQ3RANw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC5902C33A9F3kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 15:00:18 -0000 --_000_CC5902C33A9F3kentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Comments inline=85 On 8/20/12 12:59 PM, "Kent_Landfield@McAfee.com" > wrote: One question that I did have is the draft charter talks about remediation. What are other's thoughts on including that as a 'potential' for the work to be done under SACM? I would like to see it included. We may need to rethink some of the work that has already been done in this area. Maybe we start by providing some way to standardize the minimum set of information that should be represented in manual remediation instructions before we move on to automated remediation - essentially, walk before we run. Noted. --------------------------------- Security Automation Continuous Monitoring (SACM) Proposed Working Group Charter =85=85 This working group will provide solutions to these categories of problems and the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of standards that can be used for the purpose of assessing, aggregating and comparing device states against expected values, and reporting on those results in a predefined or ad hoc manner. 2. Define, either by normative reference, adoption, or creation, a set of standards that can be used to continuously monitor and report on the state of systems, composed of many different types of devices and networks, operated by varying personnel, to ensure security process effectiveness in a pre-defined or ad-hoc manner. 3. Create relationships between existing operations management standards to enable a comprehensive view of security automation, leveraging existing work and implementations. At some point I believe we had a 4 and 5 here as well. I can't remember, were those recommended to be removed? No has not been in either of the posted drafts. Both only had three. Otherwise, I agree with the three "main" areas of focus. * An Informational document providing an overview of security automation and continuous monitoring to include a reference model Is this a reference to the use case document or something else (I.e. the informational document I've talked about in the past)? This was intended to be something else. Not the Use Case document. It is m= ore the overview document we discussed in the past. * A Standards Track document describing the messages and network protocols for distributing Security Automation Content (content repository) I would remove the word "network" from "network protocols." Ok. I agree with that. I was working on some thought exercises yesterday for the Use Case document, and I think we might have some gaps in existing capabilities that we should address (either through normative reference or by creating something new): 1. Do we need a way to identify, express, and perhaps score patches in a way that differs from vulnerabilities? This may be something akin to CPE - perhaps an extension to it. One of the discussions we had in Vancouver was around trying to reduce the = scope of the working group. I totally agree there may be other scoring mec= hanisms that are needed. I am also aware there is a need for a real framewo= rk to integrate all these differing scoring mechanisms. I know there has b= een talk that maybe this isn't the right group to do that kind of work in. = Thoughts? 2. Should we consider breaking apart the constituents of a technical control checking system in a way that allows us to talk about security and non-security related system objects? There are almost certainly ties to other areas of IETF and perhaps other SDOs here, but I can use OVAL as a frame of reference. OVAL talks about definitions, tests, objects, states, and values (ultimately assigned to states). Is there a need to talk about objects, and their applicable range of states, outside the context of what we would generically call a test? I am wondering how this plays with the charter discussion=85. Maybe I need= more coffee but=85 3. Do we need a way to talk about assets in a non-identifying way? I'm thinking things like criticality, classification (I.e. level of secrecy), and other properties that may not necessarily be used for the purposes of identification? Again, from a charter discussion=85. I see this playing in the Asset ID / = Asset reporting but much of this work is covered by the MILE Charter. 4. Do we need to consider documents dealing with targeting issues? These four points essentially speak to functional components that may be lacking in the existing set of specifications/formats. It is my expectation that the Use Case document will identify and highlight such gaps, where we know we need certain functional capabilities (security configuration management including configuration assessment and remediation, asset characterization/management, and vulnerability assessment, perhaps among others). Correct me if I am wrong here folks but there is nothing to stop anyone fro= m creating an I-D and proposing it to the working group for acceptance as a= working group document after the charter is developed as long as the docum= ent can be fit under the auspices of the working group's charter. Correct? Kent --_000_CC5902C33A9F3kentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Comments in= line=85

<= blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT: = #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
On 8/20/1= 2 12:59 PM, "Kent_Landfie= ld@McAfee.com"
One question that I did have is the dra= ft charter talks about
remediation.  What are other's t= houghts on including that as a
'potential' for the work to be don= e under SACM?



I would like to see it included.  We may need to rethink s= ome of the work
that has already been done in this area. &nb= sp;Maybe we start by providing some
way to standardize the minimu= m set of information that should be
represented in manual remedia= tion instructions before we move on to
automated remediation - es= sentially, walk before we run.
Noted.



= ---------------------------------
Security Automation Continuous = Monitoring (SACM)


Proposed Working = Group Charter

=85=85
This working group = will provide solutions to these categories of problems
and the ma= in areas of focus for this working group are described as
follows= :


1. Define, either by normative re= ference, adoption, or creation, a set of
standards that can be us= ed for the purpose of assessing, aggregating and
comparing device= states against expected values, and reporting on those
results i= n a predefined or ad hoc
manner.


2. Define, either by normative reference, adoption, or= creation, a set of
standards that can be used to continuously mo= nitor and report on the
state of systems, composed of many differ= ent types of devices and
networks, operated by varying personnel,= to
ensure security process effectiveness in a pre-defined or ad= -hoc manner.


3. Create relationship= s between existing operations management standards
to enable a co= mprehensive view of security automation, leveraging
existing work= and implementations.


=
At some point I believe we had a 4 and 5 here as well. =  I can't remember,
were those recommended to be removed?


No has= not been in either of the posted drafts.  Both only had three.
<= div>


Other= wise, I agree with the three "main" areas of focus.

<= div>* An Informational document providing an overview of security automatio= n
and continuous monitoring to include a reference model


Is this a reference to the use= case document or something else (I.e. the
informational document= I've talked about in the past)?


This was intended to be something else. Not t= he Use Case document.  It is more the overview document we discussed i= n the past.



=
* A Standards Track document describing the messages and network
=
protocols for distributing Security Automation Content  (con= tent
repository)


=
I would remove the word "network" from "network protoco= ls."

Ok. &nbs= p;I agree with that.

=

I was working on some thought exercises yesterday for the Use Case
document, and I think we might have some gaps in existing capabili= ties
that we should address (either through normative reference o= r by creating
something new):

1. Do we n= eed a way to identify, express, and perhaps score patches in a
wa= y that differs from vulnerabilities?  This may be something akin = to CPE
- perhaps an extension to it.

One of the discussions we had in Vancouver was= around trying to reduce the scope of the working group.  I totally ag= ree there may be other scoring mechanisms that are needed. I am also aware = there is a need for a real framework to integrate all these differing scori= ng mechanisms.  I know there has been talk that maybe this isn't the r= ight group to do that kind of work in.  Thoughts?

=


2. Should we consid= er breaking apart the constituents of a technical
control checkin= g system in a way that allows us to talk about security and
non-s= ecurity related system objects?  There are almost certainly ties = to
other areas of IETF and perhaps other SDOs here, but I can use= OVAL as a
frame of reference.  OVAL talks about defini= tions, tests, objects, states,
and values (ultimately assigned to= states).  Is there a need to talk about
objects, and t= heir applicable range of states, outside the context of what
we w= ould generically call a test?
I am wondering how this plays with the charter discussion=85. &= nbsp;Maybe I need more coffee but=85 

<= div>

3. Do we need a way to talk about assets in a = non-identifying way?  I'm
thinking things like critical= ity, classification (I.e. level of secrecy),
and other properties= that may not necessarily be used for the purposes of
identificat= ion?

Again, from a= charter discussion=85.  I see this playing in the Asset ID / Asset re= porting but much of this work is covered by the MILE Charter.

4. Do we need to consider d= ocuments dealing with targeting issues?

These four= points essentially speak to functional components that may be
la= cking in the existing set of specifications/formats.  It is my
expectation that the Use Case document will identify and highlight = such
gaps, where we know we need certain functional capabilities = (security
configuration management including configuration assess= ment and
remediation, asset characterization/management, and vuln= erability
assessment, perhaps among others).

Correct me if I am wrong here folks bu= t there is nothing to stop anyone from creating an I-D and proposing it to = the working group for acceptance as a working group document after the char= ter is developed as long as the document can be fit under the auspices of t= he working group's charter.  Correct?

Kent


--_000_CC5902C33A9F3kentlandfieldmcafeecom_-- From Kent_Landfield@mcafee.com Tue Aug 21 08:18:44 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015D221F86C8 for ; Tue, 21 Aug 2012 08:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.074, 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 1SD3kGsofCrj for ; Tue, 21 Aug 2012 08:18:43 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7C721F86C7 for ; Tue, 21 Aug 2012 08:18:43 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 4e29_4b42_6b9e8d14_8008_41d4_862f_0232b1864e5f; Tue, 21 Aug 2012 10:18:32 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Tue, 21 Aug 2012 10:17:51 -0500 From: To: , , Date: Tue, 21 Aug 2012 10:18:53 -0500 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1/sCER24TeAy1hSrGGK0RJwQhv4g== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC590F183AA6Ckentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 15:18:44 -0000 --_000_CC590F183AA6Ckentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Steve wrote=85. Remediation is a great topic but we should not work on it in this (proposed) working group at this time. Instead, we should include hooks for sending remediation instructions (like the NEA Working Group did in PA-TNC) and encourage others to create and experiment with various remediation systems. When they have found something that works, we can bring it into SACM or just publish it straight as an RFC. My question is more about how to properly address this in the charter rathe= r than if this should be addressed directly=85 Today the charter states: This working group will develop security automation standards in suppor= t of information security processes and practices where practical. These standards will support security practi= tioners to be betterutilized within their organizations by allowing them to meet the more advanced needs of the security commun= ity (e.g. information sharing, continuous monitoring, remediation and response, result aggregation and analysis). My understanding is this type of reference will include remediation as a po= tential "in-scope" work item if there is sufficient interest in the group t= o do so but does not obligate us to tackle the issue directly as a delivera= ble. It allows us to accept non-identified (at the time of charter) I-Ds i= nto the working group if it is so decided by the group the I-D is a valuabl= e work item. Remediation aside, is my understanding of the process accurate? Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com --_000_CC590F183AA6Ckentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Steve= wrote=85.
    Remediation is a great topic but we sh= ould not work on it in
    this (proposed) working group a= t this time. Instead, we should
    include hooks for send= ing remediation instructions (like the
    NEA Working Gro= up did in PA-TNC) and encourage others to create
    and e= xperiment with various remediation systems. When they have
  &= nbsp; found something that works, we can bring it into SACM or just
=    publish it straight as an RFC.

My que= stion is more about how to properly address this in the charter rather than= if this should be addressed directly=85  

Today th= e charter states:

    This working group will develop security automatio= n standards in support of information security processes and 
=     practices where practical. These standards will support security practitioners to be better= utilized within their organizations 
    by allowi= ng them to meet the more advanced needs of the security community (e.g. information sharing, continuous monitoring, 
    remediation and response, r= esult aggregation and analysis).
<= br>
My understanding is this type of reference will include remediatio= n as a potential "in-scope" work item if there is sufficient inte= rest in the group to do so but does not obligate us to tackle the issue dir= ectly as a deliverable.  It allows us to accept non-identified (at the= time of charter) I-Ds into the working group if it is so decided by the gr= oup the I-D is a valuable work item.  

Remediation asid= e, is my understanding of the process accurate?

Ke= nt Landfield

<= strong>McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: 


 --_000_CC590F183AA6Ckentlandfieldmcafeecom_-- From michael.hammer@yaanatech.com Tue Aug 21 08:38:00 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBF111E80A6 for ; Tue, 21 Aug 2012 08:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.016, 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 TuSWUlPEF94n for ; Tue, 21 Aug 2012 08:37:57 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 7758521F8551 for ; Tue, 21 Aug 2012 08:37:57 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 21 Aug 2012 08:37:56 -0700 From: Michael Hammer To: "Kent_Landfield@McAfee.com" , "amontville@tripwire.com" , "sacm@ietf.org" Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwgAGFQsxAAAviVgACqobYAABd1KwAAEF6ogAANZTIQ Date: Tue, 21 Aug 2012 15:37:53 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB310AA7EF9@EX2K10MB1.corp.yaanatech.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.1] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0050_01CD7F91.64D7C460" MIME-Version: 1.0 Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 15:38:00 -0000 ------=_NextPart_000_0050_01CD7F91.64D7C460 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0051_01CD7F91.64D7C460" ------=_NextPart_001_0051_01CD7F91.64D7C460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The charter is to keep out stuff that is off-topic. That said, you don't want to constantly thrash on the charter. If folks can agree on the priorities, then hopefully all will respect the consensus. Mike From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Tuesday, August 21, 2012 11:00 AM To: amontville@tripwire.com; sacm@ietf.org Subject: Re: [sacm] Proposed use cases to move forward Comments inline. On 8/20/12 12:59 PM, "Kent_Landfield@McAfee.com" wrote: One question that I did have is the draft charter talks about remediation. What are other's thoughts on including that as a 'potential' for the work to be done under SACM? I would like to see it included. We may need to rethink some of the work that has already been done in this area. Maybe we start by providing some way to standardize the minimum set of information that should be represented in manual remediation instructions before we move on to automated remediation - essentially, walk before we run. Noted. --------------------------------- Security Automation Continuous Monitoring (SACM) Proposed Working Group Charter .. This working group will provide solutions to these categories of problems and the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of standards that can be used for the purpose of assessing, aggregating and comparing device states against expected values, and reporting on those results in a predefined or ad hoc manner. 2. Define, either by normative reference, adoption, or creation, a set of standards that can be used to continuously monitor and report on the state of systems, composed of many different types of devices and networks, operated by varying personnel, to ensure security process effectiveness in a pre-defined or ad-hoc manner. 3. Create relationships between existing operations management standards to enable a comprehensive view of security automation, leveraging existing work and implementations. At some point I believe we had a 4 and 5 here as well. I can't remember, were those recommended to be removed? No has not been in either of the posted drafts. Both only had three. Otherwise, I agree with the three "main" areas of focus. * An Informational document providing an overview of security automation and continuous monitoring to include a reference model Is this a reference to the use case document or something else (I.e. the informational document I've talked about in the past)? This was intended to be something else. Not the Use Case document. It is more the overview document we discussed in the past. * A Standards Track document describing the messages and network protocols for distributing Security Automation Content (content repository) I would remove the word "network" from "network protocols." Ok. I agree with that. I was working on some thought exercises yesterday for the Use Case document, and I think we might have some gaps in existing capabilities that we should address (either through normative reference or by creating something new): 1. Do we need a way to identify, express, and perhaps score patches in a way that differs from vulnerabilities? This may be something akin to CPE - perhaps an extension to it. One of the discussions we had in Vancouver was around trying to reduce the scope of the working group. I totally agree there may be other scoring mechanisms that are needed. I am also aware there is a need for a real framework to integrate all these differing scoring mechanisms. I know there has been talk that maybe this isn't the right group to do that kind of work in. Thoughts? 2. Should we consider breaking apart the constituents of a technical control checking system in a way that allows us to talk about security and non-security related system objects? There are almost certainly ties to other areas of IETF and perhaps other SDOs here, but I can use OVAL as a frame of reference. OVAL talks about definitions, tests, objects, states, and values (ultimately assigned to states). Is there a need to talk about objects, and their applicable range of states, outside the context of what we would generically call a test? I am wondering how this plays with the charter discussion.. Maybe I need more coffee but. 3. Do we need a way to talk about assets in a non-identifying way? I'm thinking things like criticality, classification (I.e. level of secrecy), and other properties that may not necessarily be used for the purposes of identification? Again, from a charter discussion.. I see this playing in the Asset ID / Asset reporting but much of this work is covered by the MILE Charter. 4. Do we need to consider documents dealing with targeting issues? These four points essentially speak to functional components that may be lacking in the existing set of specifications/formats. It is my expectation that the Use Case document will identify and highlight such gaps, where we know we need certain functional capabilities (security configuration management including configuration assessment and remediation, asset characterization/management, and vulnerability assessment, perhaps among others). Correct me if I am wrong here folks but there is nothing to stop anyone from creating an I-D and proposing it to the working group for acceptance as a working group document after the charter is developed as long as the document can be fit under the auspices of the working group's charter. Correct? Kent ------=_NextPart_001_0051_01CD7F91.64D7C460 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The charter is to keep out stuff that is = off-topic.

 

That said, you don’t want to constantly thrash on the = charter.

 

If folks can agree on the priorities, then hopefully all will respect = the consensus.

 

Mike

 

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Kent_Landfield@McAfee.com
Sent: Tuesday, August 21, 2012 = 11:00 AM
To: amontville@tripwire.com; = sacm@ietf.org
Subject: Re: [sacm] Proposed use cases to move = forward

 

Comments = inline…

 

One question that I did = have is the draft charter talks about

remediation.  What are other's thoughts = on including that as a

'potential' for the work = to be done under SACM?

 

 

 

I would like to see it = included.  We may need to rethink some of the = work

that has already been done in this = area.  Maybe we start by providing = some

way to standardize the minimum set of information = that should be

represented in manual = remediation instructions before we move on = to

automated remediation - essentially, walk before = we run.

 

Noted.

 

 

 

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

Security = Automation Continuous Monitoring = (SACM)

 

 

Proposed Working Group = Charter

 

……

This working group will = provide solutions to these categories of = problems

and the main areas of focus for this working group = are described as

follows:

 

 

1. Define, either by = normative reference, adoption, or creation, a set = of

standards that can be used for the purpose of = assessing, aggregating and

comparing device states = against expected values, and reporting on = those

results in a predefined or ad = hoc

manner.

 

 

2. Define, either by = normative reference, adoption, or creation, a set = of

standards that can be used to continuously monitor = and report on the

state of systems, composed = of many different types of devices = and

networks, operated by varying personnel, = to

ensure security process effectiveness in a = pre-defined or ad-hoc manner.

 

 

3. Create relationships = between existing operations management = standards

to enable a comprehensive view of security = automation, leveraging

existing work and = implementations.

 

 

 

At some point I believe we = had a 4 and 5 here as well.  I can't = remember,

were those recommended to be = removed?

 

 

No has not been in either = of the posted drafts.  Both only had = three.

 

 

 

Otherwise, I agree with = the three "main" areas of = focus.

 

 

* An Informational = document providing an overview of security = automation

and continuous monitoring to include a reference = model

 

 

Is this a reference to the = use case document or something else (I.e. = the

informational document I've talked about in the = past)?

 

 

This was intended to be = something else. Not the Use Case document.  It is more the overview = document we discussed in the past.

 

 

 

 

* A Standards Track = document describing the messages and = network

protocols for distributing Security Automation = Content  (content

repository)

 

 

I would remove the word = "network" from "network = protocols."

 

Ok.  I agree with = that.

 

 

I was working on some = thought exercises yesterday for the Use = Case

document, and I think we might have some gaps in = existing capabilities

that we should address = (either through normative reference or by = creating

something new):

 

1. Do we need a way to = identify, express, and perhaps score patches in = a

way that differs from = vulnerabilities?  This may be something akin to = CPE

- perhaps an extension to = it.

 

One of the discussions we = had in Vancouver was around trying to reduce the scope of the working = group.  I totally agree there may be other scoring mechanisms that = are needed. I am also aware there is a need for a real framework to = integrate all these differing scoring mechanisms.  I know there has = been talk that maybe this isn't the right group to do that kind of work = in.  Thoughts?

 

 

 

2. Should we consider = breaking apart the constituents of a = technical

control checking system in a way that allows us to = talk about security and

non-security related = system objects?  There are almost certainly ties = to

other areas of IETF and perhaps other SDOs here, = but I can use OVAL as a

frame of = reference.  OVAL talks about definitions, tests, objects, = states,

and values (ultimately assigned to = states).  Is there a need to talk = about

objects, and their applicable range of states, = outside the context of what

we would generically call = a test?

 

I am wondering how this = plays with the charter discussion….  Maybe I need more coffee = but… 

 

 

3. Do we need a way to = talk about assets in a non-identifying = way?  I'm

thinking things like = criticality, classification (I.e. level of = secrecy),

and other properties that may not necessarily be = used for the purposes of

identification?

 

Again, from a charter = discussion….  I see this playing in the Asset ID / Asset = reporting but much of this work is covered by the MILE = Charter.

 

 

4. Do we need to consider = documents dealing with targeting = issues?

 

These four points = essentially speak to functional components that may = be

lacking in the existing set of = specifications/formats.  It is = my

expectation that the Use Case document will = identify and highlight such

gaps, where we know we = need certain functional capabilities = (security

configuration management including configuration = assessment and

remediation, asset = characterization/management, and = vulnerability

assessment, perhaps among = others).

 

Correct me if I am wrong = here folks but there is nothing to stop anyone from creating an I-D and = proposing it to the working group for acceptance as a working group = document after the charter is developed as long as the document can be = fit under the auspices of the working group's charter. =  Correct?

 

Kent

 

 

------=_NextPart_001_0051_01CD7F91.64D7C460-- ------=_NextPart_000_0050_01CD7F91.64D7C460 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgy MTE1Mzc1MFowIwYJKoZIhvcNAQkEMRYEFEt9Xf88TESubIughbk7V9xSqNIYMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAQNy8ENdNTAbVRESbdWjvi3jaDdVxQgIccuRyBiSiBxow LrU2buv+NgfG/16jCoiMmjAqdbYm9Y3Z2jdVUfVRQ6BPL9vVyFjLfT/WIlsEfu9rvaVJQYVQN/Oy JSr6llaMWf+iM1GlCs5slzPgRfEtb3L+O5/mYahDT9ksWnQPgVsAAAAAAAA= ------=_NextPart_000_0050_01CD7F91.64D7C460-- From shanna@juniper.net Tue Aug 21 10:17: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 84B3821F8794 for ; Tue, 21 Aug 2012 10:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 5uCENhyjOu49 for ; Tue, 21 Aug 2012 10:17:15 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7F44521F8781 for ; Tue, 21 Aug 2012 10:17:14 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUDPCmpz5m6Kv4xIErigW0Z07d7rCNrO8@postini.com; Tue, 21 Aug 2012 10:17:15 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 21 Aug 2012 10:16:59 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 21 Aug 2012 13:15:47 -0400 From: Stephen Hanna To: Adam Montville Date: Tue, 21 Aug 2012 13:15:45 -0400 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwgAGFQsxAAAviVgACqobYAABd1KwAAAOIbcAAAvwn5AAAbMtA= Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 17:17:17 -0000 Adam Montville wrote: > For the sake of playing devil's advocate, if we have deliverables and > milestones (implying order), what warrants "to much" work? There's no hard-and-fast rule for this but I was just on a boring concall so I ran some numbers on the existing IETF SEC area Working Groups. * The number of WG documents varies from 0 to 11 with 3/4 of the WGs having between 2 & 6 WG documents. * The number of authors per WG document (not double-counting authors who are on more than one doc in a single WG) varies from 1.25 to 3.5 with 2/3 of the WGs having between 1.4 and 2.3 authors per spec. * The number of emails per month varies between about 8 and about 150. Removing two WGs with lots of legacy RFCs and therefore an extra amount of email traffic (PKIX and IPSECME), the number of emails per month per WG document varies between 6 and 20 with the average around 12. Looking at SACM, 9 WG documents would be way more than average for the SEC area. Our email list traffic is about 60 emails per month. That would indicate we can support about 5 WG documents. I think that's consistent with the number of active participants and likely document authors that I have seen on the list so far. I see about 15 active participants on the list in the last few months. We could gain or lose some as time goes on but that's what I see. If half of those become document editors, we could easily support 4-5 WG documents. Maybe we should figure out how to stage our work into two stages. That way, we could have 4-5 documents in a first stage and 4-5 documents in a second stage. Many WGs do that. We can list all the documents in our charter and have milestones that stage them. Now that I reread your email, I think that's exactly what you were suggesting. So maybe we're agreeing! But I still think that remediation shouldn't be in the first two stages. It's the least understood aspect of this work. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Tuesday, August 21, 2012 10:58 AM > To: Stephen Hanna > Cc: Kent_Landfield@McAfee.com; sacm@ietf.org > Subject: Re: [sacm] Proposed use cases to move forward > > > > On Aug 21, 2012, at 7:55 AM, "Stephen Hanna" > wrote: > > > In the current charter, I see 3 areas of focus, 2 Informational > > documents, and at least 9 Standards Track documents. That's more > > than one Working Group should be taking on at one time. We need > > to focus on narrowing our scope not expanding it. > > > For the sake of playing devil's advocate, if we have deliverables and > milestones (implying order), what warrants "to much" work? > > > > > > > > Remediation is a great topic but we should not work on it in > > this (proposed) working group at this time. Instead, we should > > include hooks for sending remediation instructions (like the > > NEA Working Group did in PA-TNC) and encourage others to create > > and experiment with various remediation systems. When they have > > found something that works, we can bring it into SACM or just > > publish it straight as an RFC. > > > > At least, that's my view. > > > > Thanks, > > > > Steve > > > >> -----Original Message----- > >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of > >> Adam Montville > >> Sent: Tuesday, August 21, 2012 10:11 AM > >> To: Kent_Landfield@McAfee.com; sacm@ietf.org > >> Subject: Re: [sacm] Proposed use cases to move forward > >> > >> On 8/20/12 12:59 PM, "Kent_Landfield@McAfee.com" > >> wrote: > >>> One question that I did have is the draft charter talks about > >>> remediation. What are other's thoughts on including that as a > >>> 'potential' for the work to be done under SACM? > >> > >> > >> > >> I would like to see it included. We may need to rethink some of the > >> work > >> that has already been done in this area. Maybe we start by > providing > >> some > >> way to standardize the minimum set of information that should be > >> represented in manual remediation instructions before we move on to > >> automated remediation - essentially, walk before we run. > >> > >> > >> > >>> > >>> --------------------------------- > >>> Security Automation Continuous Monitoring (SACM) > >>> > >>> > >>> Proposed Working Group Charter > >>> > >>> > >>> Chairs: > >>> TBD > >>> TBD > >>> > >>> > >>> Security Area Directors: > >>> Stephen Farrell > >>> Sean Turner > >>> > >>> > >>> Security Area Advisor: > >>> Sean Turner > >>> > >>> > >>> Mailing Lists: > >>> General Discussion: sacm@ietf.org > >>> To Subscribe: > http://www.ietf.org/mailman/listinfo/sacm > >>> Archive: http://www.ietf.org/mail- > archive/web/sacm > >>> > >>> > >>> Description of Working Group > >>> > >>> > >>> Securing information and the systems that store, process, and > transmit > >>> that information has become a challenging task for organizations of > >> all > >>> sizes, and we find that security practitioners spend most of their > >> time > >>> on manual processes relegating them to > >>> ineffectiveness. Security automation is the key to escaping this > rut. > >>> This working group will develop security automation standards in > >> support > >>> of information security processes and practices where practical. > These > >>> standards will support security practitioners > >>> to be better utilized within their organizations by allowing them > to > >>> meet the more advanced needs of the security community (e.g. > >> information > >>> sharing, continuous monitoring, remediation and response, result > >>> aggregation and analysis). The initial focus of this > >>> work is to address enterprise and SOHO use cases. The working group > >> will > >>> achieve this by consuming and continuing (with cooperation) the > >> security > >>> automation work already performed by various organizations around > the > >>> world. > >>> > >>> > >>> The initial work has been fruitful, and the data formats previously > >>> published are ready for expansion on the international stage. Of > >>> particular interest to this working group are the security > automation > >>> specifications supporting asset, change, configuration, > >>> and vulnerability management. Of additional interest to this > working > >>> group are the emerging security automation interfaces and data > formats > >>> relating to event management and continuous monitoring. > >>> > >>> > >>> By undertaking this work, we recognize that there are multiple > >> categories > >>> of problems in the security automation domain: defining expressions > >> for > >>> particular domain concepts (i.e. data formats), establishing a > >>> standards-based foundation supporting the curation > >>> and exchange of security automation content collections in content > >>> repositories and enabling interoperability through the development > and > >>> use of interfaces and communications protocols. Content based on > rich > >>> data standards and protocols will provide the authoritative > >>> instructions needed by data-driven tools to enable the automated > >>> collection and exchange of configuration and vulnerability data > >>> pertaining to enterprise assets. Information produced by these > tools > >> will > >>> provide accurate and timely situational awareness in > >>> support of organizational decision making. > >>> > >>> > >>> This working group will provide solutions to these categories of > >> problems > >>> and the main areas of focus for this working group are described as > >>> follows: > >>> > >>> > >>> 1. Define, either by normative reference, adoption, or creation, a > set > >> of > >>> standards that can be used for the purpose of assessing, > aggregating > >> and > >>> comparing device states against expected values, and reporting on > >> those > >>> results in a predefined or ad hoc > >>> manner. > >>> > >>> > >>> > >>> 2. Define, either by normative reference, adoption, or creation, a > set > >> of > >>> standards that can be used to continuously monitor and report on > the > >>> state of systems, composed of many different types of devices and > >>> networks, operated by varying personnel, to > >>> ensure security process effectiveness in a pre-defined or ad-hoc > >> manner. > >>> > >>> > >>> 3. Create relationships between existing operations management > >> standards > >>> to enable a comprehensive view of security automation, leveraging > >>> existing work and implementations. > >> > >> > >> > >> At some point I believe we had a 4 and 5 here as well. I can't > >> remember, > >> were those recommended to be removed? > >> > >> Otherwise, I agree with the three "main" areas of focus. > >> > >> > >> > >>> > >>> > >>> This working group will produce the following: > >>> > >>> > >>> * An Informational document providing an overview of security > >> automation > >>> and continuous monitoring to include a reference model > >> > >> > >> Is this a reference to the use case document or something else (I.e. > >> the > >> informational document I've talked about in the past)? > >> > >> > >> > >>> * A Standards Track document specifying benchmark configuration > >>> representation (XCCDF) > >>> * An Informational document stating guidelines / requirements for > >>> specifying checking languages > >>> * Standards Track documents specifying device state checking > languages > >>> (OVAL, ECL, ACEML, =A9) > >>> * A Standards Track document specifying an interrogative checking > >>> language (OCIL) > >>> * A Standards Track document specifying platform naming, matching > and > >>> applicability (CPE) > >>> * Standards Track documents specifying asset identification and > >> reporting > >>> information (Asset ID, ARF) > >>> * Standards Track documents specifying interfaces and communication > >>> protocols used for security automation and continuous monitoring > >>> * A Standards Track document describing the messages and network > >>> protocols for distributing Security Automation Content (content > >>> repository) > >> > >> > >> I would remove the word "network" from "network protocols." > >> > >> > >>> * Standards Track document describing integrating security > automation > >> and > >>> Network Endpoint Assessment capabilities (if-m for SCAP?) > >>> * A Standards Track document describing protocols and data formats > for > >>> securely sharing dynamic network state information among security > >> systems > >>> (if-map) > >> > >> > >> > >> I was working on some thought exercises yesterday for the Use Case > >> document, and I think we might have some gaps in existing > capabilities > >> that we should address (either through normative reference or by > >> creating > >> something new): > >> > >> 1. Do we need a way to identify, express, and perhaps score patches > in > >> a > >> way that differs from vulnerabilities? This may be something akin > to > >> CPE > >> - perhaps an extension to it. > >> > >> 2. Should we consider breaking apart the constituents of a technical > >> control checking system in a way that allows us to talk about > security > >> and > >> non-security related system objects? There are almost certainly > ties > >> to > >> other areas of IETF and perhaps other SDOs here, but I can use OVAL > as > >> a > >> frame of reference. OVAL talks about definitions, tests, objects, > >> states, > >> and values (ultimately assigned to states). Is there a need to talk > >> about > >> objects, and their applicable range of states, outside the context > of > >> what > >> we would generically call a test? > >> > >> 3. Do we need a way to talk about assets in a non-identifying way? > I'm > >> thinking things like criticality, classification (I.e. level of > >> secrecy), > >> and other properties that may not necessarily be used for the > purposes > >> of > >> identification? > >> > >> 4. Do we need to consider documents dealing with targeting issues? > >> > >> These four points essentially speak to functional components that > may > >> be > >> lacking in the existing set of specifications/formats. It is my > >> expectation that the Use Case document will identify and highlight > such > >> gaps, where we know we need certain functional capabilities > (security > >> configuration management including configuration assessment and > >> remediation, asset characterization/management, and vulnerability > >> assessment, perhaps among others). > >> > >> > >> > >> > >>> > >>> > >>> Goals and Milestones > >>> > >>> > >>> TBD > >>> -------------------------------------------- > >>> > >>> > >>> > >>> > >>> > >>> Thanks. > >>> > >>> > >>> Kent Landfield > >>> > >>> McAfee | An Intel Company > >>> Direct: +1.972.963.7096 > >>> Mobile: +1.817.637.8026 > >>> Web: www.mcafee.com > >>> > >>> > >>> > >>> > >>> > >>> From: Adam Montville > >>> Date: Friday, August 17, 2012 12:33 PM > >>> To: David Waltermire , Stephen Hanna > >>> , Luis Nunez , > >>> Omar Santos > >>> Cc: "sacm@ietf.org" > >>> Subject: Re: [sacm] Proposed use cases to move forward > >>> > >>> > >>> > >>>> I like taking the scope down as well - and I think we all believe > >> we've > >>>> agreed to UC1 and UC3. I don't have an issue having the other use > >> cases > >>>> (2, 4, and 5) described in the use case document, but not fleshed > out > >> in > >>>> the functional capabilities, components, and data/protocol > sections. > >> The > >>>> charter can be derived from the use cases we take on, and a > separate > >>>> informational document can help place those use cases in the right > >>>> context > >>>> with respect to the "grand scheme of things." > >>>> > >>>> > >>>> No matter how we slice it, right now we need to focus on the use > >> cases > >>>> and > >>>> charter, and to focus on the use cases we would ideally need to > work > >> on > >>>> setting the context. I've tried to do that (to a limited extent) > >> with > >>>> the > >>>> informational document I sent to the list. > >>>> > >>>> > >>>> Additionally, I think these efforts need to be done in parallel > >>>> irrespective of any idealistic dependencies. For example, we > should > >> be > >>>> able to work on a charter, a use case doc, and an informational > doc > >> all > >>>> at > >>>> the same time, but join the threads for a final alignment pass > before > >>>> submitting them. > >>>> > >>>> > >>>> Adam > >>>> > >>>> > >>>> On 8/17/12 9:30 AM, "Waltermire, David A." > >> > >>>> wrote: > >>>> > >>>> > >>>>> Steve, > >>>>> > >>>>> > >>>>> These are all valid concerns that I completely agree with. What > I > >> am > >>>>> struggling with is insuring that the work we are embarking on > >> remains > >>>>> relevant in the broader context. My fear is that if we narrow > our > >>>>> thinking too much, we may inadvertently make decisions that drift > >> from > >>>>> addressing the broader set of use cases. I like the idea of > working > >> on > >>>>> an individual draft to address the larger context. What I am not > >> sure > >>>>> about is how introduce a feedback loop that would result in > >> minimizing > >>>>> this kind of risk. I guess this type of issue is something that > we > >> will > >>>>> need to collectively monitor and address as needed. > >>>>> > >>>>> > >>>>> Sincerely, > >>>>> Dave > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Stephen Hanna [mailto:shanna@juniper.net] > >>>>> Sent: Wednesday, August 15, 2012 3:55 PM > >>>>> To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos > >>>>> Cc: sacm@ietf.org > >>>>> Subject: RE: [sacm] Proposed use cases to move forward > >>>>> > >>>>> > >>>>> I love broad scope. Don't get me wrong! But I'm concerned about > >> having a > >>>>> use cases document and an architecture document for this working > >> group > >>>>> that goes way beyond the charter and initial scope for the group. > >>>>> > >>>>> > >>>>> I'm concerned that this will lead to lots of discussions on the > sacm > >>>>> list > >>>>> and lots of effort being spent on topics that are out of scope, > >>>>> diverting > >>>>> us from the tasks at hand and slowing our progress. > >>>>> > >>>>> > >>>>> I'm concerned that the working group chairs won't be able to cut > off > >>>>> discussion of topics by saying they're out of scope for the > working > >>>>> group. > >>>>> > >>>>> > >>>>> I'm concerned that we'll get sidetracked or even derailed by > >>>>> controversies that aren't relevant to the scope of the group. > >>>>> > >>>>> > >>>>> I'm concerned that by including all of security automation within > >> our > >>>>> use > >>>>> cases and architecture, we may actually prevent the formation of > >> other > >>>>> working groups that could work on those other use cases. > >>>>> > >>>>> > >>>>> We have plenty of work to keep us busy for years with UC1 and > UC3. > >>>>> There's agreement that the technology needed is mature enough for > >> IETF > >>>>> standardization. I suggest that we scope this working group to > >> address > >>>>> only those use cases and that our use cases and architecture be > >> limited > >>>>> to them. > >>>>> > >>>>> > >>>>> I'm sorely tempted to create an ambitious architecture for > security > >>>>> automation that encompasses all of the use cases that we have > >> described > >>>>> so far and maybe more. I understand that people have a hard time > >>>>> understanding how the NEA and MILE and SACM standards fit > together > >> and I > >>>>> would love to address that in an IETF RFC. But I have seen > several > >> grand > >>>>> architecture efforts die or come to nothing in IETF. IETF is > filled > >> with > >>>>> smart engineers with clever ideas. We're great at solving > problems > >> but > >>>>> if > >>>>> we can't agree on the problem to solve or if we choose the wrong > >>>>> problem, > >>>>> we can easily spin an intricate and pointless web. > >>>>> > >>>>> > >>>>> I think we'll do better if we scope our effort properly. > >>>>> > >>>>> > >>>>> Maybe a few people can create an individual submission describing > a > >>>>> grand > >>>>> architecture and roadmap for security automation and ask people > in > >> SACM > >>>>> to review and provide feedback on that document. That would be a > >> good > >>>>> way > >>>>> to get a grand architecture while still ensuring that the SACM > >> effort > >>>>> keeps its focus. In IETF as in so many things, you must keep your > >> focus > >>>>> or you'll never succeed. > >>>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> > >>>>> Steve > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > >> Behalf > >>>>>> Of Waltermire, David A. > >>>>>> Sent: Wednesday, August 15, 2012 1:13 PM > >>>>>> To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos > >>>>>> Cc: sacm@ietf.org > >>>>>> Subject: Re: [sacm] Proposed use cases to move forward > >>>>>> +1 on scoping the charter to UC1 and UC3. > >>>>>> I think we are better served with a use cases document, and > >> eventually > >>>>>> an architecture documemnt, that is broader scoped. Both of > these > >>>>>> documents will help inform the work we will do under the charter > as > >> it > >>>>>> relates to the larger context. > >>>>>> To this end I would suggest we focus on expanding the use case > >>>>>> document primarily in the areas of UC1 and UC3 for now. We can > >> expand > >>>>>> the other use cases later. > >>>>>> Sincerely, > >>>>>> Dave > >>>>>>> -----Original Message----- > >>>>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > >> Behalf > >>>>>> Of > >>>>>>> Stephen Hanna > >>>>>>> Sent: Wednesday, August 15, 2012 11:24 AM > >>>>>>> To: Adam Montville; Luis Nunez; Omar Santos > >>>>>>> Cc: sacm@ietf.org > >>>>>>> Subject: Re: [sacm] Proposed use cases to move forward > >>>>>>> > >>>>>>> I agree. Let's work on UC1 and UC3. The other use cases are > >> valuable > >>>>>>> but just doing UC1 and UC3 is plenty of work for this group for > >> the > >>>>>>> next year or two (maybe five!). > >>>>>>> > >>>>>>> I saw several emails in favor of this a few weeks ago. I > thought > >>>>>>> that it was settled. I'd like to see a revised charter and use > >> case > >>>>>>> document, scoped down to focus on just UC1 and UC3. > >>>>>>> > >>>>>>> What do others think? Do we have rough consensus on this? > >>>>>>> If so, let's get moving. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Steve > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Adam Montville [mailto:amontville@tripwire.com] > >>>>>>>> Sent: Wednesday, August 15, 2012 10:30 AM > >>>>>>>> To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos > >>>>>>>> Cc: sacm@ietf.org > >>>>>>>> Subject: Re: [sacm] Proposed use cases to move forward > >>>>>>>> > >>>>>>>> On 8/6/12 7:27 AM, "Adam Montville" > >>>>>> wrote: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> UC1 and UC3 both require assessment of endpoint state. If not > >> for > >>>>>>> the > >>>>>>>> NEA > >>>>>>>>> ties in UC1, it seems a subset of UC3. So, we should be able > >> to > >>>>>>>>> start with the main concern of UC3: Security Configuration > >>>>>>> Management. > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> I haven't seen much activity on this thread (there was another > >>>>>>> thread, > >>>>>>>> "Using the Frame of Reference," discussing some approaches we > >> can > >>>>>> use > >>>>>>>> to keep us focused and meaningful). > >>>>>>>> > >>>>>>>> Are there any objections to tackling UC3 followed by UC1? > Does > >>>>>>> anyone > >>>>>>>> disagree with my assertion that UC3 is a subset of UC1 and > that > >> a > >>>>>>>> reasonable starting point is Security Configuration > Management? > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> sacm mailing list > >>>>>>> sacm@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/sacm > >>>>>> _______________________________________________ > >>>>>> sacm mailing list > >>>>>> sacm@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sacm > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> sacm mailing list > >>>> sacm@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sacm > >>>> > >>>> > >>>> > >>>> > >>> > >> > >> > >> > >> > >> _______________________________________________ > >> sacm mailing list > >> sacm@ietf.org > >> https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From shanna@juniper.net Tue Aug 21 10:53: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 600B321F8781 for ; Tue, 21 Aug 2012 10:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 LmvVxsM9Z9M0 for ; Tue, 21 Aug 2012 10:53:50 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 92A7C21F877F for ; Tue, 21 Aug 2012 10:53:48 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUDPLK9E3usfOMS9so7ziDQXaqldSa/c9@postini.com; Tue, 21 Aug 2012 10:53:48 PDT 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; Tue, 21 Aug 2012 10:53:37 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Aug 2012 10:53:37 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 21 Aug 2012 13:53:36 -0400 From: Stephen Hanna To: "Kent_Landfield@mcafee.com" , "amontville@tripwire.com" , "sacm@ietf.org" Date: Tue, 21 Aug 2012 13:53:35 -0400 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1/sCER24TeAy1hSrGGK0RJwQhv4gABxY7w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AC6674AB7BC78549BB231821ABF7A9AEB913994F72EMBX01WFjnprn_" MIME-Version: 1.0 Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 17:53:52 -0000 --_000_AC6674AB7BC78549BB231821ABF7A9AEB913994F72EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with your understanding of the process and I'm fine with having rem= ediation mentioned in the charter. I just don't think we should have it as = a deliverable in the schedule. Thanks, Steve From: Kent_Landfield@mcafee.com [mailto:Kent_Landfield@mcafee.com] Sent: Tuesday, August 21, 2012 11:19 AM To: Stephen Hanna; amontville@tripwire.com; sacm@ietf.org Subject: Re: [sacm] Proposed use cases to move forward Steve wrote.... Remediation is a great topic but we should not work on it in this (proposed) working group at this time. Instead, we should include hooks for sending remediation instructions (like the NEA Working Group did in PA-TNC) and encourage others to create and experiment with various remediation systems. When they have found something that works, we can bring it into SACM or just publish it straight as an RFC. My question is more about how to properly address this in the charter rathe= r than if this should be addressed directly... Today the charter states: This working group will develop security automation standards in suppor= t of information security processes and practices where practical. These standards will support security practi= tioners to be betterutilized within their organizations by allowing them to meet the more advanced needs of the security commun= ity (e.g. information sharing, continuous monitoring, remediation and response, result aggregation and analysis). My understanding is this type of reference will include remediation as a po= tential "in-scope" work item if there is sufficient interest in the group t= o do so but does not obligate us to tackle the issue directly as a delivera= ble. It allows us to accept non-identified (at the time of charter) I-Ds i= nto the working group if it is so decided by the group the I-D is a valuabl= e work item. Remediation aside, is my understanding of the process accurate? Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com --_000_AC6674AB7BC78549BB231821ABF7A9AEB913994F72EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with your understanding of the proce= ss and I’m fine with having remediation mentioned in the charter. I j= ust don’t think we should have it as a deliverable in the schedule.

 

Thanks,

 

Steve

 

=

From: Kent_Landfield@mcafee.com [mailto:Kent_Landfield@m= cafee.com]
Sent: Tuesday, August 21, 2012 11:19 AM
To:= Stephen Hanna; amontville@tripwire.com; sacm@ietf.org
Subject: R= e: [sacm] Proposed use cases to move forward

 

Ste= ve wrote….

=   &n= bsp; Remediation is a great topic but we should not work on it in

    this (proposed) working gr= oup at this time. Instead, we should

    include hooks for sending remediation instructions (lik= e the

    NEA Working= Group did in PA-TNC) and encourage others to create

<= /div>

    and experiment with various remediation= systems. When they have

 =   found something that works, we can bring it into SACM or just<= /o:p>

   publish it straight as = an RFC.

 =

My question is more about how to properly= address this in the charter rather than if this should be addressed direct= ly…  

 

Today the charter states:

 

    This working group will develop security automation s= tandards in support of information security processes and 

    practices where practic= al. These standards will support security practitioners to be betterutilize= d within their organizations 

    by allowing them to meet the more advanced needs of = the security community (e.g. information sharing, continuous monitorin= g, 

    remedi= ation and response, result aggregation and analysis).

 

My understanding is this type of reference will include remediation as= a potential "in-scope" work item if there is sufficient interest= in the group to do so but does not obligate us to tackle the issue directl= y as a deliverable.  It allows us to accept non-identified (at the tim= e of charter) I-Ds into the working group if it is so decided by the group = the I-D is a valuable work item.  

 

Remediation asi= de, is my understanding of the process accurate?

 

Kent Landfield

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

 

= &nbs= p;

 

=

 

= --_000_AC6674AB7BC78549BB231821ABF7A9AEB913994F72EMBX01WFjnprn_-- From gunnar.engelbach@threatguard.com Tue Aug 21 12:04: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 32F4A21F86F4 for ; Tue, 21 Aug 2012 12:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[AWL=-0.323, 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 Etqt6qRsiEpg for ; Tue, 21 Aug 2012 12:04:47 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id B0AFE21F86EF for ; Tue, 21 Aug 2012 12:04:47 -0700 (PDT) Received: (qmail 6994 invoked from network); 21 Aug 2012 12:04:13 -0700 Received: from h69-130-58-233.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.227?) (69.130.58.233) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 21 Aug 2012 12:04:13 -0700 Message-ID: <5033DBD0.7090609@ThreatGuard.com> Date: Tue, 21 Aug 2012 15:04:48 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 CC: "sacm@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 19:04:48 -0000 Same goes for SOHO. I think it needs to be recognized up front that SOHO and Enterprise are not the same, but I don't expect the initial deliverables to address that. I don't see any dissent from UC1 and UC3 as the starting point. The process of breaking those up into deliverables will, I think, give a more concrete idea of the scope of work and help decide which items should get the initial attention. --gun On 8/21/2012 1:53 PM, Stephen Hanna wrote: > I agree with your understanding of the process and I’m fine with having > remediation mentioned in the charter. I just don’t think we should have > it as a deliverable in the schedule. > > Thanks, > > Steve > > *From:*Kent_Landfield@mcafee.com [mailto:Kent_Landfield@mcafee.com] > *Sent:* Tuesday, August 21, 2012 11:19 AM > *To:* Stephen Hanna; amontville@tripwire.com; sacm@ietf.org > *Subject:* Re: [sacm] Proposed use cases to move forward > > Steve wrote…. > > Remediation is a great topic but we should not work on it in > > this (proposed) working group at this time. Instead, we should > > include hooks for sending remediation instructions (like the > > NEA Working Group did in PA-TNC) and encourage others to create > > and experiment with various remediation systems. When they have > > found something that works, we can bring it into SACM or just > > publish it straight as an RFC. > > My question is more about how to properly address this in the charter > rather than if this should be addressed directly… > > Today the charter states: > > This working group will develop security automation standards in > support of information security processes and > > practices where practical. These standards will support security > practitioners to be betterutilized within their organizations > > by allowing them to meet the more advanced needs of the > security community (e.g. information sharing, continuous monitoring, > > remediation and response, result aggregation and analysis). > > My understanding is this type of reference will include remediation as a > potential "in-scope" work item if there is sufficient interest in the > group to do so but does not obligate us to tackle the issue directly as > a deliverable. It allows us to accept non-identified (at the time of > charter) I-Ds into the working group if it is so decided by the group > the I-D is a valuable work item. > > Remediation aside, is my understanding of the process accurate? > > *Kent Landfield* > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From amontville@tripwire.com Tue Aug 21 14:40:59 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 5573D21F8697 for ; Tue, 21 Aug 2012 14:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.43 X-Spam-Level: X-Spam-Status: No, score=-5.43 tagged_above=-999 required=5 tests=[AWL=1.169, 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 pgmjyH-27pcE for ; Tue, 21 Aug 2012 14:40:57 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7C79B21F869C for ; Tue, 21 Aug 2012 14:40:54 -0700 (PDT) Received: from mail27-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 Aug 2012 21:40:53 +0000 Received: from mail27-tx2 (localhost [127.0.0.1]) by mail27-tx2-R.bigfish.com (Postfix) with ESMTP id CD4BA602EA for ; Tue, 21 Aug 2012 21:40:53 +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: -43 X-BigFish: VPS-43(zzbb2dI98dI9371I1503M168aJ542M1432I1418I1455M4015Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839he5bhf0ah107ah) Received: from mail27-tx2 (localhost.localdomain [127.0.0.1]) by mail27-tx2 (MessageSwitch) id 1345585251996532_16802; Tue, 21 Aug 2012 21:40:51 +0000 (UTC) Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.248]) by mail27-tx2.bigfish.com (Postfix) with ESMTP id F0CD11201A5 for ; Tue, 21 Aug 2012 21:40:51 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 Aug 2012 21:40:51 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 146CB23211E0 for ; Tue, 21 Aug 2012 14:39:49 -0700 (PDT) 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 518F123211D9; Tue, 21 Aug 2012 14:39:48 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Aug 2012 14:42:31 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Tue, 21 Aug 2012 14:40:49 -0700 From: Adam Montville To: Stephen Hanna Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwgAGFQsxAAAviVgACqobYAABd1KwAAAOIbcAAAvwn5AAAbMtAADfY2AA== Date: Tue, 21 Aug 2012 21:40:48 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.16.97.57] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="iso-8859-2" Content-ID: <48B768CDE3A07746AA09E64C86EE3359@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: bc402fee-8356-4315-b298-d5b5ff899c41 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: "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 21 Aug 2012 21:40:59 -0000 Remind me not to bore you on a call - you'll have too much time to dig up useful data :-) At the end of it all, I believe you're correct in that we are agreeing. I would much prefer to see a more complete view of the work this group would like to do over time and stage it using milestones. I further agree that remediation is the least understood of the subdomains, and have no issue relegating such work to a later stage. Adam On 8/21/12 10:15 AM, "Stephen Hanna" wrote: >Adam Montville wrote: >> For the sake of playing devil's advocate, if we have deliverables and >> milestones (implying order), what warrants "to much" work? > >There's no hard-and-fast rule for this but I was just on >a boring concall so I ran some numbers on the existing >IETF SEC area Working Groups. > >* The number of WG documents varies from 0 to 11 with 3/4 of the > WGs having between 2 & 6 WG documents. > >* The number of authors per WG document (not double-counting authors > who are on more than one doc in a single WG) varies from 1.25 to > 3.5 with 2/3 of the WGs having between 1.4 and 2.3 authors per spec. > >* The number of emails per month varies between about 8 and about 150. > Removing two WGs with lots of legacy RFCs and therefore an extra > amount of email traffic (PKIX and IPSECME), the number of emails > per month per WG document varies between 6 and 20 with the > average around 12. > >Looking at SACM, 9 WG documents would be way more than average >for the SEC area. Our email list traffic is about 60 emails per >month. That would indicate we can support about 5 WG documents. >I think that's consistent with the number of active participants >and likely document authors that I have seen on the list so far. >I see about 15 active participants on the list in the last few >months. We could gain or lose some as time goes on but that's >what I see. If half of those become document editors, we could >easily support 4-5 WG documents. > >Maybe we should figure out how to stage our work into two stages. >That way, we could have 4-5 documents in a first stage and 4-5 >documents in a second stage. Many WGs do that. We can list all >the documents in our charter and have milestones that stage them. > >Now that I reread your email, I think that's exactly what you >were suggesting. So maybe we're agreeing! But I still think >that remediation shouldn't be in the first two stages. It's >the least understood aspect of this work. > >Thanks, > >Steve > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Adam Montville >> Sent: Tuesday, August 21, 2012 10:58 AM >> To: Stephen Hanna >> Cc: Kent_Landfield@McAfee.com; sacm@ietf.org >> Subject: Re: [sacm] Proposed use cases to move forward >> >> >> >> On Aug 21, 2012, at 7:55 AM, "Stephen Hanna" >> wrote: >> >> > In the current charter, I see 3 areas of focus, 2 Informational >> > documents, and at least 9 Standards Track documents. That's more >> > than one Working Group should be taking on at one time. We need >> > to focus on narrowing our scope not expanding it. >> >> >> For the sake of playing devil's advocate, if we have deliverables and >> milestones (implying order), what warrants "to much" work? >> >> >> >> >> > >> > Remediation is a great topic but we should not work on it in >> > this (proposed) working group at this time. Instead, we should >> > include hooks for sending remediation instructions (like the >> > NEA Working Group did in PA-TNC) and encourage others to create >> > and experiment with various remediation systems. When they have >> > found something that works, we can bring it into SACM or just >> > publish it straight as an RFC. >> > >> > At least, that's my view. >> > >> > Thanks, >> > >> > Steve >> > >> >> -----Original Message----- >> >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >> Of >> >> Adam Montville >> >> Sent: Tuesday, August 21, 2012 10:11 AM >> >> To: Kent_Landfield@McAfee.com; sacm@ietf.org >> >> Subject: Re: [sacm] Proposed use cases to move forward >> >> >> >> On 8/20/12 12:59 PM, "Kent_Landfield@McAfee.com" >> >> wrote: >> >>> One question that I did have is the draft charter talks about >> >>> remediation. What are other's thoughts on including that as a >> >>> 'potential' for the work to be done under SACM? >> >> >> >> >> >> >> >> I would like to see it included. We may need to rethink some of the >> >> work >> >> that has already been done in this area. Maybe we start by >> providing >> >> some >> >> way to standardize the minimum set of information that should be >> >> represented in manual remediation instructions before we move on to >> >> automated remediation - essentially, walk before we run. >> >> >> >> >> >> >> >>> >> >>> --------------------------------- >> >>> Security Automation Continuous Monitoring (SACM) >> >>> >> >>> >> >>> Proposed Working Group Charter >> >>> >> >>> >> >>> Chairs: >> >>> TBD >> >>> TBD >> >>> >> >>> >> >>> Security Area Directors: >> >>> Stephen Farrell >> >>> Sean Turner >> >>> >> >>> >> >>> Security Area Advisor: >> >>> Sean Turner >> >>> >> >>> >> >>> Mailing Lists: >> >>> General Discussion: sacm@ietf.org >> >>> To Subscribe: >> http://www.ietf.org/mailman/listinfo/sacm >> >>> Archive: http://www.ietf.org/mail- >> archive/web/sacm >> >>> >> >>> >> >>> Description of Working Group >> >>> >> >>> >> >>> Securing information and the systems that store, process, and >> transmit >> >>> that information has become a challenging task for organizations of >> >> all >> >>> sizes, and we find that security practitioners spend most of their >> >> time >> >>> on manual processes relegating them to >> >>> ineffectiveness. Security automation is the key to escaping this >> rut. >> >>> This working group will develop security automation standards in >> >> support >> >>> of information security processes and practices where practical. >> These >> >>> standards will support security practitioners >> >>> to be better utilized within their organizations by allowing them >> to >> >>> meet the more advanced needs of the security community (e.g. >> >> information >> >>> sharing, continuous monitoring, remediation and response, result >> >>> aggregation and analysis). The initial focus of this >> >>> work is to address enterprise and SOHO use cases. The working group >> >> will >> >>> achieve this by consuming and continuing (with cooperation) the >> >> security >> >>> automation work already performed by various organizations around >> the >> >>> world. >> >>> >> >>> >> >>> The initial work has been fruitful, and the data formats previously >> >>> published are ready for expansion on the international stage. Of >> >>> particular interest to this working group are the security >> automation >> >>> specifications supporting asset, change, configuration, >> >>> and vulnerability management. Of additional interest to this >> working >> >>> group are the emerging security automation interfaces and data >> formats >> >>> relating to event management and continuous monitoring. >> >>> >> >>> >> >>> By undertaking this work, we recognize that there are multiple >> >> categories >> >>> of problems in the security automation domain: defining expressions >> >> for >> >>> particular domain concepts (i.e. data formats), establishing a >> >>> standards-based foundation supporting the curation >> >>> and exchange of security automation content collections in content >> >>> repositories and enabling interoperability through the development >> and >> >>> use of interfaces and communications protocols. Content based on >> rich >> >>> data standards and protocols will provide the authoritative >> >>> instructions needed by data-driven tools to enable the automated >> >>> collection and exchange of configuration and vulnerability data >> >>> pertaining to enterprise assets. Information produced by these >> tools >> >> will >> >>> provide accurate and timely situational awareness in >> >>> support of organizational decision making. >> >>> >> >>> >> >>> This working group will provide solutions to these categories of >> >> problems >> >>> and the main areas of focus for this working group are described as >> >>> follows: >> >>> >> >>> >> >>> 1. Define, either by normative reference, adoption, or creation, a >> set >> >> of >> >>> standards that can be used for the purpose of assessing, >> aggregating >> >> and >> >>> comparing device states against expected values, and reporting on >> >> those >> >>> results in a predefined or ad hoc >> >>> manner. >> >>> >> >>> >> >>> >> >>> 2. Define, either by normative reference, adoption, or creation, a >> set >> >> of >> >>> standards that can be used to continuously monitor and report on >> the >> >>> state of systems, composed of many different types of devices and >> >>> networks, operated by varying personnel, to >> >>> ensure security process effectiveness in a pre-defined or ad-hoc >> >> manner. >> >>> >> >>> >> >>> 3. Create relationships between existing operations management >> >> standards >> >>> to enable a comprehensive view of security automation, leveraging >> >>> existing work and implementations. >> >> >> >> >> >> >> >> At some point I believe we had a 4 and 5 here as well. I can't >> >> remember, >> >> were those recommended to be removed? >> >> >> >> Otherwise, I agree with the three "main" areas of focus. >> >> >> >> >> >> >> >>> >> >>> >> >>> This working group will produce the following: >> >>> >> >>> >> >>> * An Informational document providing an overview of security >> >> automation >> >>> and continuous monitoring to include a reference model >> >> >> >> >> >> Is this a reference to the use case document or something else (I.e. >> >> the >> >> informational document I've talked about in the past)? >> >> >> >> >> >> >> >>> * A Standards Track document specifying benchmark configuration >> >>> representation (XCCDF) >> >>> * An Informational document stating guidelines / requirements for >> >>> specifying checking languages >> >>> * Standards Track documents specifying device state checking >> languages >> >>> (OVAL, ECL, ACEML, =A9) >> >>> * A Standards Track document specifying an interrogative checking >> >>> language (OCIL) >> >>> * A Standards Track document specifying platform naming, matching >> and >> >>> applicability (CPE) >> >>> * Standards Track documents specifying asset identification and >> >> reporting >> >>> information (Asset ID, ARF) >> >>> * Standards Track documents specifying interfaces and communication >> >>> protocols used for security automation and continuous monitoring >> >>> * A Standards Track document describing the messages and network >> >>> protocols for distributing Security Automation Content (content >> >>> repository) >> >> >> >> >> >> I would remove the word "network" from "network protocols." >> >> >> >> >> >>> * Standards Track document describing integrating security >> automation >> >> and >> >>> Network Endpoint Assessment capabilities (if-m for SCAP?) >> >>> * A Standards Track document describing protocols and data formats >> for >> >>> securely sharing dynamic network state information among security >> >> systems >> >>> (if-map) >> >> >> >> >> >> >> >> I was working on some thought exercises yesterday for the Use Case >> >> document, and I think we might have some gaps in existing >> capabilities >> >> that we should address (either through normative reference or by >> >> creating >> >> something new): >> >> >> >> 1. Do we need a way to identify, express, and perhaps score patches >> in >> >> a >> >> way that differs from vulnerabilities? This may be something akin >> to >> >> CPE >> >> - perhaps an extension to it. >> >> >> >> 2. Should we consider breaking apart the constituents of a technical >> >> control checking system in a way that allows us to talk about >> security >> >> and >> >> non-security related system objects? There are almost certainly >> ties >> >> to >> >> other areas of IETF and perhaps other SDOs here, but I can use OVAL >> as >> >> a >> >> frame of reference. OVAL talks about definitions, tests, objects, >> >> states, >> >> and values (ultimately assigned to states). Is there a need to talk >> >> about >> >> objects, and their applicable range of states, outside the context >> of >> >> what >> >> we would generically call a test? >> >> >> >> 3. Do we need a way to talk about assets in a non-identifying way? >> I'm >> >> thinking things like criticality, classification (I.e. level of >> >> secrecy), >> >> and other properties that may not necessarily be used for the >> purposes >> >> of >> >> identification? >> >> >> >> 4. Do we need to consider documents dealing with targeting issues? >> >> >> >> These four points essentially speak to functional components that >> may >> >> be >> >> lacking in the existing set of specifications/formats. It is my >> >> expectation that the Use Case document will identify and highlight >> such >> >> gaps, where we know we need certain functional capabilities >> (security >> >> configuration management including configuration assessment and >> >> remediation, asset characterization/management, and vulnerability >> >> assessment, perhaps among others). >> >> >> >> >> >> >> >> >> >>> >> >>> >> >>> Goals and Milestones >> >>> >> >>> >> >>> TBD >> >>> -------------------------------------------- >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> Thanks. >> >>> >> >>> >> >>> Kent Landfield >> >>> >> >>> McAfee | An Intel Company >> >>> Direct: +1.972.963.7096 >> >>> Mobile: +1.817.637.8026 >> >>> Web: www.mcafee.com >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> From: Adam Montville >> >>> Date: Friday, August 17, 2012 12:33 PM >> >>> To: David Waltermire , Stephen Hanna >> >>> , Luis Nunez , >> >>> Omar Santos >> >>> Cc: "sacm@ietf.org" >> >>> Subject: Re: [sacm] Proposed use cases to move forward >> >>> >> >>> >> >>> >> >>>> I like taking the scope down as well - and I think we all believe >> >> we've >> >>>> agreed to UC1 and UC3. I don't have an issue having the other use >> >> cases >> >>>> (2, 4, and 5) described in the use case document, but not fleshed >> out >> >> in >> >>>> the functional capabilities, components, and data/protocol >> sections. >> >> The >> >>>> charter can be derived from the use cases we take on, and a >> separate >> >>>> informational document can help place those use cases in the right >> >>>> context >> >>>> with respect to the "grand scheme of things." >> >>>> >> >>>> >> >>>> No matter how we slice it, right now we need to focus on the use >> >> cases >> >>>> and >> >>>> charter, and to focus on the use cases we would ideally need to >> work >> >> on >> >>>> setting the context. I've tried to do that (to a limited extent) >> >> with >> >>>> the >> >>>> informational document I sent to the list. >> >>>> >> >>>> >> >>>> Additionally, I think these efforts need to be done in parallel >> >>>> irrespective of any idealistic dependencies. For example, we >> should >> >> be >> >>>> able to work on a charter, a use case doc, and an informational >> doc >> >> all >> >>>> at >> >>>> the same time, but join the threads for a final alignment pass >> before >> >>>> submitting them. >> >>>> >> >>>> >> >>>> Adam >> >>>> >> >>>> >> >>>> On 8/17/12 9:30 AM, "Waltermire, David A." >> >> >> >>>> wrote: >> >>>> >> >>>> >> >>>>> Steve, >> >>>>> >> >>>>> >> >>>>> These are all valid concerns that I completely agree with. What >> I >> >> am >> >>>>> struggling with is insuring that the work we are embarking on >> >> remains >> >>>>> relevant in the broader context. My fear is that if we narrow >> our >> >>>>> thinking too much, we may inadvertently make decisions that drift >> >> from >> >>>>> addressing the broader set of use cases. I like the idea of >> working >> >> on >> >>>>> an individual draft to address the larger context. What I am not >> >> sure >> >>>>> about is how introduce a feedback loop that would result in >> >> minimizing >> >>>>> this kind of risk. I guess this type of issue is something that >> we >> >> will >> >>>>> need to collectively monitor and address as needed. >> >>>>> >> >>>>> >> >>>>> Sincerely, >> >>>>> Dave >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: Stephen Hanna [mailto:shanna@juniper.net] >> >>>>> Sent: Wednesday, August 15, 2012 3:55 PM >> >>>>> To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos >> >>>>> Cc: sacm@ietf.org >> >>>>> Subject: RE: [sacm] Proposed use cases to move forward >> >>>>> >> >>>>> >> >>>>> I love broad scope. Don't get me wrong! But I'm concerned about >> >> having a >> >>>>> use cases document and an architecture document for this working >> >> group >> >>>>> that goes way beyond the charter and initial scope for the group. >> >>>>> >> >>>>> >> >>>>> I'm concerned that this will lead to lots of discussions on the >> sacm >> >>>>> list >> >>>>> and lots of effort being spent on topics that are out of scope, >> >>>>> diverting >> >>>>> us from the tasks at hand and slowing our progress. >> >>>>> >> >>>>> >> >>>>> I'm concerned that the working group chairs won't be able to cut >> off >> >>>>> discussion of topics by saying they're out of scope for the >> working >> >>>>> group. >> >>>>> >> >>>>> >> >>>>> I'm concerned that we'll get sidetracked or even derailed by >> >>>>> controversies that aren't relevant to the scope of the group. >> >>>>> >> >>>>> >> >>>>> I'm concerned that by including all of security automation within >> >> our >> >>>>> use >> >>>>> cases and architecture, we may actually prevent the formation of >> >> other >> >>>>> working groups that could work on those other use cases. >> >>>>> >> >>>>> >> >>>>> We have plenty of work to keep us busy for years with UC1 and >> UC3. >> >>>>> There's agreement that the technology needed is mature enough for >> >> IETF >> >>>>> standardization. I suggest that we scope this working group to >> >> address >> >>>>> only those use cases and that our use cases and architecture be >> >> limited >> >>>>> to them. >> >>>>> >> >>>>> >> >>>>> I'm sorely tempted to create an ambitious architecture for >> security >> >>>>> automation that encompasses all of the use cases that we have >> >> described >> >>>>> so far and maybe more. I understand that people have a hard time >> >>>>> understanding how the NEA and MILE and SACM standards fit >> together >> >> and I >> >>>>> would love to address that in an IETF RFC. But I have seen >> several >> >> grand >> >>>>> architecture efforts die or come to nothing in IETF. IETF is >> filled >> >> with >> >>>>> smart engineers with clever ideas. We're great at solving >> problems >> >> but >> >>>>> if >> >>>>> we can't agree on the problem to solve or if we choose the wrong >> >>>>> problem, >> >>>>> we can easily spin an intricate and pointless web. >> >>>>> >> >>>>> >> >>>>> I think we'll do better if we scope our effort properly. >> >>>>> >> >>>>> >> >>>>> Maybe a few people can create an individual submission describing >> a >> >>>>> grand >> >>>>> architecture and roadmap for security automation and ask people >> in >> >> SACM >> >>>>> to review and provide feedback on that document. That would be a >> >> good >> >>>>> way >> >>>>> to get a grand architecture while still ensuring that the SACM >> >> effort >> >>>>> keeps its focus. In IETF as in so many things, you must keep your >> >> focus >> >>>>> or you'll never succeed. >> >>>>> >> >>>>> >> >>>>> Thanks, >> >>>>> >> >>>>> >> >>>>> Steve >> >>>>> >> >>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> >> Behalf >> >>>>>> Of Waltermire, David A. >> >>>>>> Sent: Wednesday, August 15, 2012 1:13 PM >> >>>>>> To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos >> >>>>>> Cc: sacm@ietf.org >> >>>>>> Subject: Re: [sacm] Proposed use cases to move forward >> >>>>>> +1 on scoping the charter to UC1 and UC3. >> >>>>>> I think we are better served with a use cases document, and >> >> eventually >> >>>>>> an architecture documemnt, that is broader scoped. Both of >> these >> >>>>>> documents will help inform the work we will do under the charter >> as >> >> it >> >>>>>> relates to the larger context. >> >>>>>> To this end I would suggest we focus on expanding the use case >> >>>>>> document primarily in the areas of UC1 and UC3 for now. We can >> >> expand >> >>>>>> the other use cases later. >> >>>>>> Sincerely, >> >>>>>> Dave >> >>>>>>> -----Original Message----- >> >>>>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> >> Behalf >> >>>>>> Of >> >>>>>>> Stephen Hanna >> >>>>>>> Sent: Wednesday, August 15, 2012 11:24 AM >> >>>>>>> To: Adam Montville; Luis Nunez; Omar Santos >> >>>>>>> Cc: sacm@ietf.org >> >>>>>>> Subject: Re: [sacm] Proposed use cases to move forward >> >>>>>>> >> >>>>>>> I agree. Let's work on UC1 and UC3. The other use cases are >> >> valuable >> >>>>>>> but just doing UC1 and UC3 is plenty of work for this group for >> >> the >> >>>>>>> next year or two (maybe five!). >> >>>>>>> >> >>>>>>> I saw several emails in favor of this a few weeks ago. I >> thought >> >>>>>>> that it was settled. I'd like to see a revised charter and use >> >> case >> >>>>>>> document, scoped down to focus on just UC1 and UC3. >> >>>>>>> >> >>>>>>> What do others think? Do we have rough consensus on this? >> >>>>>>> If so, let's get moving. >> >>>>>>> >> >>>>>>> Thanks, >> >>>>>>> >> >>>>>>> Steve >> >>>>>>> >> >>>>>>>> -----Original Message----- >> >>>>>>>> From: Adam Montville [mailto:amontville@tripwire.com] >> >>>>>>>> Sent: Wednesday, August 15, 2012 10:30 AM >> >>>>>>>> To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos >> >>>>>>>> Cc: sacm@ietf.org >> >>>>>>>> Subject: Re: [sacm] Proposed use cases to move forward >> >>>>>>>> >> >>>>>>>> On 8/6/12 7:27 AM, "Adam Montville" >> >>>>>> wrote: >> >>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> UC1 and UC3 both require assessment of endpoint state. If not >> >> for >> >>>>>>> the >> >>>>>>>> NEA >> >>>>>>>>> ties in UC1, it seems a subset of UC3. So, we should be able >> >> to >> >>>>>>>>> start with the main concern of UC3: Security Configuration >> >>>>>>> Management. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> I haven't seen much activity on this thread (there was another >> >>>>>>> thread, >> >>>>>>>> "Using the Frame of Reference," discussing some approaches we >> >> can >> >>>>>> use >> >>>>>>>> to keep us focused and meaningful). >> >>>>>>>> >> >>>>>>>> Are there any objections to tackling UC3 followed by UC1? >> Does >> >>>>>>> anyone >> >>>>>>>> disagree with my assertion that UC3 is a subset of UC1 and >> that >> >> a >> >>>>>>>> reasonable starting point is Security Configuration >> Management? >> >>>>>>>> >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> sacm mailing list >> >>>>>>> sacm@ietf.org >> >>>>>>> https://www.ietf.org/mailman/listinfo/sacm >> >>>>>> _______________________________________________ >> >>>>>> sacm mailing list >> >>>>>> sacm@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/sacm >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> sacm mailing list >> >>>> sacm@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/sacm >> >>>> >> >>>> >> >>>> >> >>>> >> >>> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> sacm mailing list >> >> sacm@ietf.org >> >> https://www.ietf.org/mailman/listinfo/sacm >> > _______________________________________________ >> > sacm mailing list >> > sacm@ietf.org >> > https://www.ietf.org/mailman/listinfo/sacm >> > >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm > > From shanna@juniper.net Thu Aug 23 12:11:46 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D26421E8039 for ; Thu, 23 Aug 2012 12:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 FWOdU3tlQYGQ for ; Thu, 23 Aug 2012 12:11:34 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 78F7021E8037 for ; Thu, 23 Aug 2012 12:11:33 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUDaAZEhxv3QDtj+Ea9gTr5WfAl9h58Ca@postini.com; Thu, 23 Aug 2012 12:11:33 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 23 Aug 2012 12:11:01 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 23 Aug 2012 12:11:00 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 23 Aug 2012 15:11:00 -0400 From: Stephen Hanna To: "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Date: Thu, 23 Aug 2012 15:10:58 -0400 Thread-Topic: Proposed SACM Charter (was re: Proposed use cases to move forward) Thread-Index: Ac1/Di05WE4H3VKuQbKX+8ZBRWr2bABeVw7w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AC6674AB7BC78549BB231821ABF7A9AEB916F11040EMBX01WFjnprn_" MIME-Version: 1.0 Subject: [sacm] Proposed SACM Charter (was re: Proposed use cases to move forward) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 19:11:46 -0000 --_000_AC6674AB7BC78549BB231821ABF7A9AEB916F11040EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I did a complete review of this proposed SACM charter today. Here are my co= mments. Please review and respond! * Now that we have narrowed our focus to UC1 and UC3, we should con= tinue to narrow the charter to match that focus. One way to do this would b= e to change the proposed WG name from "Security Automation and Continuous M= onitoring" to "Security Compliance Automation" OR "Security Automation for = Compliance". The topic of security automation is a really broad one, includ= ing many MILE projects and other things that go way beyond UC1 and UC3. * In the first paragraph of the WG Description, I'd like to suggest= a few changes to this sentence: "These standards will support security pra= ctitioners to be better utilized within their organizations by allowing the= m to meet the more advanced needs of the security community (e.g. informati= on sharing, continuous monitoring, remediation and response, result aggrega= tion and analysis)." Right now, the text seems to imply that our focus will= be on defining standards to "meet the more advanced needs of the security = community", including information sharing, continuous monitoring, remediati= on and response, and result aggregation and analysis. I don't quite agree. = I think that our goal now is to automate routine tasks related to gathering= and managing information about endpoint security so that information secur= ity practitioners can focus on more advanced needs. Our scope may include s= ome aspects of information sharing, continuous monitoring, remediation and = response, and result aggregation and analysis but not the complete and tota= l extent of any of those broad topics. So I suggest this replacement senten= ce: "These standards will help security practitioners to be better utilized= within their organizations by automating routine tasks related to endpoint= security so that practitioners can focus on more advanced work." * We should delete "and SOHO" from this sentence: "The initial focu= s of this work is to address enterprise and SOHO use cases." We need to mai= ntain our focus and avoid the added complexities of SOHO. Anyway, that's my= view. * I think the last sentence in the first paragraph (about consuming= and continuing work) belongs at the start of the second paragraph. The sec= ond paragraph is about how we're going to use and enhance standards develop= ed elsewhere. The first paragraph explains why our work is needed. * In the third paragraph, I'd say "use of standard interfaces" not = just "use of interfaces". We only want to develop and use standard interfac= es. We don't want to design a system that will be based on proprietary inte= rfaces. * The first area of focus is "1. Define, either by normative refere= nce, adoption, or creation, a set of standards that can be used for the pur= pose of assessing, aggregating and comparing device states against expected= values, and reporting on those results in a predefined or ad hoc manner." = I suggest changing "assessing, aggregating and comparing device states agai= nst expected values" to "assessing and aggregating device states and compar= ing these device states against expected values". Otherwise it's not clear = which verbs are modified by the adverbial phrase "against expected values". * I don't think that the third area of focus is needed to address U= C1 and UC3. Therefore, we should take it out. That area is "3. Create relat= ionships between existing operations management standards to enable a compr= ehensive view of security automation, leveraging existing work and implemen= tations." * Let's narrow the reference model document to UC1 and UC3 and add = requirements in that document for all the standards that we're going to nee= d. That way, we can do all our architecture and requirements definition in = one place. And we can delete the other Informational document in our list o= f deliverables. * Delete the parenthetical mentions of specific existing external s= pecs from the deliverables (e.g. XCCDF, OVAL). We should not prejudge which= standard the working group will choose for each purpose. * Don't call for multiple Standards Track documents on a single top= ic at this point. We should aim to have one standard for each purpose. I th= ink this comment only applies to the device state checking languages. Asset= identification and reporting are separate things, right? If so, they shoul= d be separate deliverables. And I don't know what this deliverable means: "= Standards Track documents specifying interfaces and communication protocols= used for security automation and continuous monitoring". If we know what i= t means, let's explain it more clearly. If we don't know what it means, it = shouldn't be on the list. We can always add deliverables later if we need t= o. We should pare back our list to only things that we understand now and c= an describe. * I guess we're going to break our deliverables into two phases. Wh= ich deliverables should go in Phase 2? It's always hard to decide what can = wait but I'd suggest these: "Standards Track document describing the messag= es and network protocols for distributing Security Automation Content", "St= andards Track document describing protocols and data formats for securely s= haring dynamic network state information among security systems", and any o= f the other deliverables where we don't have a mature spec (stable with sev= eral implementations) with good IPR terms that can be published as an RFC o= r referenced with a normative reference. This will allow us to rapidly get = an open standard solution, even if it can't do everything we want. We should check whether pushing out all those deliverables will still let u= s meet a useful subset of UC1 and UC3. If not, we may need to pull some thi= ngs in from Phase 2 but doing so will probably slow down the completion of = Phase 1 considerably. We could also define a Phase 1.5 for any such items w= here lots of work is needed but we really need them. Then we could start wo= rk on those Phase 1.5 deliverables right away, knowing that they probably w= on't be ready until after the Phase 1 deliverables. And I hope that we'll m= ake the reference model and protocols extensible so that people can try out= draft specs in a prototype implementation or even make up their own soluti= on for some problem and experiment with it without causing massive problems= . To answer Kent's question about how we can most easily track differences be= tween versions of the charter, I suggest that whoever's editing the charter= (Kent, it seems) provide a plain text file version of each version of the = charter. Send that out as an attachment to your email and we can all use ou= r own tools to do a diff. Good charter discussion! Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Monday, August 20, 2012 4:00 PM To: sacm@ietf.org Subject: Re: [sacm] Proposed use cases to move forward Yes, I agree we need to focus. It appears we have consensus on working on U= C1 and UC3. The use case document as it exists is very broad and its inten= t has expanded a great deal from the initial meeting in Paris. ;-) It is time to focus on the charter and what it is we want this working grou= p to do. We need to put a reasonable box around the effort so we can be pro= ductive. To that end, what follows is an updated version of the charter that was pos= ted just prior to the Vancouver meeting. It has taken into consideration r= equests made on the lists. Let's start discussing it as is. I know there a= re some good suggestions that I have not gotten to incorporate yet. One question that I did have is the draft charter talks about remediation. = What are other's thoughts on including that as a 'potential' for the work = to be done under SACM? Please take a look at it and let's talk about what is here. We will need t= o develop the list of deliverables and the milestones we expect to meet but= that will hopefully be driven by the base charter discussions. As a point of reference, how does the list want to see differences from one= version of the charter to the next? Let's keep it simple if possible... --------------------------------- Security Automation Continuous Monitoring (SACM) Proposed Working Group Charter Chairs: TBD TBD Security Area Directors: Stephen Farrell > Sean Turner > Security Area Advisor: Sean Turner > Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm Description of Working Group Securing information and the systems that store, process, and transmit that= information has become a challenging task for organizations of all sizes, = and we find that security practitioners spend most of their time on manual = processes relegating them to ineffectiveness. Security automation is the ke= y to escaping this rut. This working group will develop security automation= standards in support of information security processes and practices where= practical. These standards will support security practitioners to be bette= r utilized within their organizations by allowing them to meet the more adv= anced needs of the security community (e.g. information sharing, continuous= monitoring, remediation and response, result aggregation and analysis). Th= e initial focus of this work is to address enterprise and SOHO use cases. T= he working group will achieve this by consuming and continuing (with cooper= ation) the security automation work already performed by various organizati= ons around the world. The initial work has been fruitful, and the data formats previously publish= ed are ready for expansion on the international stage. Of particular intere= st to this working group are the security automation specifications support= ing asset, change, configuration, and vulnerability management. Of addition= al interest to this working group are the emerging security automation inte= rfaces and data formats relating to event management and continuous monitor= ing. By undertaking this work, we recognize that there are multiple categories o= f problems in the security automation domain: defining expressions for part= icular domain concepts (i.e. data formats), establishing a standards-based = foundation supporting the curation and exchange of security automation cont= ent collections in content repositories and enabling interoperability throu= gh the development and use of interfaces and communications protocols. Cont= ent based on rich data standards and protocols will provide the authoritati= ve instructions needed by data-driven tools to enable the automated collect= ion and exchange of configuration and vulnerability data pertaining to ente= rprise assets. Information produced by these tools will provide accurate an= d timely situational awareness in support of organizational decision making= . This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used for the purpose of assessing, aggregating and com= paring device states against expected values, and reporting on those result= s in a predefined or ad hoc manner. 2. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used to continuously monitor and report on the state o= f systems, composed of many different types of devices and networks, operat= ed by varying personnel, to ensure security process effectiveness in a pre-= defined or ad-hoc manner. 3. Create relationships between existing operations management standards to= enable a comprehensive view of security automation, leveraging existing wo= rk and implementations. This working group will produce the following: * An Informational document providing an overview of security automation an= d continuous monitoring to include a reference model * A Standards Track document specifying benchmark configuration representat= ion (XCCDF) * An Informational document stating guidelines / requirements for specifyin= g checking languages * Standards Track documents specifying device state checking languages (OVA= L, ECL, ACEML, ...) * A Standards Track document specifying an interrogative checking language = (OCIL) * A Standards Track document specifying platform naming, matching and appli= cability (CPE) * Standards Track documents specifying asset identification and reporting i= nformation (Asset ID, ARF) * Standards Track documents specifying interfaces and communication protoco= ls used for security automation and continuous monitoring * A Standards Track document describing the messages and network protocols = for distributing Security Automation Content (content repository) * Standards Track document describing integrating security automation and N= etwork Endpoint Assessment capabilities (if-m for SCAP?) * A Standards Track document describing protocols and data formats for secu= rely sharing dynamic network state information among security systems (if-m= ap) Goals and Milestones TBD -------------------------------------------- Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville > Date: Friday, August 17, 2012 12:33 PM To: David Waltermire >, Stephen Hanna >, Lui= s Nunez >, Omar Santo= s > Cc: "sacm@ietf.org" > Subject: Re: [sacm] Proposed use cases to move forward I like taking the scope down as well - and I think we all believe we've agreed to UC1 and UC3. I don't have an issue having the other use cases (2, 4, and 5) described in the use case document, but not fleshed out in the functional capabilities, components, and data/protocol sections. The charter can be derived from the use cases we take on, and a separate informational document can help place those use cases in the right context with respect to the "grand scheme of things." No matter how we slice it, right now we need to focus on the use cases and charter, and to focus on the use cases we would ideally need to work on setting the context. I've tried to do that (to a limited extent) with the informational document I sent to the list. Additionally, I think these efforts need to be done in parallel irrespective of any idealistic dependencies. For example, we should be able to work on a charter, a use case doc, and an informational doc all at the same time, but join the threads for a final alignment pass before submitting them. Adam On 8/17/12 9:30 AM, "Waltermire, David A." > wrote: Steve, These are all valid concerns that I completely agree with. What I am struggling with is insuring that the work we are embarking on remains relevant in the broader context. My fear is that if we narrow our thinking too much, we may inadvertently make decisions that drift from addressing the broader set of use cases. I like the idea of working on an individual draft to address the larger context. What I am not sure about is how introduce a feedback loop that would result in minimizing this kind of risk. I guess this type of issue is something that we will need to collectively monitor and address as needed. Sincerely, Dave -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net] Sent: Wednesday, August 15, 2012 3:55 PM To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos Cc: sacm@ietf.org Subject: RE: [sacm] Proposed use cases to move forward I love broad scope. Don't get me wrong! But I'm concerned about having a use cases document and an architecture document for this working group that goes way beyond the charter and initial scope for the group. I'm concerned that this will lead to lots of discussions on the sacm list and lots of effort being spent on topics that are out of scope, diverting us from the tasks at hand and slowing our progress. I'm concerned that the working group chairs won't be able to cut off discussion of topics by saying they're out of scope for the working group. I'm concerned that we'll get sidetracked or even derailed by controversies that aren't relevant to the scope of the group. I'm concerned that by including all of security automation within our use cases and architecture, we may actually prevent the formation of other working groups that could work on those other use cases. We have plenty of work to keep us busy for years with UC1 and UC3. There's agreement that the technology needed is mature enough for IETF standardization. I suggest that we scope this working group to address only those use cases and that our use cases and architecture be limited to them. I'm sorely tempted to create an ambitious architecture for security automation that encompasses all of the use cases that we have described so far and maybe more. I understand that people have a hard time understanding how the NEA and MILE and SACM standards fit together and I would love to address that in an IETF RFC. But I have seen several grand architecture efforts die or come to nothing in IETF. IETF is filled with smart engineers with clever ideas. We're great at solving problems but if we can't agree on the problem to solve or if we choose the wrong problem, we can easily spin an intricate and pointless web. I think we'll do better if we scope our effort properly. Maybe a few people can create an individual submission describing a grand architecture and roadmap for security automation and ask people in SACM to review and provide feedback on that document. That would be a good way to get a grand architecture while still ensuring that the SACM effort keeps its focus. In IETF as in so many things, you must keep your focus or you'll never succeed. Thanks, Steve -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Waltermire, David A. Sent: Wednesday, August 15, 2012 1:13 PM To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos Cc: sacm@ietf.org Subject: Re: [sacm] Proposed use cases to move forward +1 on scoping the charter to UC1 and UC3. I think we are better served with a use cases document, and eventually an architecture documemnt, that is broader scoped. Both of these documents will help inform the work we will do under the charter as it relates to the larger context. To this end I would suggest we focus on expanding the use case document primarily in the areas of UC1 and UC3 for now. We can expand the other use cases later. Sincerely, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bo= unces@ietf.org] On Behalf Of > Stephen Hanna > Sent: Wednesday, August 15, 2012 11:24 AM > To: Adam Montville; Luis Nunez; Omar Santos > Cc: sacm@ietf.org > Subject: Re: [sacm] Proposed use cases to move forward > > I agree. Let's work on UC1 and UC3. The other use cases are valuable > but just doing UC1 and UC3 is plenty of work for this group for the > next year or two (maybe five!). > > I saw several emails in favor of this a few weeks ago. I thought > that it was settled. I'd like to see a revised charter and use case > document, scoped down to focus on just UC1 and UC3. > > What do others think? Do we have rough consensus on this? > If so, let's get moving. > > Thanks, > > Steve > > > -----Original Message----- > > From: Adam Montville [mailto:amontville@tripwire.com] > > Sent: Wednesday, August 15, 2012 10:30 AM > > To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Proposed use cases to move forward > > > > On 8/6/12 7:27 AM, "Adam Montville" > wrote: > > > > > > > > > > >UC1 and UC3 both require assessment of endpoint state. If not for > the > > NEA > > >ties in UC1, it seems a subset of UC3. So, we should be able to > > >start with the main concern of UC3: Security Configuration > Management. > > > > > > > > > > > > I haven't seen much activity on this thread (there was another > thread, > > "Using the Frame of Reference," discussing some approaches we can use > > to keep us focused and meaningful). > > > > Are there any objections to tackling UC3 followed by UC1? Does > anyone > > disagree with my assertion that UC3 is a subset of UC1 and that a > > reasonable starting point is Security Configuration Management? > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_AC6674AB7BC78549BB231821ABF7A9AEB916F11040EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I did a c= omplete review of this proposed SACM charter today. Here are my comments. P= lease review and respond!

=  

·   &= nbsp;     Now tha= t we have narrowed our focus to UC1 and UC3, we should continue to narrow t= he charter to match that focus. One way to do this would be to change the p= roposed WG name from “Security Automation and Continuous Monitoring&#= 8221; to “Security Compliance Automation” OR “Security Au= tomation for Compliance”. The topic of security automation is a reall= y broad one, including many MILE projects and other things that go way beyo= nd UC1 and UC3.

· &nbs= p;       In the first paragraph of the WG Description, I’d like to suggest a= few changes to this sentence: “These standards will support security= practitioners to be better utilized within their organizations by allowing= them to meet the more advanced needs of the security community (e.g. infor= mation sharing, continuous monitoring, remediation and response, result agg= regation and analysis).” Right now, the text seems to imply that our = focus will be on defining standards to “meet the more advanced needs = of the security community”, including information sharing, continuous= monitoring, remediation and response, and result aggregation and analysis.= I don’t quite agree. I think that our goal now is to automate routin= e tasks related to gathering and managing information about endpoint securi= ty so that information security practitioners can focus on more advanced ne= eds. Our scope may include some aspects of information sharing, continuous = monitoring, remediation and response, and result aggregation and analysis b= ut not the complete and total extent of any of those broad topics. So I sug= gest this replacement sentence: “These standards will help security p= ractitioners to be better utilized within their organizations by automating= routine tasks related to endpoint security so that practitioners can focus= on more advanced work.”

·         = We should delete “and SOHO” from this sentence= : “The initial focus of this work is to address enterprise and SOHO u= se cases.” We need to maintain our focus and avoid the added complexi= ties of SOHO. Anyway, that’s my view.

·         I think the last sentence in the first para= graph (about consuming and continuing work) belongs at the start of the sec= ond paragraph. The second paragraph is about how we’re going to use a= nd enhance standards developed elsewhere. The first paragraph explains why = our work is needed.

· = ;        = In the third paragraph, I’d say “use of standard interfa= ces” not just “use of interfaces”. We only want to develo= p and use standard interfaces. We don’t want to design a system that = will be based on proprietary interfaces.

·         The first area of focus is “1. Define, eit= her by normative reference, adoption, or creation, a set of standards that = can be used for the purpose of assessing, aggregating and comparing device = states against expected values, and reporting on those results in a predefi= ned or ad hoc manner.” I suggest changing “assessing, aggregati= ng and comparing device states against expected values” to “ass= essing and aggregating device states and comparing these device states agai= nst expected values”. Otherwise it’s not clear which verbs are = modified by the adverbial phrase “against expected values”.

·= ;     = ;    I don’t thi= nk that the third area of focus is needed to address UC1 and UC3. Therefore= , we should take it out. That area is “3. Create relationships betwee= n existing operations management standards to enable a comprehensive view o= f security automation, leveraging existing work and implementations.”=

&mi= ddot;    &= nbsp;    Let’s n= arrow the reference model document to UC1 and UC3 and add requirements in t= hat document for all the standards that we’re going to need. That way= , we can do all our architecture and requirements definition in one place. = And we can delete the other Informational document in our list of deliverab= les.

·   &nb= sp;     Delete th= e parenthetical mentions of specific existing external specs from the deliv= erables (e.g. XCCDF, OVAL). We should not prejudge which standard the worki= ng group will choose for each purpose.

·         Don’t call for multiple Standards Track docu= ments on a single topic at this point. We should aim to have one standard f= or each purpose. I think this comment only applies to the device state chec= king languages. Asset identification and reporting are separate things, rig= ht? If so, they should be separate deliverables. And I don’t know wha= t this deliverable means: “Standards Track documents specifying inter= faces and communication protocols used for security automation and continuo= us monitoring”. If we know what it means, let’s explain it more= clearly. If we don’t know what it means, it shouldn’t be on th= e list. We can always add deliverables later if we need to. We should pare = back our list to only things that we understand now and can describe.<= /o:p>

·<= span style=3D'font:7.0pt "Times New Roman"'>     &= nbsp;   I guess we’re= going to break our deliverables into two phases. Which deliverables should= go in Phase 2? It’s always hard to decide what can wait but I’= d suggest these: “Standards Track document describing the messages an= d network protocols for distributing Security Automation Content”, &#= 8220;Standards Track document describing protocols and data formats for sec= urely sharing dynamic network state information among security systems̶= 1;, and any of the other deliverables where we don’t have a mature sp= ec (stable with several implementations) with good IPR terms that can be pu= blished as an RFC or referenced with a normative reference. This will allow= us to rapidly get an open standard solution, even if it can’t do eve= rything we want.

We should check whether pushing out all those deliv= erables will still let us meet a useful subset of UC1 and UC3. If not, we m= ay need to pull some things in from Phase 2 but doing so will probably slow= down the completion of Phase 1 considerably. We could also define a Phase = 1.5 for any such items where lots of work is needed but we really need them= . Then we could start work on those Phase 1.5 deliverables right away, know= ing that they probably won’t be ready until after the Phase 1 deliver= ables. And I hope that we’ll make the reference model and protocols e= xtensible so that people can try out draft specs in a prototype implementat= ion or even make up their own solution for some problem and experiment with= it without causing massive problems.

 

To answ= er Kent’s question about how we can most easily track differences bet= ween versions of the charter, I suggest that whoever’s editing the ch= arter (Kent, it seems) provide a plain text file version of each version of= the charter. Send that out as an attachment to your email and we can all u= se our own tools to do a diff.

 

Good charter d= iscussion!

 

Thanks,

 

Steve

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com
<= b>Sent: Monday, August 20, 2012 4:00 PM
To: sacm@ietf.org
Subject: Re: [sacm] Proposed us= e cases to move forward

 

Yes, I agree we need to focus. It appears we have consensus on= working on UC1 and UC3.  The use case document as it exists is very b= road and its intent has expanded a great deal from the initial meeting in P= aris. ;-)

 

It is time to focus on the charter and what i= t is we want this working group to do. We need to put a reasonable box arou= nd the effort so we can be productive.

 

To that end, what= follows is an updated version of the charter that was posted just prior to= the Vancouver meeting.  It has taken into consideration requests made= on the lists.  Let's start discussing it as is. I know there are some= good suggestions that I have not gotten to incorporate yet.

&nb= sp;

One question that I did have is the draft charter talks about remediat= ion.  What are other's thoughts on including that as a 'potential' for= the work to be done under SACM?

 

=

Please take a look at= it and let's talk about what is here.  We will need to develop the li= st of deliverables and the milestones we expect to meet but that will hopef= ully be driven by the base charter discussions.

=

 

As a poi= nt of reference, how does the list want to see differences from one version= of the charter to the next?  Let's keep it simple if possible…<= o:p>

 

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

Security Au= tomation Continuous Monitoring (SACM)

 

Proposed Working G= roup Charter

 

Chairs:

TBD

TBD

&nbs= p;

Security Area Directors:

     Stephen Farrell <= stephen.farrell@cs.tcd.ie&= gt;

     Sean Turner <turners@ieca.com>

 

Security Area Advisor:

     Sean Turner <turners@ieca.com>

 

Mailing Lists:

  &= nbsp;  General Discussion: sacm@ietf.= org

     To Subscribe:        =   http://www.ie= tf.org/mailman/listinfo/sacm

     Archive:  = ;              http://www.ietf.org/mail-archive/web/sacm<= o:p>

 

Description of Working Group

=

 

Securing= information and the systems that store, process, and transmit that informa= tion has become a challenging task for organizations of all sizes, and we f= ind that security practitioners spend most of their time on manual processe= s relegating them to ineffectiveness. Security automation is the key to esc= aping this rut. This working group will develop security automation standar= ds in support of information security processes and practices where practic= al. These standards will support security practitioners to be better utiliz= ed within their organizations by allowing them to meet the more advanced ne= eds of the security community (e.g. information sharing, continuous monitor= ing, remediation and response, result aggregation and analysis). The initia= l focus of this work is to address enterprise and SOHO use cases. The worki= ng group will achieve this by consuming and continuing (with cooperation) t= he security automation work already performed by various organizations arou= nd the world.

 

The initial work has been fruitful, and th= e data formats previously published are ready for expansion on the internat= ional stage. Of particular interest to this working group are the security = automation specifications supporting asset, change, configuration, and vuln= erability management. Of additional interest to this working group are the = emerging security automation interfaces and data formats relating to event = management and continuous monitoring.

 

By undertaking thi= s work, we recognize that there are multiple categories of problems in the = security automation domain: defining expressions for particular domain conc= epts (i.e. data formats), establishing a standards-based foundation support= ing the curation and exchange of security automation content collections in= content repositories and enabling interoperability through the development= and use of interfaces and communications protocols. Content based on rich = data standards and protocols will provide the authoritative instructions ne= eded by data-driven tools to enable the automated collection and exchange o= f configuration and vulnerability data pertaining to enterprise assets. Inf= ormation produced by these tools will provide accurate and timely situation= al awareness in support of organizational decision making. =

 

This working group will provide solutions to these categories of p= roblems and the main areas of focus for this working group are described as= follows:

 

1. Define, either by normative reference, ado= ption, or creation, a set of standards that can be used for the purpose of = assessing, aggregating and comparing device states against expected values,= and reporting on those results in a predefined or ad hoc manner. 

 

2. Define, either by normative reference, adoption, or cre= ation, a set of standards that can be used to continuously monitor and repo= rt on the state of systems, composed of many different types of devices and= networks, operated by varying personnel, to ensure security process effect= iveness in a pre-defined or ad-hoc manner. 

 

3. Crea= te relationships between existing operations management standards to enable= a comprehensive view of security automation, leveraging existing work and = implementations.

 

This working group will produce the fol= lowing:

 

<= span style=3D'color:black'>* An Informational document providing an overvie= w of security automation and continuous monitoring to include a reference m= odel

* A Standards Track document specifying benchmark configuration = representation (XCCDF)

* An Informational document stating guidelines= / requirements for specifying checking languages

* Standards Track d= ocuments specifying device state checking languages (OVAL, ECL, ACEML, R= 30;)

* A Standards Track document specifying an interrogative checkin= g language (OCIL)

* A Standards Track document specifying platform na= ming, matching and applicability (CPE)

* Standards Track documents sp= ecifying asset identification and reporting information (Asset ID, ARF)

* Standards Track documents specifying interfaces and communication prot= ocols used for security automation and continuous monitoring 

* = A Standards Track document describing the messages and network protocols fo= r distributing Security Automation Content  (content repository)<= /o:p>

* Standards Track document describing integrating security automation and = Network Endpoint Assessment capabilities (if-m for SCAP?)=

* A Standar= ds Track document describing protocols and data formats for securely sharin= g dynamic network state information among security systems (if-map)

<= o:p> 

Goals and Milestones

 

=

TBD=

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

 

=

 

Th= anks.

 

Kent Landfield

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

=

 

= From: Adam Montville <amontville@tripwire.com>
Date: Friday, August 17,= 2012 12:33 PM
To: David Waltermire <david.waltermire@nist.gov>, Stephen Hanna <shanna@juniper.net>, Luis Nunez = <lnunez@c3isecurity.com>= ;, Omar Santos <osantos@cisco.com>
Cc: "sacm@ietf.org" <sacm@ietf.org>
S= ubject: Re: [sacm] Proposed use cases to move forward=

 =

I like= taking the scope down as well - and I think we all believe we've

agr= eed to UC1 and UC3.  I don't have an issue having the other use c= ases

(2, 4, and 5) described in the use case document, but not fleshe= d out in

the functional capabilities, components, and data/protocol= sections.  The

charter can be derived from the use cases w= e take on, and a separate

informational document can help place those= use cases in the right context

with respect to the "grand schem= e of things."

 

No matter how we slice it, right now = we need to focus on the use cases and

charter, and to focus on the us= e cases we would ideally need to work on

setting the context. &n= bsp;I've tried to do that (to a limited extent) with the<= /p>

informationa= l document I sent to the list.

 

Additionally, I think the= se efforts need to be done in parallel

irrespective of any idealistic= dependencies.  For example, we should be

able to work on a= charter, a use case doc, and an informational doc all at=

the same ti= me, but join the threads for a final alignment pass before

submitting= them.

 

Adam

 

On 8/17/12 9:30 AM, "= ;Waltermire, David A." <david.waltermire@nist.gov>

wrote:

 

Steve,<= /p>

 <= /o:p>

These are all valid concerns that I completely agree with.  What= I am

struggling with is insuring that the work we are embarking on r= emains

relevant in the broader context.  My fear is that if= we narrow our

thinking too much, we may inadvertently make decisions= that drift from

addressing the broader set of use cases.  = I like the idea of working on

an individual draft to address the larg= er context.  What I am not sure

<= p class=3DMsoNormal>about is how introduce a fe= edback loop that would result in minimizing

this kind of risk. &= nbsp;I guess this type of issue is something that we will=

need to col= lectively monitor and address as needed.

 

=

Sincerely,=

Dave

 

 

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

F= rom: Stephen Hanna [mailto:shanna@jun= iper.net]

Sent: Wednesday, August 15, 2012 3:55 PM

To: Walt= ermire, David A.; Adam Montville; Luis Nunez; Omar Santos=

Subject: RE: [sacm] Propo= sed use cases to move forward

 

=

I love broad scope. Don't = get me wrong! But I'm concerned about having a

<= div>

use cases document and= an architecture document for this working group

that goes way beyond= the charter and initial scope for the group.

 

I'm concer= ned that this will lead to lots of discussions on the sacm list<= /span>

and l= ots of effort being spent on topics that are out of scope, diverting

= us from the tasks at hand and slowing our progress.

 =

I'm = concerned that the working group chairs won't be able to cut off=

disc= ussion of topics by saying they're out of scope for the working group.=

 

I'm concerned that we'll get sidetracked or even derailed = by

controversies that aren't relevant to the scope of the group.=

 

I'm concerned that by including all of security automation= within our use

cases and architecture, we may actually prevent the f= ormation of other

working groups that could work on those other use c= ases.

 

We have plenty of work to keep us busy for years w= ith UC1 and UC3.

There's agreement that the technology needed is matu= re enough for IETF

standardization. I suggest that we scope this work= ing group to address

<= span style=3D'color:black'>only those use cases and that our use cases and = architecture be limited

to them.

 

I'm sorely tempte= d to create an ambitious architecture for security

automation that en= compasses all of the use cases that we have described

=

so far and mayb= e more. I understand that people have a hard time

understanding how t= he NEA and MILE and SACM standards fit together and I

=

would love to a= ddress that in an IETF RFC. But I have seen several grand=

architectur= e efforts die or come to nothing in IETF. IETF is filled with

smart e= ngineers with clever ideas. We're great at solving problems but if

we= can't agree on the problem to solve or if we choose the wrong problem,

we can easily spin an intricate and pointless web.

=

 

I = think we'll do better if we scope our effort properly.

 

M= aybe a few people can create an individual submission describing a grand

architecture and roadmap for security automation and ask people in SACM=

to review and provide feedback on that document. That would be a goo= d way

to get a grand architecture while still ensuring that the SACM = effort

keeps its focus. In IETF as in so many things, you must keep y= our focus

or you'll never succeed.

<= p class=3DMsoNormal> 

Thanks,

=  

Steve

 

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

<= div>

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

Of Walt= ermire, David A.

Sent: Wednesday, August 15, 2012 1:13 PM<= /span>

To: S= tephen Hanna; Adam Montville; Luis Nunez; Omar Santos

=

Subject: Re: [sacm] Proposed = use cases to move forward

+1 on scoping the charter to UC1 and UC3.

I think we are better served with a use cases document, and eventually=

an architecture documemnt, that is broader scoped.  Both o= f these

documents will help inform the work we will do under the char= ter as it

relates to the larger context.

=

To this end I would s= uggest we focus on expanding the use case

<= p class=3DMsoNormal>document primarily in the a= reas of UC1 and UC3 for now.  We can expand

=

the other use c= ases later.

Sincerely,

Dave

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

Of

> Stephen Hanna<= /p>

> Sent: W= ednesday, August 15, 2012 11:24 AM

> To: Adam Montville; Luis Nune= z; Omar Santos

> Subject: Re: [sacm] Proposed use cases to move forward

> 

> I agree. Let's work on UC1 and UC3. The other use = cases are valuable

> but just doing UC1 and UC3 is plenty of work = for this group for the

> next year or two (maybe five!).

>= ; 

> I saw several emails in favor of this a few weeks ago. I= thought

> that it was settled. I'd like to see a revised charte= r and use case

> document, scoped down to focus on just UC1 and UC= 3.

> 

> What do others think? Do we have rough conse= nsus on this?

> If so, let's get moving.

> 

&g= t; Thanks,

> 

> Steve

> 

> &g= t; -----Original Message-----

> > From: Adam Montville [mailto:amontville@tripwire.com]

> > Sent: Wednesday, August 15, 2012 10:30 AM

> > To: = Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos

> > Cc: = sacm@ietf.org

> > Subject:= Re: [sacm] Proposed use cases to move forward

<= div>

> >

> &= gt; On 8/6/12 7:27 AM, "Adam Montville" <amontville@tripwire.com>

=

wrote:

&g= t; >

> > >

> > >

> > >UC1 a= nd UC3 both require assessment of endpoint state. If not for

> the=

> > NEA

<= span style=3D'color:black'>> > >ties in UC1, it seems a subset of = UC3.  So, we should be able to

> > >start with the= main concern of UC3: Security Configuration

> Management.

&= gt; > >

> > >

> >

> >

&g= t; > I haven't seen much activity on this thread (there was another=

> thread,

> > "Using the Frame of Reference," di= scussing some approaches we can

use

<= p class=3DMsoNormal>> > to keep us focuse= d and meaningful).

> >

> > Are there any objections= to tackling UC3 followed by UC1?  Does

> anyone

&= gt; > disagree with my assertion that UC3 is a subset of UC1 and that a<= o:p>

> > reasonable starting point is Security Configuration Managem= ent?

> >

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

> __________________________= _____________________

= > sacm mailing list

_______________________________________________

sacm mailing l= ist

 

=

 

 

 

 

_______________________________= ________________

sacm mailing list

 

= --_000_AC6674AB7BC78549BB231821ABF7A9AEB916F11040EMBX01WFjnprn_-- From shanna@juniper.net Thu Aug 23 13:37:55 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C1221F84C9 for ; Thu, 23 Aug 2012 13:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 rTCrYOGUZZ8i for ; Thu, 23 Aug 2012 13:37:54 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id D536D21F84A5 for ; Thu, 23 Aug 2012 13:37:46 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUDaUmUNCAALvCalHo1zr0MgdzhO/K8j/@postini.com; Thu, 23 Aug 2012 13:37:53 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 23 Aug 2012 13:37:11 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 23 Aug 2012 16:37:10 -0400 From: Stephen Hanna To: "Waltermire, David A." , Adam Montville , Luis Nunez , Omar Santos Date: Thu, 23 Aug 2012 16:37:08 -0400 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwgAGFQsxABNtxpMA== 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 20:37:55 -0000 Dave, Sorry to be late in responding to your email. I agree that we must avoid having our work stray from its place in the larger picture of security automation. In order to do that effectively, it would be very useful (one might say essential!) to have a document that provides that larger picture. If you want to work on an individual submission to do so, I'd be glad to work on it with you. Probably several other people would also. And we can send it to MILE and SACM and other lists for review. In IETF, the feedback loop across WGs is usually provided by having the same people participating in multiple WGs. The IESG, IAB, and directorates can also provide some coordination but mostly we count on the individual participants to do it.=20 Thanks, Steve > -----Original Message----- > From: Waltermire, David A. [mailto:david.waltermire@nist.gov] > Sent: Friday, August 17, 2012 12:30 PM > To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos > Cc: sacm@ietf.org > Subject: RE: [sacm] Proposed use cases to move forward >=20 > Steve, >=20 > These are all valid concerns that I completely agree with. What I am > struggling with is insuring that the work we are embarking on remains > relevant in the broader context. My fear is that if we narrow our > thinking too much, we may inadvertently make decisions that drift from > addressing the broader set of use cases. I like the idea of working on > an individual draft to address the larger context. What I am not sure > about is how introduce a feedback loop that would result in minimizing > this kind of risk. I guess this type of issue is something that we > will need to collectively monitor and address as needed. >=20 > Sincerely, > Dave >=20 >=20 > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net] > Sent: Wednesday, August 15, 2012 3:55 PM > To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos > Cc: sacm@ietf.org > Subject: RE: [sacm] Proposed use cases to move forward >=20 > I love broad scope. Don't get me wrong! But I'm concerned about having > a use cases document and an architecture document for this working > group that goes way beyond the charter and initial scope for the group. >=20 > I'm concerned that this will lead to lots of discussions on the sacm > list and lots of effort being spent on topics that are out of scope, > diverting us from the tasks at hand and slowing our progress. >=20 > I'm concerned that the working group chairs won't be able to cut off > discussion of topics by saying they're out of scope for the working > group. >=20 > I'm concerned that we'll get sidetracked or even derailed by > controversies that aren't relevant to the scope of the group. >=20 > I'm concerned that by including all of security automation within our > use cases and architecture, we may actually prevent the formation of > other working groups that could work on those other use cases. >=20 > We have plenty of work to keep us busy for years with UC1 and UC3. > There's agreement that the technology needed is mature enough for IETF > standardization. I suggest that we scope this working group to address > only those use cases and that our use cases and architecture be limited > to them. >=20 > I'm sorely tempted to create an ambitious architecture for security > automation that encompasses all of the use cases that we have described > so far and maybe more. I understand that people have a hard time > understanding how the NEA and MILE and SACM standards fit together and > I would love to address that in an IETF RFC. But I have seen several > grand architecture efforts die or come to nothing in IETF. IETF is > filled with smart engineers with clever ideas. We're great at solving > problems but if we can't agree on the problem to solve or if we choose > the wrong problem, we can easily spin an intricate and pointless web. >=20 > I think we'll do better if we scope our effort properly. >=20 > Maybe a few people can create an individual submission describing a > grand architecture and roadmap for security automation and ask people > in SACM to review and provide feedback on that document. That would be > a good way to get a grand architecture while still ensuring that the > SACM effort keeps its focus. In IETF as in so many things, you must > keep your focus or you'll never succeed. >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Waltermire, David A. > > Sent: Wednesday, August 15, 2012 1:13 PM > > To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Proposed use cases to move forward > > > > +1 on scoping the charter to UC1 and UC3. > > > > I think we are better served with a use cases document, and > eventually > > an architecture documemnt, that is broader scoped. Both of these > > documents will help inform the work we will do under the charter as > it > > relates to the larger context. > > > > To this end I would suggest we focus on expanding the use case > > document primarily in the areas of UC1 and UC3 for now. We can > expand > > the other use cases later. > > > > Sincerely, > > Dave > > > > > -----Original Message----- > > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf > > Of > > > Stephen Hanna > > > Sent: Wednesday, August 15, 2012 11:24 AM > > > To: Adam Montville; Luis Nunez; Omar Santos > > > Cc: sacm@ietf.org > > > Subject: Re: [sacm] Proposed use cases to move forward > > > > > > I agree. Let's work on UC1 and UC3. The other use cases are > valuable > > > but just doing UC1 and UC3 is plenty of work for this group for the > > > next year or two (maybe five!). > > > > > > I saw several emails in favor of this a few weeks ago. I thought > > > that it was settled. I'd like to see a revised charter and use case > > > document, scoped down to focus on just UC1 and UC3. > > > > > > What do others think? Do we have rough consensus on this? > > > If so, let's get moving. > > > > > > Thanks, > > > > > > Steve > > > > > > > -----Original Message----- > > > > From: Adam Montville [mailto:amontville@tripwire.com] > > > > Sent: Wednesday, August 15, 2012 10:30 AM > > > > To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos > > > > Cc: sacm@ietf.org > > > > Subject: Re: [sacm] Proposed use cases to move forward > > > > > > > > On 8/6/12 7:27 AM, "Adam Montville" > > wrote: > > > > > > > > > > > > > > > > > > >UC1 and UC3 both require assessment of endpoint state. If not > for > > > the > > > > NEA > > > > >ties in UC1, it seems a subset of UC3. So, we should be able to > > > > >start with the main concern of UC3: Security Configuration > > > Management. > > > > > > > > > > > > > > > > > > > > > > I haven't seen much activity on this thread (there was another > > > thread, > > > > "Using the Frame of Reference," discussing some approaches we can > > use > > > > to keep us focused and meaningful). > > > > > > > > Are there any objections to tackling UC3 followed by UC1? Does > > > anyone > > > > disagree with my assertion that UC3 is a subset of UC1 and that a > > > > reasonable starting point is Security Configuration Management? > > > > > > > > > > _______________________________________________ > > > sacm mailing 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 kathleen.moriarty@emc.com Thu Aug 23 13:47: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 26E2C21F8494 for ; Thu, 23 Aug 2012 13:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 2k-gNgRN6kgH for ; Thu, 23 Aug 2012 13:47:39 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id D3AD621F8643 for ; Thu, 23 Aug 2012 13:47:38 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q7NKlVb0029245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Aug 2012 16:47:34 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 23 Aug 2012 16:47:24 -0400 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 q7NKlKd1022887; Thu, 23 Aug 2012 16:47:23 -0400 Received: from mx15a.corp.emc.com ([169.254.1.66]) by mxhub08.corp.emc.com ([128.222.70.205]) with mapi; Thu, 23 Aug 2012 16:45:25 -0400 From: "Moriarty, Kathleen" To: Stephen Hanna , "Waltermire, David A." , Adam Montville , Luis Nunez , Omar Santos Date: Thu, 23 Aug 2012 16:45:24 -0400 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwgAGFQsxABNtxpMAAAfhlw 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 20:47:40 -0000 Hello, I am a little behind in my email, so hopefully my response has all of the r= elevant context. I do agree with Steve that if we can focus the effort to = the scope of a working group with the larger scope defined separately (indi= vidual draft is a great idea), then we should get closer to WG formation an= d driving progress in the WG. Best regards, Kathleen -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ste= phen Hanna Sent: Thursday, August 23, 2012 4:37 PM To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos Cc: sacm@ietf.org Subject: Re: [sacm] Proposed use cases to move forward Dave, Sorry to be late in responding to your email. I agree that we must avoid having our work stray from its place in the larger picture of security automation. In order to do that effectively, it would be very useful (one might say essential!) to have a document that provides that larger picture. If you want to work on an individual submission to do so, I'd be glad to work on it with you. Probably several other people would also. And we can send it to MILE and SACM and other lists for review. In IETF, the feedback loop across WGs is usually provided by having the same people participating in multiple WGs. The IESG, IAB, and directorates can also provide some coordination but mostly we count on the individual participants to do it.=20 Thanks, Steve > -----Original Message----- > From: Waltermire, David A. [mailto:david.waltermire@nist.gov] > Sent: Friday, August 17, 2012 12:30 PM > To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos > Cc: sacm@ietf.org > Subject: RE: [sacm] Proposed use cases to move forward >=20 > Steve, >=20 > These are all valid concerns that I completely agree with. What I am > struggling with is insuring that the work we are embarking on remains > relevant in the broader context. My fear is that if we narrow our > thinking too much, we may inadvertently make decisions that drift from > addressing the broader set of use cases. I like the idea of working on > an individual draft to address the larger context. What I am not sure > about is how introduce a feedback loop that would result in minimizing > this kind of risk. I guess this type of issue is something that we > will need to collectively monitor and address as needed. >=20 > Sincerely, > Dave >=20 >=20 > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net] > Sent: Wednesday, August 15, 2012 3:55 PM > To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos > Cc: sacm@ietf.org > Subject: RE: [sacm] Proposed use cases to move forward >=20 > I love broad scope. Don't get me wrong! But I'm concerned about having > a use cases document and an architecture document for this working > group that goes way beyond the charter and initial scope for the group. >=20 > I'm concerned that this will lead to lots of discussions on the sacm > list and lots of effort being spent on topics that are out of scope, > diverting us from the tasks at hand and slowing our progress. >=20 > I'm concerned that the working group chairs won't be able to cut off > discussion of topics by saying they're out of scope for the working > group. >=20 > I'm concerned that we'll get sidetracked or even derailed by > controversies that aren't relevant to the scope of the group. >=20 > I'm concerned that by including all of security automation within our > use cases and architecture, we may actually prevent the formation of > other working groups that could work on those other use cases. >=20 > We have plenty of work to keep us busy for years with UC1 and UC3. > There's agreement that the technology needed is mature enough for IETF > standardization. I suggest that we scope this working group to address > only those use cases and that our use cases and architecture be limited > to them. >=20 > I'm sorely tempted to create an ambitious architecture for security > automation that encompasses all of the use cases that we have described > so far and maybe more. I understand that people have a hard time > understanding how the NEA and MILE and SACM standards fit together and > I would love to address that in an IETF RFC. But I have seen several > grand architecture efforts die or come to nothing in IETF. IETF is > filled with smart engineers with clever ideas. We're great at solving > problems but if we can't agree on the problem to solve or if we choose > the wrong problem, we can easily spin an intricate and pointless web. >=20 > I think we'll do better if we scope our effort properly. >=20 > Maybe a few people can create an individual submission describing a > grand architecture and roadmap for security automation and ask people > in SACM to review and provide feedback on that document. That would be > a good way to get a grand architecture while still ensuring that the > SACM effort keeps its focus. In IETF as in so many things, you must > keep your focus or you'll never succeed. >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Waltermire, David A. > > Sent: Wednesday, August 15, 2012 1:13 PM > > To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Proposed use cases to move forward > > > > +1 on scoping the charter to UC1 and UC3. > > > > I think we are better served with a use cases document, and > eventually > > an architecture documemnt, that is broader scoped. Both of these > > documents will help inform the work we will do under the charter as > it > > relates to the larger context. > > > > To this end I would suggest we focus on expanding the use case > > document primarily in the areas of UC1 and UC3 for now. We can > expand > > the other use cases later. > > > > Sincerely, > > Dave > > > > > -----Original Message----- > > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf > > Of > > > Stephen Hanna > > > Sent: Wednesday, August 15, 2012 11:24 AM > > > To: Adam Montville; Luis Nunez; Omar Santos > > > Cc: sacm@ietf.org > > > Subject: Re: [sacm] Proposed use cases to move forward > > > > > > I agree. Let's work on UC1 and UC3. The other use cases are > valuable > > > but just doing UC1 and UC3 is plenty of work for this group for the > > > next year or two (maybe five!). > > > > > > I saw several emails in favor of this a few weeks ago. I thought > > > that it was settled. I'd like to see a revised charter and use case > > > document, scoped down to focus on just UC1 and UC3. > > > > > > What do others think? Do we have rough consensus on this? > > > If so, let's get moving. > > > > > > Thanks, > > > > > > Steve > > > > > > > -----Original Message----- > > > > From: Adam Montville [mailto:amontville@tripwire.com] > > > > Sent: Wednesday, August 15, 2012 10:30 AM > > > > To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos > > > > Cc: sacm@ietf.org > > > > Subject: Re: [sacm] Proposed use cases to move forward > > > > > > > > On 8/6/12 7:27 AM, "Adam Montville" > > wrote: > > > > > > > > > > > > > > > > > > >UC1 and UC3 both require assessment of endpoint state. If not > for > > > the > > > > NEA > > > > >ties in UC1, it seems a subset of UC3. So, we should be able to > > > > >start with the main concern of UC3: Security Configuration > > > Management. > > > > > > > > > > > > > > > > > > > > > > I haven't seen much activity on this thread (there was another > > > thread, > > > > "Using the Frame of Reference," discussing some approaches we can > > use > > > > to keep us focused and meaningful). > > > > > > > > Are there any objections to tackling UC3 followed by UC1? Does > > > anyone > > > > disagree with my assertion that UC3 is a subset of UC1 and that a > > > > reasonable starting point is Security Configuration Management? > > > > > > > > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From amontville@tripwire.com Fri Aug 24 06:47:55 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B95221F84B2 for ; Fri, 24 Aug 2012 06:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.454 X-Spam-Level: X-Spam-Status: No, score=-5.454 tagged_above=-999 required=5 tests=[AWL=1.145, 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 GvqbAShoSmhS for ; Fri, 24 Aug 2012 06:47:54 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 59A4621F84A2 for ; Fri, 24 Aug 2012 06:47:54 -0700 (PDT) Received: from mail93-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 24 Aug 2012 13:47:53 +0000 Received: from mail93-tx2 (localhost [127.0.0.1]) by mail93-tx2-R.bigfish.com (Postfix) with ESMTP id 29F801E027E for ; Fri, 24 Aug 2012 13:47:53 +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(zzbb2dI98dI9371I1503M542M1432I4015Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail93-tx2 (localhost.localdomain [127.0.0.1]) by mail93-tx2 (MessageSwitch) id 1345816071762310_17451; Fri, 24 Aug 2012 13:47:51 +0000 (UTC) Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.249]) by mail93-tx2.bigfish.com (Postfix) with ESMTP id B6DC9140066 for ; Fri, 24 Aug 2012 13:47:51 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 24 Aug 2012 13:47:50 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 1A68223211F3 for ; Fri, 24 Aug 2012 06:46:27 -0700 (PDT) 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 5299323211EF; Fri, 24 Aug 2012 06:46:26 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 24 Aug 2012 06:50:27 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Fri, 24 Aug 2012 06:47:48 -0700 From: Adam Montville To: Stephen Hanna , "Waltermire, David A." , Luis Nunez , Omar Santos Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwgAGFQsxABNtxpMAAkQJuA Date: Fri, 24 Aug 2012 13:47:47 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: f39e28b6-2002-4d48-b99a-f344b4825c02 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] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 13:47:55 -0000 On 8/23/12 1:37 PM, "Stephen Hanna" wrote: >Dave, > >Sorry to be late in responding to your email. I agree that >we must avoid having our work stray from its place in the >larger picture of security automation. In order to do that >effectively, it would be very useful (one might say essential!) >to have a document that provides that larger picture. If you >want to work on an individual submission to do so, I'd be >glad to work on it with you. Probably several other people >would also. And we can send it to MILE and SACM and other >lists for review. I'm feeling that we're talking about two different levels of document - one is the use case document, which I think needs to be "broad" in the sense that we keep the five use cases represented, but only address UC1 and UC3; the second is a more abstract, context setting informational document. Are we talking about two things or am I missing something? > >In IETF, the feedback loop across WGs is usually provided >by having the same people participating in multiple WGs. >The IESG, IAB, and directorates can also provide some >coordination but mostly we count on the individual >participants to do it. > >Thanks, > >Steve > >> -----Original Message----- >> From: Waltermire, David A. [mailto:david.waltermire@nist.gov] >> Sent: Friday, August 17, 2012 12:30 PM >> To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos >> Cc: sacm@ietf.org >> Subject: RE: [sacm] Proposed use cases to move forward >>=20 >> Steve, >>=20 >> These are all valid concerns that I completely agree with. What I am >> struggling with is insuring that the work we are embarking on remains >> relevant in the broader context. My fear is that if we narrow our >> thinking too much, we may inadvertently make decisions that drift from >> addressing the broader set of use cases. I like the idea of working on >> an individual draft to address the larger context. What I am not sure >> about is how introduce a feedback loop that would result in minimizing >> this kind of risk. I guess this type of issue is something that we >> will need to collectively monitor and address as needed. >>=20 >> Sincerely, >> Dave >>=20 >>=20 >> -----Original Message----- >> From: Stephen Hanna [mailto:shanna@juniper.net] >> Sent: Wednesday, August 15, 2012 3:55 PM >> To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos >> Cc: sacm@ietf.org >> Subject: RE: [sacm] Proposed use cases to move forward >>=20 >> I love broad scope. Don't get me wrong! But I'm concerned about having >> a use cases document and an architecture document for this working >> group that goes way beyond the charter and initial scope for the group. >>=20 >> I'm concerned that this will lead to lots of discussions on the sacm >> list and lots of effort being spent on topics that are out of scope, >> diverting us from the tasks at hand and slowing our progress. >>=20 >> I'm concerned that the working group chairs won't be able to cut off >> discussion of topics by saying they're out of scope for the working >> group. >>=20 >> I'm concerned that we'll get sidetracked or even derailed by >> controversies that aren't relevant to the scope of the group. >>=20 >> I'm concerned that by including all of security automation within our >> use cases and architecture, we may actually prevent the formation of >> other working groups that could work on those other use cases. >>=20 >> We have plenty of work to keep us busy for years with UC1 and UC3. >> There's agreement that the technology needed is mature enough for IETF >> standardization. I suggest that we scope this working group to address >> only those use cases and that our use cases and architecture be limited >> to them. >>=20 >> I'm sorely tempted to create an ambitious architecture for security >> automation that encompasses all of the use cases that we have described >> so far and maybe more. I understand that people have a hard time >> understanding how the NEA and MILE and SACM standards fit together and >> I would love to address that in an IETF RFC. But I have seen several >> grand architecture efforts die or come to nothing in IETF. IETF is >> filled with smart engineers with clever ideas. We're great at solving >> problems but if we can't agree on the problem to solve or if we choose >> the wrong problem, we can easily spin an intricate and pointless web. >>=20 >> I think we'll do better if we scope our effort properly. >>=20 >> Maybe a few people can create an individual submission describing a >> grand architecture and roadmap for security automation and ask people >> in SACM to review and provide feedback on that document. That would be >> a good way to get a grand architecture while still ensuring that the >> SACM effort keeps its focus. In IETF as in so many things, you must >> keep your focus or you'll never succeed. >>=20 >> Thanks, >>=20 >> Steve >>=20 >> > -----Original Message----- >> > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >> > Of Waltermire, David A. >> > Sent: Wednesday, August 15, 2012 1:13 PM >> > To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos >> > Cc: sacm@ietf.org >> > Subject: Re: [sacm] Proposed use cases to move forward >> > >> > +1 on scoping the charter to UC1 and UC3. >> > >> > I think we are better served with a use cases document, and >> eventually >> > an architecture documemnt, that is broader scoped. Both of these >> > documents will help inform the work we will do under the charter as >> it >> > relates to the larger context. >> > >> > To this end I would suggest we focus on expanding the use case >> > document primarily in the areas of UC1 and UC3 for now. We can >> expand >> > the other use cases later. >> > >> > Sincerely, >> > Dave >> > >> > > -----Original Message----- >> > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> Behalf >> > Of >> > > Stephen Hanna >> > > Sent: Wednesday, August 15, 2012 11:24 AM >> > > To: Adam Montville; Luis Nunez; Omar Santos >> > > Cc: sacm@ietf.org >> > > Subject: Re: [sacm] Proposed use cases to move forward >> > > >> > > I agree. Let's work on UC1 and UC3. The other use cases are >> valuable >> > > but just doing UC1 and UC3 is plenty of work for this group for the >> > > next year or two (maybe five!). >> > > >> > > I saw several emails in favor of this a few weeks ago. I thought >> > > that it was settled. I'd like to see a revised charter and use case >> > > document, scoped down to focus on just UC1 and UC3. >> > > >> > > What do others think? Do we have rough consensus on this? >> > > If so, let's get moving. >> > > >> > > Thanks, >> > > >> > > Steve >> > > >> > > > -----Original Message----- >> > > > From: Adam Montville [mailto:amontville@tripwire.com] >> > > > Sent: Wednesday, August 15, 2012 10:30 AM >> > > > To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos >> > > > Cc: sacm@ietf.org >> > > > Subject: Re: [sacm] Proposed use cases to move forward >> > > > >> > > > On 8/6/12 7:27 AM, "Adam Montville" >> > wrote: >> > > > >> > > > > >> > > > > >> > > > >UC1 and UC3 both require assessment of endpoint state. If not >> for >> > > the >> > > > NEA >> > > > >ties in UC1, it seems a subset of UC3. So, we should be able to >> > > > >start with the main concern of UC3: Security Configuration >> > > Management. >> > > > > >> > > > > >> > > > >> > > > >> > > > I haven't seen much activity on this thread (there was another >> > > thread, >> > > > "Using the Frame of Reference," discussing some approaches we can >> > use >> > > > to keep us focused and meaningful). >> > > > >> > > > Are there any objections to tackling UC3 followed by UC1? Does >> > > anyone >> > > > disagree with my assertion that UC3 is a subset of UC1 and that a >> > > > reasonable starting point is Security Configuration Management? >> > > > >> > > >> > > _______________________________________________ >> > > sacm mailing list >> > > sacm@ietf.org >> > > https://www.ietf.org/mailman/listinfo/sacm >> > _______________________________________________ >> > sacm mailing list >> > sacm@ietf.org >> > https://www.ietf.org/mailman/listinfo/sacm > > From shanna@juniper.net Fri Aug 24 07:45: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 3CB5821F8471 for ; Fri, 24 Aug 2012 07:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 3LR6ZmMXXO0t for ; Fri, 24 Aug 2012 07:45:18 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 35BC621F846A for ; Fri, 24 Aug 2012 07:45:14 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUDeTeaPQARDc413LvYM+QyzpARYfQX8a@postini.com; Fri, 24 Aug 2012 07:45:17 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 24 Aug 2012 07:44:57 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 24 Aug 2012 10:44:56 -0400 From: Stephen Hanna To: Adam Montville , "Waltermire, David A." , Luis Nunez , Omar Santos Date: Fri, 24 Aug 2012 10:44:55 -0400 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwgAGFQsxABNtxpMAAkQJuAAACnG9A= 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 14:45:19 -0000 Adam, I think the core issue here is scope. Successful IETF Working Groups must have a charter that clearly articulates a fairly narrow scope with a limited set of deliverables that will provide significant value when completed. Then they must stick to that scope. Without a clear and narrow scope, WGs wander around and never complete. WG chairs can't shut down irrelevant discussions on the email list. People bring in interesting and perhaps worthwhile ideas that distract the group from their goal. Eventually, people get frustrated and leave. The only people who are left are impractical and create a monument to their huge intelligence that nobody implements. You didn't say that you disagree about scope, though. In fact, I think that you have previously said that you agree that we should have a narrow scope. So I'll assume that we agree on that topic. Why would we want to have use cases in the key architecture document for SACM that are not in scope for the WG? That will just encourage the WG to spend time talking about those use cases. In fact, we'd be obligated to spend time talking about them if they're in our key architecture document, the main document guiding our WG's work. We couldn't approve something with use cases that we haven't reached consensus on. Maybe you're arguing that UC2, UC4, and UC5 should also be in scope for this WG. I thought we had already settled that matter but if you want to reopen it, please speak up and explain why. Thanks, Steve > -----Original Message----- > From: Adam Montville [mailto:amontville@tripwire.com] > Sent: Friday, August 24, 2012 9:48 AM > To: Stephen Hanna; Waltermire, David A.; Luis Nunez; Omar Santos > Cc: sacm@ietf.org > Subject: Re: [sacm] Proposed use cases to move forward >=20 > On 8/23/12 1:37 PM, "Stephen Hanna" wrote: >=20 > >Dave, > > > >Sorry to be late in responding to your email. I agree that > >we must avoid having our work stray from its place in the > >larger picture of security automation. In order to do that > >effectively, it would be very useful (one might say essential!) > >to have a document that provides that larger picture. If you > >want to work on an individual submission to do so, I'd be > >glad to work on it with you. Probably several other people > >would also. And we can send it to MILE and SACM and other > >lists for review. >=20 >=20 > I'm feeling that we're talking about two different levels of document - > one is the use case document, which I think needs to be "broad" in the > sense that we keep the five use cases represented, but only address UC1 > and UC3; the second is a more abstract, context setting informational > document. Are we talking about two things or am I missing something? >=20 >=20 > > > >In IETF, the feedback loop across WGs is usually provided > >by having the same people participating in multiple WGs. > >The IESG, IAB, and directorates can also provide some > >coordination but mostly we count on the individual > >participants to do it. > > > >Thanks, > > > >Steve > > > >> -----Original Message----- > >> From: Waltermire, David A. [mailto:david.waltermire@nist.gov] > >> Sent: Friday, August 17, 2012 12:30 PM > >> To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos > >> Cc: sacm@ietf.org > >> Subject: RE: [sacm] Proposed use cases to move forward > >> > >> Steve, > >> > >> These are all valid concerns that I completely agree with. What I > am > >> struggling with is insuring that the work we are embarking on > remains > >> relevant in the broader context. My fear is that if we narrow our > >> thinking too much, we may inadvertently make decisions that drift > from > >> addressing the broader set of use cases. I like the idea of working > on > >> an individual draft to address the larger context. What I am not > sure > >> about is how introduce a feedback loop that would result in > minimizing > >> this kind of risk. I guess this type of issue is something that we > >> will need to collectively monitor and address as needed. > >> > >> Sincerely, > >> Dave > >> > >> > >> -----Original Message----- > >> From: Stephen Hanna [mailto:shanna@juniper.net] > >> Sent: Wednesday, August 15, 2012 3:55 PM > >> To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos > >> Cc: sacm@ietf.org > >> Subject: RE: [sacm] Proposed use cases to move forward > >> > >> I love broad scope. Don't get me wrong! But I'm concerned about > having > >> a use cases document and an architecture document for this working > >> group that goes way beyond the charter and initial scope for the > group. > >> > >> I'm concerned that this will lead to lots of discussions on the sacm > >> list and lots of effort being spent on topics that are out of scope, > >> diverting us from the tasks at hand and slowing our progress. > >> > >> I'm concerned that the working group chairs won't be able to cut off > >> discussion of topics by saying they're out of scope for the working > >> group. > >> > >> I'm concerned that we'll get sidetracked or even derailed by > >> controversies that aren't relevant to the scope of the group. > >> > >> I'm concerned that by including all of security automation within > our > >> use cases and architecture, we may actually prevent the formation of > >> other working groups that could work on those other use cases. > >> > >> We have plenty of work to keep us busy for years with UC1 and UC3. > >> There's agreement that the technology needed is mature enough for > IETF > >> standardization. I suggest that we scope this working group to > address > >> only those use cases and that our use cases and architecture be > limited > >> to them. > >> > >> I'm sorely tempted to create an ambitious architecture for security > >> automation that encompasses all of the use cases that we have > described > >> so far and maybe more. I understand that people have a hard time > >> understanding how the NEA and MILE and SACM standards fit together > and > >> I would love to address that in an IETF RFC. But I have seen several > >> grand architecture efforts die or come to nothing in IETF. IETF is > >> filled with smart engineers with clever ideas. We're great at > solving > >> problems but if we can't agree on the problem to solve or if we > choose > >> the wrong problem, we can easily spin an intricate and pointless > web. > >> > >> I think we'll do better if we scope our effort properly. > >> > >> Maybe a few people can create an individual submission describing a > >> grand architecture and roadmap for security automation and ask > people > >> in SACM to review and provide feedback on that document. That would > be > >> a good way to get a grand architecture while still ensuring that the > >> SACM effort keeps its focus. In IETF as in so many things, you must > >> keep your focus or you'll never succeed. > >> > >> Thanks, > >> > >> Steve > >> > >> > -----Original Message----- > >> > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf > >> > Of Waltermire, David A. > >> > Sent: Wednesday, August 15, 2012 1:13 PM > >> > To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos > >> > Cc: sacm@ietf.org > >> > Subject: Re: [sacm] Proposed use cases to move forward > >> > > >> > +1 on scoping the charter to UC1 and UC3. > >> > > >> > I think we are better served with a use cases document, and > >> eventually > >> > an architecture documemnt, that is broader scoped. Both of these > >> > documents will help inform the work we will do under the charter > as > >> it > >> > relates to the larger context. > >> > > >> > To this end I would suggest we focus on expanding the use case > >> > document primarily in the areas of UC1 and UC3 for now. We can > >> expand > >> > the other use cases later. > >> > > >> > Sincerely, > >> > Dave > >> > > >> > > -----Original Message----- > >> > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > >> Behalf > >> > Of > >> > > Stephen Hanna > >> > > Sent: Wednesday, August 15, 2012 11:24 AM > >> > > To: Adam Montville; Luis Nunez; Omar Santos > >> > > Cc: sacm@ietf.org > >> > > Subject: Re: [sacm] Proposed use cases to move forward > >> > > > >> > > I agree. Let's work on UC1 and UC3. The other use cases are > >> valuable > >> > > but just doing UC1 and UC3 is plenty of work for this group for > the > >> > > next year or two (maybe five!). > >> > > > >> > > I saw several emails in favor of this a few weeks ago. I thought > >> > > that it was settled. I'd like to see a revised charter and use > case > >> > > document, scoped down to focus on just UC1 and UC3. > >> > > > >> > > What do others think? Do we have rough consensus on this? > >> > > If so, let's get moving. > >> > > > >> > > Thanks, > >> > > > >> > > Steve > >> > > > >> > > > -----Original Message----- > >> > > > From: Adam Montville [mailto:amontville@tripwire.com] > >> > > > Sent: Wednesday, August 15, 2012 10:30 AM > >> > > > To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos > >> > > > Cc: sacm@ietf.org > >> > > > Subject: Re: [sacm] Proposed use cases to move forward > >> > > > > >> > > > On 8/6/12 7:27 AM, "Adam Montville" > >> > wrote: > >> > > > > >> > > > > > >> > > > > > >> > > > >UC1 and UC3 both require assessment of endpoint state. If not > >> for > >> > > the > >> > > > NEA > >> > > > >ties in UC1, it seems a subset of UC3. So, we should be able > to > >> > > > >start with the main concern of UC3: Security Configuration > >> > > Management. > >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > I haven't seen much activity on this thread (there was another > >> > > thread, > >> > > > "Using the Frame of Reference," discussing some approaches we > can > >> > use > >> > > > to keep us focused and meaningful). > >> > > > > >> > > > Are there any objections to tackling UC3 followed by UC1? > Does > >> > > anyone > >> > > > disagree with my assertion that UC3 is a subset of UC1 and > that a > >> > > > reasonable starting point is Security Configuration > Management? > >> > > > > >> > > > >> > > _______________________________________________ > >> > > sacm mailing list > >> > > sacm@ietf.org > >> > > https://www.ietf.org/mailman/listinfo/sacm > >> > _______________________________________________ > >> > sacm mailing list > >> > sacm@ietf.org > >> > https://www.ietf.org/mailman/listinfo/sacm > > > > >=20 >=20 >=20 From amontville@tripwire.com Fri Aug 24 08:37: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 ED86B21F8722 for ; Fri, 24 Aug 2012 08:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.976 X-Spam-Level: X-Spam-Status: No, score=-3.976 tagged_above=-999 required=5 tests=[AWL=-0.377, 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 4ie+xZaBwjz9 for ; Fri, 24 Aug 2012 08:37:01 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 88DFA21F871E for ; Fri, 24 Aug 2012 08:37:01 -0700 (PDT) Received: from mail37-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 24 Aug 2012 15:37:00 +0000 Received: from mail37-va3 (localhost [127.0.0.1]) by mail37-va3-R.bigfish.com (Postfix) with ESMTP id D78C622021F for ; Fri, 24 Aug 2012 15:37:00 +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(zzbb2dI98dI9371I1503M542M1432I4015Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h944hd25he5bhf0ah107ah) Received: from mail37-va3 (localhost.localdomain [127.0.0.1]) by mail37-va3 (MessageSwitch) id 1345822606994500_6325; Fri, 24 Aug 2012 15:36:46 +0000 (UTC) Received: from VA3EHSMHS033.bigfish.com (unknown [10.7.14.252]) by mail37-va3.bigfish.com (Postfix) with ESMTP id EE0B82A033C for ; Fri, 24 Aug 2012 15:36:46 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by VA3EHSMHS033.bigfish.com (10.7.99.43) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 24 Aug 2012 15:36:41 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id AA0C023211F0 for ; Fri, 24 Aug 2012 08:35:16 -0700 (PDT) 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 ED2A223211EF; Fri, 24 Aug 2012 08:35:15 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 24 Aug 2012 08:39:17 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Fri, 24 Aug 2012 08:36:38 -0700 From: Adam Montville To: Stephen Hanna Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwgAGFQsxABNtxpMAAkQJuAAACnG9AAEdFVgA== Date: Fri, 24 Aug 2012 15:36:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: 5aa0a2f0-7ca0-434f-9b5c-888fac3d5b5a 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: Luis Nunez , "sacm@ietf.org" , "Waltermire, David A." , Omar Santos , Adam Montville Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 15:37:03 -0000 I agree on WG scope. Just distinguishing between doc scope. UC1 and UC3 for= WG scope. Seems that 2, 4, and 5 should be pulled up into a more informat= ional doc. So we can renumber 3 to 2, and describe the others elsewhere. Make sense? Sent from my iPhone On Aug 24, 2012, at 7:44 AM, Stephen Hanna wrote: > Adam, >=20 > I think the core issue here is scope. Successful IETF Working Groups > must have a charter that clearly articulates a fairly narrow scope > with a limited set of deliverables that will provide significant value > when completed. Then they must stick to that scope. >=20 > Without a clear and narrow scope, WGs wander around and never complete. > WG chairs can't shut down irrelevant discussions on the email list. > People bring in interesting and perhaps worthwhile ideas that distract > the group from their goal. Eventually, people get frustrated and leave. > The only people who are left are impractical and create a monument to > their huge intelligence that nobody implements. >=20 > You didn't say that you disagree about scope, though. In fact, I think > that you have previously said that you agree that we should have a > narrow scope. So I'll assume that we agree on that topic. >=20 > Why would we want to have use cases in the key architecture document > for SACM that are not in scope for the WG? That will just encourage > the WG to spend time talking about those use cases. In fact, we'd > be obligated to spend time talking about them if they're in our > key architecture document, the main document guiding our WG's work. > We couldn't approve something with use cases that we haven't reached > consensus on. >=20 > Maybe you're arguing that UC2, UC4, and UC5 should also be in scope > for this WG. I thought we had already settled that matter but if > you want to reopen it, please speak up and explain why. >=20 > Thanks, >=20 > Steve >=20 >> -----Original Message----- >> From: Adam Montville [mailto:amontville@tripwire.com] >> Sent: Friday, August 24, 2012 9:48 AM >> To: Stephen Hanna; Waltermire, David A.; Luis Nunez; Omar Santos >> Cc: sacm@ietf.org >> Subject: Re: [sacm] Proposed use cases to move forward >>=20 >> On 8/23/12 1:37 PM, "Stephen Hanna" wrote: >>=20 >>> Dave, >>>=20 >>> Sorry to be late in responding to your email. I agree that >>> we must avoid having our work stray from its place in the >>> larger picture of security automation. In order to do that >>> effectively, it would be very useful (one might say essential!) >>> to have a document that provides that larger picture. If you >>> want to work on an individual submission to do so, I'd be >>> glad to work on it with you. Probably several other people >>> would also. And we can send it to MILE and SACM and other >>> lists for review. >>=20 >>=20 >> I'm feeling that we're talking about two different levels of document - >> one is the use case document, which I think needs to be "broad" in the >> sense that we keep the five use cases represented, but only address UC1 >> and UC3; the second is a more abstract, context setting informational >> document. Are we talking about two things or am I missing something? >>=20 >>=20 >>>=20 >>> In IETF, the feedback loop across WGs is usually provided >>> by having the same people participating in multiple WGs. >>> The IESG, IAB, and directorates can also provide some >>> coordination but mostly we count on the individual >>> participants to do it. >>>=20 >>> Thanks, >>>=20 >>> Steve >>>=20 >>>> -----Original Message----- >>>> From: Waltermire, David A. [mailto:david.waltermire@nist.gov] >>>> Sent: Friday, August 17, 2012 12:30 PM >>>> To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos >>>> Cc: sacm@ietf.org >>>> Subject: RE: [sacm] Proposed use cases to move forward >>>>=20 >>>> Steve, >>>>=20 >>>> These are all valid concerns that I completely agree with. What I >> am >>>> struggling with is insuring that the work we are embarking on >> remains >>>> relevant in the broader context. My fear is that if we narrow our >>>> thinking too much, we may inadvertently make decisions that drift >> from >>>> addressing the broader set of use cases. I like the idea of working >> on >>>> an individual draft to address the larger context. What I am not >> sure >>>> about is how introduce a feedback loop that would result in >> minimizing >>>> this kind of risk. I guess this type of issue is something that we >>>> will need to collectively monitor and address as needed. >>>>=20 >>>> Sincerely, >>>> Dave >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Stephen Hanna [mailto:shanna@juniper.net] >>>> Sent: Wednesday, August 15, 2012 3:55 PM >>>> To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos >>>> Cc: sacm@ietf.org >>>> Subject: RE: [sacm] Proposed use cases to move forward >>>>=20 >>>> I love broad scope. Don't get me wrong! But I'm concerned about >> having >>>> a use cases document and an architecture document for this working >>>> group that goes way beyond the charter and initial scope for the >> group. >>>>=20 >>>> I'm concerned that this will lead to lots of discussions on the sacm >>>> list and lots of effort being spent on topics that are out of scope, >>>> diverting us from the tasks at hand and slowing our progress. >>>>=20 >>>> I'm concerned that the working group chairs won't be able to cut off >>>> discussion of topics by saying they're out of scope for the working >>>> group. >>>>=20 >>>> I'm concerned that we'll get sidetracked or even derailed by >>>> controversies that aren't relevant to the scope of the group. >>>>=20 >>>> I'm concerned that by including all of security automation within >> our >>>> use cases and architecture, we may actually prevent the formation of >>>> other working groups that could work on those other use cases. >>>>=20 >>>> We have plenty of work to keep us busy for years with UC1 and UC3. >>>> There's agreement that the technology needed is mature enough for >> IETF >>>> standardization. I suggest that we scope this working group to >> address >>>> only those use cases and that our use cases and architecture be >> limited >>>> to them. >>>>=20 >>>> I'm sorely tempted to create an ambitious architecture for security >>>> automation that encompasses all of the use cases that we have >> described >>>> so far and maybe more. I understand that people have a hard time >>>> understanding how the NEA and MILE and SACM standards fit together >> and >>>> I would love to address that in an IETF RFC. But I have seen several >>>> grand architecture efforts die or come to nothing in IETF. IETF is >>>> filled with smart engineers with clever ideas. We're great at >> solving >>>> problems but if we can't agree on the problem to solve or if we >> choose >>>> the wrong problem, we can easily spin an intricate and pointless >> web. >>>>=20 >>>> I think we'll do better if we scope our effort properly. >>>>=20 >>>> Maybe a few people can create an individual submission describing a >>>> grand architecture and roadmap for security automation and ask >> people >>>> in SACM to review and provide feedback on that document. That would >> be >>>> a good way to get a grand architecture while still ensuring that the >>>> SACM effort keeps its focus. In IETF as in so many things, you must >>>> keep your focus or you'll never succeed. >>>>=20 >>>> Thanks, >>>>=20 >>>> Steve >>>>=20 >>>>> -----Original Message----- >>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> Behalf >>>>> Of Waltermire, David A. >>>>> Sent: Wednesday, August 15, 2012 1:13 PM >>>>> To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos >>>>> Cc: sacm@ietf.org >>>>> Subject: Re: [sacm] Proposed use cases to move forward >>>>>=20 >>>>> +1 on scoping the charter to UC1 and UC3. >>>>>=20 >>>>> I think we are better served with a use cases document, and >>>> eventually >>>>> an architecture documemnt, that is broader scoped. Both of these >>>>> documents will help inform the work we will do under the charter >> as >>>> it >>>>> relates to the larger context. >>>>>=20 >>>>> To this end I would suggest we focus on expanding the use case >>>>> document primarily in the areas of UC1 and UC3 for now. We can >>>> expand >>>>> the other use cases later. >>>>>=20 >>>>> Sincerely, >>>>> Dave >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >>>> Behalf >>>>> Of >>>>>> Stephen Hanna >>>>>> Sent: Wednesday, August 15, 2012 11:24 AM >>>>>> To: Adam Montville; Luis Nunez; Omar Santos >>>>>> Cc: sacm@ietf.org >>>>>> Subject: Re: [sacm] Proposed use cases to move forward >>>>>>=20 >>>>>> I agree. Let's work on UC1 and UC3. The other use cases are >>>> valuable >>>>>> but just doing UC1 and UC3 is plenty of work for this group for >> the >>>>>> next year or two (maybe five!). >>>>>>=20 >>>>>> I saw several emails in favor of this a few weeks ago. I thought >>>>>> that it was settled. I'd like to see a revised charter and use >> case >>>>>> document, scoped down to focus on just UC1 and UC3. >>>>>>=20 >>>>>> What do others think? Do we have rough consensus on this? >>>>>> If so, let's get moving. >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Steve >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Adam Montville [mailto:amontville@tripwire.com] >>>>>>> Sent: Wednesday, August 15, 2012 10:30 AM >>>>>>> To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos >>>>>>> Cc: sacm@ietf.org >>>>>>> Subject: Re: [sacm] Proposed use cases to move forward >>>>>>>=20 >>>>>>> On 8/6/12 7:27 AM, "Adam Montville" >>>>> wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> UC1 and UC3 both require assessment of endpoint state. If not >>>> for >>>>>> the >>>>>>> NEA >>>>>>>> ties in UC1, it seems a subset of UC3. So, we should be able >> to >>>>>>>> start with the main concern of UC3: Security Configuration >>>>>> Management. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I haven't seen much activity on this thread (there was another >>>>>> thread, >>>>>>> "Using the Frame of Reference," discussing some approaches we >> can >>>>> use >>>>>>> to keep us focused and meaningful). >>>>>>>=20 >>>>>>> Are there any objections to tackling UC3 followed by UC1? >> Does >>>>>> anyone >>>>>>> disagree with my assertion that UC3 is a subset of UC1 and >> that a >>>>>>> reasonable starting point is Security Configuration >> Management? >>>>>>>=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 >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From shanna@juniper.net Fri Aug 24 09:21:36 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A7F21F8598 for ; Fri, 24 Aug 2012 09:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 TtjPeEinULWE for ; Fri, 24 Aug 2012 09:21:35 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id BB19B21F860D for ; Fri, 24 Aug 2012 09:21:32 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUDeqDL9ZChAMVdoe1xEovGP3D8nFgQyA@postini.com; Fri, 24 Aug 2012 09:21:35 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 24 Aug 2012 09:20:39 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 24 Aug 2012 12:20:35 -0400 From: Stephen Hanna To: Adam Montville Date: Fri, 24 Aug 2012 12:20:33 -0400 Thread-Topic: [sacm] Proposed use cases to move forward Thread-Index: Ac1xJoVL8Ifx3EnyRsGzJUOVORn/rQAhiw2AABYdQIAAdpirAAHEurOAAADHmlAABL+MAAABMKwgAGFQsxABNtxpMAAkQJuAAACnG9AAEdFVgAANQb6g 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Luis Nunez , "Waltermire, David A." , Omar Santos , "sacm@ietf.org" Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 16:21:37 -0000 I agree completely as long as the document that contains 2, 4, and 5 is not a WG document for this WG. Maybe we can put use cases into the broader architecture document that Dave and I are going to write (the independent submission). We could even start a non-WG email list to talk about that document and/or others that span multiple WGs. We should find ways to continue the broader discussion but not in this WG. Does that make sense? Thanks, Steve > -----Original Message----- > From: Adam Montville [mailto:amontville@tripwire.com] > Sent: Friday, August 24, 2012 11:37 AM > To: Stephen Hanna > Cc: Adam Montville; Waltermire, David A.; Luis Nunez; Omar Santos; > sacm@ietf.org > Subject: Re: [sacm] Proposed use cases to move forward >=20 > I agree on WG scope. Just distinguishing between doc scope. UC1 and UC3 > for WG scope. Seems that 2, 4, and 5 should be pulled up into a more > informational doc. >=20 > So we can renumber 3 to 2, and describe the others elsewhere. >=20 > Make sense? >=20 > Sent from my iPhone >=20 > On Aug 24, 2012, at 7:44 AM, Stephen Hanna wrote: >=20 > > Adam, > > > > I think the core issue here is scope. Successful IETF Working Groups > > must have a charter that clearly articulates a fairly narrow scope > > with a limited set of deliverables that will provide significant > value > > when completed. Then they must stick to that scope. > > > > Without a clear and narrow scope, WGs wander around and never > complete. > > WG chairs can't shut down irrelevant discussions on the email list. > > People bring in interesting and perhaps worthwhile ideas that > distract > > the group from their goal. Eventually, people get frustrated and > leave. > > The only people who are left are impractical and create a monument to > > their huge intelligence that nobody implements. > > > > You didn't say that you disagree about scope, though. In fact, I > think > > that you have previously said that you agree that we should have a > > narrow scope. So I'll assume that we agree on that topic. > > > > Why would we want to have use cases in the key architecture document > > for SACM that are not in scope for the WG? That will just encourage > > the WG to spend time talking about those use cases. In fact, we'd > > be obligated to spend time talking about them if they're in our > > key architecture document, the main document guiding our WG's work. > > We couldn't approve something with use cases that we haven't reached > > consensus on. > > > > Maybe you're arguing that UC2, UC4, and UC5 should also be in scope > > for this WG. I thought we had already settled that matter but if > > you want to reopen it, please speak up and explain why. > > > > Thanks, > > > > Steve > > > >> -----Original Message----- > >> From: Adam Montville [mailto:amontville@tripwire.com] > >> Sent: Friday, August 24, 2012 9:48 AM > >> To: Stephen Hanna; Waltermire, David A.; Luis Nunez; Omar Santos > >> Cc: sacm@ietf.org > >> Subject: Re: [sacm] Proposed use cases to move forward > >> > >> On 8/23/12 1:37 PM, "Stephen Hanna" wrote: > >> > >>> Dave, > >>> > >>> Sorry to be late in responding to your email. I agree that > >>> we must avoid having our work stray from its place in the > >>> larger picture of security automation. In order to do that > >>> effectively, it would be very useful (one might say essential!) > >>> to have a document that provides that larger picture. If you > >>> want to work on an individual submission to do so, I'd be > >>> glad to work on it with you. Probably several other people > >>> would also. And we can send it to MILE and SACM and other > >>> lists for review. > >> > >> > >> I'm feeling that we're talking about two different levels of > document - > >> one is the use case document, which I think needs to be "broad" in > the > >> sense that we keep the five use cases represented, but only address > UC1 > >> and UC3; the second is a more abstract, context setting > informational > >> document. Are we talking about two things or am I missing > something? > >> > >> > >>> > >>> In IETF, the feedback loop across WGs is usually provided > >>> by having the same people participating in multiple WGs. > >>> The IESG, IAB, and directorates can also provide some > >>> coordination but mostly we count on the individual > >>> participants to do it. > >>> > >>> Thanks, > >>> > >>> Steve > >>> > >>>> -----Original Message----- > >>>> From: Waltermire, David A. [mailto:david.waltermire@nist.gov] > >>>> Sent: Friday, August 17, 2012 12:30 PM > >>>> To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos > >>>> Cc: sacm@ietf.org > >>>> Subject: RE: [sacm] Proposed use cases to move forward > >>>> > >>>> Steve, > >>>> > >>>> These are all valid concerns that I completely agree with. What I > >> am > >>>> struggling with is insuring that the work we are embarking on > >> remains > >>>> relevant in the broader context. My fear is that if we narrow our > >>>> thinking too much, we may inadvertently make decisions that drift > >> from > >>>> addressing the broader set of use cases. I like the idea of > working > >> on > >>>> an individual draft to address the larger context. What I am not > >> sure > >>>> about is how introduce a feedback loop that would result in > >> minimizing > >>>> this kind of risk. I guess this type of issue is something that > we > >>>> will need to collectively monitor and address as needed. > >>>> > >>>> Sincerely, > >>>> Dave > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Stephen Hanna [mailto:shanna@juniper.net] > >>>> Sent: Wednesday, August 15, 2012 3:55 PM > >>>> To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos > >>>> Cc: sacm@ietf.org > >>>> Subject: RE: [sacm] Proposed use cases to move forward > >>>> > >>>> I love broad scope. Don't get me wrong! But I'm concerned about > >> having > >>>> a use cases document and an architecture document for this working > >>>> group that goes way beyond the charter and initial scope for the > >> group. > >>>> > >>>> I'm concerned that this will lead to lots of discussions on the > sacm > >>>> list and lots of effort being spent on topics that are out of > scope, > >>>> diverting us from the tasks at hand and slowing our progress. > >>>> > >>>> I'm concerned that the working group chairs won't be able to cut > off > >>>> discussion of topics by saying they're out of scope for the > working > >>>> group. > >>>> > >>>> I'm concerned that we'll get sidetracked or even derailed by > >>>> controversies that aren't relevant to the scope of the group. > >>>> > >>>> I'm concerned that by including all of security automation within > >> our > >>>> use cases and architecture, we may actually prevent the formation > of > >>>> other working groups that could work on those other use cases. > >>>> > >>>> We have plenty of work to keep us busy for years with UC1 and UC3. > >>>> There's agreement that the technology needed is mature enough for > >> IETF > >>>> standardization. I suggest that we scope this working group to > >> address > >>>> only those use cases and that our use cases and architecture be > >> limited > >>>> to them. > >>>> > >>>> I'm sorely tempted to create an ambitious architecture for > security > >>>> automation that encompasses all of the use cases that we have > >> described > >>>> so far and maybe more. I understand that people have a hard time > >>>> understanding how the NEA and MILE and SACM standards fit together > >> and > >>>> I would love to address that in an IETF RFC. But I have seen > several > >>>> grand architecture efforts die or come to nothing in IETF. IETF is > >>>> filled with smart engineers with clever ideas. We're great at > >> solving > >>>> problems but if we can't agree on the problem to solve or if we > >> choose > >>>> the wrong problem, we can easily spin an intricate and pointless > >> web. > >>>> > >>>> I think we'll do better if we scope our effort properly. > >>>> > >>>> Maybe a few people can create an individual submission describing > a > >>>> grand architecture and roadmap for security automation and ask > >> people > >>>> in SACM to review and provide feedback on that document. That > would > >> be > >>>> a good way to get a grand architecture while still ensuring that > the > >>>> SACM effort keeps its focus. In IETF as in so many things, you > must > >>>> keep your focus or you'll never succeed. > >>>> > >>>> Thanks, > >>>> > >>>> Steve > >>>> > >>>>> -----Original Message----- > >>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > >> Behalf > >>>>> Of Waltermire, David A. > >>>>> Sent: Wednesday, August 15, 2012 1:13 PM > >>>>> To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos > >>>>> Cc: sacm@ietf.org > >>>>> Subject: Re: [sacm] Proposed use cases to move forward > >>>>> > >>>>> +1 on scoping the charter to UC1 and UC3. > >>>>> > >>>>> I think we are better served with a use cases document, and > >>>> eventually > >>>>> an architecture documemnt, that is broader scoped. Both of these > >>>>> documents will help inform the work we will do under the charter > >> as > >>>> it > >>>>> relates to the larger context. > >>>>> > >>>>> To this end I would suggest we focus on expanding the use case > >>>>> document primarily in the areas of UC1 and UC3 for now. We can > >>>> expand > >>>>> the other use cases later. > >>>>> > >>>>> Sincerely, > >>>>> Dave > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > >>>> Behalf > >>>>> Of > >>>>>> Stephen Hanna > >>>>>> Sent: Wednesday, August 15, 2012 11:24 AM > >>>>>> To: Adam Montville; Luis Nunez; Omar Santos > >>>>>> Cc: sacm@ietf.org > >>>>>> Subject: Re: [sacm] Proposed use cases to move forward > >>>>>> > >>>>>> I agree. Let's work on UC1 and UC3. The other use cases are > >>>> valuable > >>>>>> but just doing UC1 and UC3 is plenty of work for this group for > >> the > >>>>>> next year or two (maybe five!). > >>>>>> > >>>>>> I saw several emails in favor of this a few weeks ago. I thought > >>>>>> that it was settled. I'd like to see a revised charter and use > >> case > >>>>>> document, scoped down to focus on just UC1 and UC3. > >>>>>> > >>>>>> What do others think? Do we have rough consensus on this? > >>>>>> If so, let's get moving. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Steve > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Adam Montville [mailto:amontville@tripwire.com] > >>>>>>> Sent: Wednesday, August 15, 2012 10:30 AM > >>>>>>> To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos > >>>>>>> Cc: sacm@ietf.org > >>>>>>> Subject: Re: [sacm] Proposed use cases to move forward > >>>>>>> > >>>>>>> On 8/6/12 7:27 AM, "Adam Montville" > >>>>> wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> UC1 and UC3 both require assessment of endpoint state. If not > >>>> for > >>>>>> the > >>>>>>> NEA > >>>>>>>> ties in UC1, it seems a subset of UC3. So, we should be able > >> to > >>>>>>>> start with the main concern of UC3: Security Configuration > >>>>>> Management. > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I haven't seen much activity on this thread (there was another > >>>>>> thread, > >>>>>>> "Using the Frame of Reference," discussing some approaches we > >> can > >>>>> use > >>>>>>> to keep us focused and meaningful). > >>>>>>> > >>>>>>> Are there any objections to tackling UC3 followed by UC1? > >> Does > >>>>>> anyone > >>>>>>> disagree with my assertion that UC3 is a subset of UC1 and > >> that a > >>>>>>> reasonable starting point is Security Configuration > >> Management? > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> sacm mailing list > >>>>>> sacm@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sacm > >>>>> _______________________________________________ > >>>>> sacm mailing list > >>>>> sacm@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sacm > >>> > >>> > >> > >> > >> > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm >=20 From adam@stoicsecurity.com Fri Aug 24 09:52: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 1187221F86EC for ; Fri, 24 Aug 2012 09:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd3mNO6GwyJM for ; Fri, 24 Aug 2012 09:52:04 -0700 (PDT) Received: from p3plsmtpa09-02.prod.phx3.secureserver.net (p3plsmtpa09-02.prod.phx3.secureserver.net [173.201.193.231]) by ietfa.amsl.com (Postfix) with ESMTP id B656F21F86B7 for ; Fri, 24 Aug 2012 09:51:46 -0700 (PDT) Received: from [172.17.4.220] ([174.47.84.222]) by p3plsmtpa09-02.prod.phx3.secureserver.net with id qgrj1j0024nonZ201grk5Y; Fri, 24 Aug 2012 09:51:44 -0700 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <738E98B9-C0FA-4703-9139-C7BC375F4BFB@stoicsecurity.com> X-Mailer: iPhone Mail (9B206) From: "Adam W. Montville" Date: Fri, 24 Aug 2012 09:42:11 -0700 To: Stephen Hanna Cc: Luis Nunez , "sacm@ietf.org" , "Waltermire, David A." , Omar Santos , Adam Montville Subject: Re: [sacm] Proposed use cases to move forward X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 16:52:20 -0000 Yes. Sent from my iPhone On Aug 24, 2012, at 9:20 AM, Stephen Hanna wrote: > I agree completely as long as the document that contains 2, 4, and 5 > is not a WG document for this WG. Maybe we can put use cases into > the broader architecture document that Dave and I are going to write > (the independent submission). We could even start a non-WG email list > to talk about that document and/or others that span multiple WGs. We > should find ways to continue the broader discussion but not in this WG. > > Does that make sense? > > Thanks, > > Steve > >> -----Original Message----- >> From: Adam Montville [mailto:amontville@tripwire.com] >> Sent: Friday, August 24, 2012 11:37 AM >> To: Stephen Hanna >> Cc: Adam Montville; Waltermire, David A.; Luis Nunez; Omar Santos; >> sacm@ietf.org >> Subject: Re: [sacm] Proposed use cases to move forward >> >> I agree on WG scope. Just distinguishing between doc scope. UC1 and UC3 >> for WG scope. Seems that 2, 4, and 5 should be pulled up into a more >> informational doc. >> >> So we can renumber 3 to 2, and describe the others elsewhere. >> >> Make sense? >> >> Sent from my iPhone >> >> On Aug 24, 2012, at 7:44 AM, Stephen Hanna wrote: >> >>> Adam, >>> >>> I think the core issue here is scope. Successful IETF Working Groups >>> must have a charter that clearly articulates a fairly narrow scope >>> with a limited set of deliverables that will provide significant >> value >>> when completed. Then they must stick to that scope. >>> >>> Without a clear and narrow scope, WGs wander around and never >> complete. >>> WG chairs can't shut down irrelevant discussions on the email list. >>> People bring in interesting and perhaps worthwhile ideas that >> distract >>> the group from their goal. Eventually, people get frustrated and >> leave. >>> The only people who are left are impractical and create a monument to >>> their huge intelligence that nobody implements. >>> >>> You didn't say that you disagree about scope, though. In fact, I >> think >>> that you have previously said that you agree that we should have a >>> narrow scope. So I'll assume that we agree on that topic. >>> >>> Why would we want to have use cases in the key architecture document >>> for SACM that are not in scope for the WG? That will just encourage >>> the WG to spend time talking about those use cases. In fact, we'd >>> be obligated to spend time talking about them if they're in our >>> key architecture document, the main document guiding our WG's work. >>> We couldn't approve something with use cases that we haven't reached >>> consensus on. >>> >>> Maybe you're arguing that UC2, UC4, and UC5 should also be in scope >>> for this WG. I thought we had already settled that matter but if >>> you want to reopen it, please speak up and explain why. >>> >>> Thanks, >>> >>> Steve >>> >>>> -----Original Message----- >>>> From: Adam Montville [mailto:amontville@tripwire.com] >>>> Sent: Friday, August 24, 2012 9:48 AM >>>> To: Stephen Hanna; Waltermire, David A.; Luis Nunez; Omar Santos >>>> Cc: sacm@ietf.org >>>> Subject: Re: [sacm] Proposed use cases to move forward >>>> >>>> On 8/23/12 1:37 PM, "Stephen Hanna" wrote: >>>> >>>>> Dave, >>>>> >>>>> Sorry to be late in responding to your email. I agree that >>>>> we must avoid having our work stray from its place in the >>>>> larger picture of security automation. In order to do that >>>>> effectively, it would be very useful (one might say essential!) >>>>> to have a document that provides that larger picture. If you >>>>> want to work on an individual submission to do so, I'd be >>>>> glad to work on it with you. Probably several other people >>>>> would also. And we can send it to MILE and SACM and other >>>>> lists for review. >>>> >>>> >>>> I'm feeling that we're talking about two different levels of >> document - >>>> one is the use case document, which I think needs to be "broad" in >> the >>>> sense that we keep the five use cases represented, but only address >> UC1 >>>> and UC3; the second is a more abstract, context setting >> informational >>>> document. Are we talking about two things or am I missing >> something? >>>> >>>> >>>>> >>>>> In IETF, the feedback loop across WGs is usually provided >>>>> by having the same people participating in multiple WGs. >>>>> The IESG, IAB, and directorates can also provide some >>>>> coordination but mostly we count on the individual >>>>> participants to do it. >>>>> >>>>> Thanks, >>>>> >>>>> Steve >>>>> >>>>>> -----Original Message----- >>>>>> From: Waltermire, David A. [mailto:david.waltermire@nist.gov] >>>>>> Sent: Friday, August 17, 2012 12:30 PM >>>>>> To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos >>>>>> Cc: sacm@ietf.org >>>>>> Subject: RE: [sacm] Proposed use cases to move forward >>>>>> >>>>>> Steve, >>>>>> >>>>>> These are all valid concerns that I completely agree with. What I >>>> am >>>>>> struggling with is insuring that the work we are embarking on >>>> remains >>>>>> relevant in the broader context. My fear is that if we narrow our >>>>>> thinking too much, we may inadvertently make decisions that drift >>>> from >>>>>> addressing the broader set of use cases. I like the idea of >> working >>>> on >>>>>> an individual draft to address the larger context. What I am not >>>> sure >>>>>> about is how introduce a feedback loop that would result in >>>> minimizing >>>>>> this kind of risk. I guess this type of issue is something that >> we >>>>>> will need to collectively monitor and address as needed. >>>>>> >>>>>> Sincerely, >>>>>> Dave >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Stephen Hanna [mailto:shanna@juniper.net] >>>>>> Sent: Wednesday, August 15, 2012 3:55 PM >>>>>> To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos >>>>>> Cc: sacm@ietf.org >>>>>> Subject: RE: [sacm] Proposed use cases to move forward >>>>>> >>>>>> I love broad scope. Don't get me wrong! But I'm concerned about >>>> having >>>>>> a use cases document and an architecture document for this working >>>>>> group that goes way beyond the charter and initial scope for the >>>> group. >>>>>> >>>>>> I'm concerned that this will lead to lots of discussions on the >> sacm >>>>>> list and lots of effort being spent on topics that are out of >> scope, >>>>>> diverting us from the tasks at hand and slowing our progress. >>>>>> >>>>>> I'm concerned that the working group chairs won't be able to cut >> off >>>>>> discussion of topics by saying they're out of scope for the >> working >>>>>> group. >>>>>> >>>>>> I'm concerned that we'll get sidetracked or even derailed by >>>>>> controversies that aren't relevant to the scope of the group. >>>>>> >>>>>> I'm concerned that by including all of security automation within >>>> our >>>>>> use cases and architecture, we may actually prevent the formation >> of >>>>>> other working groups that could work on those other use cases. >>>>>> >>>>>> We have plenty of work to keep us busy for years with UC1 and UC3. >>>>>> There's agreement that the technology needed is mature enough for >>>> IETF >>>>>> standardization. I suggest that we scope this working group to >>>> address >>>>>> only those use cases and that our use cases and architecture be >>>> limited >>>>>> to them. >>>>>> >>>>>> I'm sorely tempted to create an ambitious architecture for >> security >>>>>> automation that encompasses all of the use cases that we have >>>> described >>>>>> so far and maybe more. I understand that people have a hard time >>>>>> understanding how the NEA and MILE and SACM standards fit together >>>> and >>>>>> I would love to address that in an IETF RFC. But I have seen >> several >>>>>> grand architecture efforts die or come to nothing in IETF. IETF is >>>>>> filled with smart engineers with clever ideas. We're great at >>>> solving >>>>>> problems but if we can't agree on the problem to solve or if we >>>> choose >>>>>> the wrong problem, we can easily spin an intricate and pointless >>>> web. >>>>>> >>>>>> I think we'll do better if we scope our effort properly. >>>>>> >>>>>> Maybe a few people can create an individual submission describing >> a >>>>>> grand architecture and roadmap for security automation and ask >>>> people >>>>>> in SACM to review and provide feedback on that document. That >> would >>>> be >>>>>> a good way to get a grand architecture while still ensuring that >> the >>>>>> SACM effort keeps its focus. In IETF as in so many things, you >> must >>>>>> keep your focus or you'll never succeed. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Steve >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >>>> Behalf >>>>>>> Of Waltermire, David A. >>>>>>> Sent: Wednesday, August 15, 2012 1:13 PM >>>>>>> To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos >>>>>>> Cc: sacm@ietf.org >>>>>>> Subject: Re: [sacm] Proposed use cases to move forward >>>>>>> >>>>>>> +1 on scoping the charter to UC1 and UC3. >>>>>>> >>>>>>> I think we are better served with a use cases document, and >>>>>> eventually >>>>>>> an architecture documemnt, that is broader scoped. Both of these >>>>>>> documents will help inform the work we will do under the charter >>>> as >>>>>> it >>>>>>> relates to the larger context. >>>>>>> >>>>>>> To this end I would suggest we focus on expanding the use case >>>>>>> document primarily in the areas of UC1 and UC3 for now. We can >>>>>> expand >>>>>>> the other use cases later. >>>>>>> >>>>>>> Sincerely, >>>>>>> Dave >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >>>>>> Behalf >>>>>>> Of >>>>>>>> Stephen Hanna >>>>>>>> Sent: Wednesday, August 15, 2012 11:24 AM >>>>>>>> To: Adam Montville; Luis Nunez; Omar Santos >>>>>>>> Cc: sacm@ietf.org >>>>>>>> Subject: Re: [sacm] Proposed use cases to move forward >>>>>>>> >>>>>>>> I agree. Let's work on UC1 and UC3. The other use cases are >>>>>> valuable >>>>>>>> but just doing UC1 and UC3 is plenty of work for this group for >>>> the >>>>>>>> next year or two (maybe five!). >>>>>>>> >>>>>>>> I saw several emails in favor of this a few weeks ago. I thought >>>>>>>> that it was settled. I'd like to see a revised charter and use >>>> case >>>>>>>> document, scoped down to focus on just UC1 and UC3. >>>>>>>> >>>>>>>> What do others think? Do we have rough consensus on this? >>>>>>>> If so, let's get moving. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Adam Montville [mailto:amontville@tripwire.com] >>>>>>>>> Sent: Wednesday, August 15, 2012 10:30 AM >>>>>>>>> To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos >>>>>>>>> Cc: sacm@ietf.org >>>>>>>>> Subject: Re: [sacm] Proposed use cases to move forward >>>>>>>>> >>>>>>>>> On 8/6/12 7:27 AM, "Adam Montville" >>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> UC1 and UC3 both require assessment of endpoint state. If not >>>>>> for >>>>>>>> the >>>>>>>>> NEA >>>>>>>>>> ties in UC1, it seems a subset of UC3. So, we should be able >>>> to >>>>>>>>>> start with the main concern of UC3: Security Configuration >>>>>>>> Management. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I haven't seen much activity on this thread (there was another >>>>>>>> thread, >>>>>>>>> "Using the Frame of Reference," discussing some approaches we >>>> can >>>>>>> use >>>>>>>>> to keep us focused and meaningful). >>>>>>>>> >>>>>>>>> Are there any objections to tackling UC3 followed by UC1? >>>> Does >>>>>>>> anyone >>>>>>>>> disagree with my assertion that UC3 is a subset of UC1 and >>>> that a >>>>>>>>> reasonable starting point is Security Configuration >>>> Management? >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sacm mailing list >>>>>>>> sacm@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>>>> _______________________________________________ >>>>>>> sacm mailing list >>>>>>> sacm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>> >>>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >> > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From amontville@tripwire.com Fri Aug 24 09:56: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 70DE221F86EF for ; Fri, 24 Aug 2012 09:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.969 X-Spam-Level: X-Spam-Status: No, score=-3.969 tagged_above=-999 required=5 tests=[AWL=-0.370, 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 rqQ8CnMGE0cy for ; Fri, 24 Aug 2012 09:56:07 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 5568321F86EC for ; Fri, 24 Aug 2012 09:56:07 -0700 (PDT) Received: from mail56-co1-R.bigfish.com (10.243.78.240) by CO1EHSOBE011.bigfish.com (10.243.66.74) with Microsoft SMTP Server id 14.1.225.23; Fri, 24 Aug 2012 16:56:06 +0000 Received: from mail56-co1 (localhost [127.0.0.1]) by mail56-co1-R.bigfish.com (Postfix) with ESMTP id 73B04B000CB for ; Fri, 24 Aug 2012 16:56:06 +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: -52 X-BigFish: VPS-52(zzbb2dI98dI9371I1503M9f17R146fI542M1432I1418I1455M4015Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h946he5bhf0ah107ah1155h) Received: from mail56-co1 (localhost.localdomain [127.0.0.1]) by mail56-co1 (MessageSwitch) id 1345827364474371_16194; Fri, 24 Aug 2012 16:56:04 +0000 (UTC) Received: from CO1EHSMHS003.bigfish.com (unknown [10.243.78.232]) by mail56-co1.bigfish.com (Postfix) with ESMTP id 71A9B3C0043 for ; Fri, 24 Aug 2012 16:56:04 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CO1EHSMHS003.bigfish.com (10.243.66.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 24 Aug 2012 16:56:03 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id CAF9223211F1 for ; Fri, 24 Aug 2012 09:54:39 -0700 (PDT) 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 045D123211F0; Fri, 24 Aug 2012 09:54:39 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 24 Aug 2012 09:58:41 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Fri, 24 Aug 2012 09:56:01 -0700 From: Adam Montville To: Stephen Hanna , "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Thread-Topic: [sacm] Proposed SACM Charter (was re: Proposed use cases to move forward) Thread-Index: AQHNghlXQdOH1A2xP0eY2r6J1RDJtA== Date: Fri, 24 Aug 2012 16:56:01 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="Windows-1252" Content-ID: <7E5A92C9C0909844A304962841C12520@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: f6b8eae3-bceb-4eb2-9fcd-c7ef903b4417 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: Re: [sacm] Proposed SACM Charter (was re: Proposed use cases to move forward) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 16:56:09 -0000 From: Stephen Hanna > Date: Thursday, August 23, 2012 12:10 PM To: kent_landfield >, "sacm@ietf.org" > Subject: [sacm] Proposed SACM Charter (was re: Proposed use cases to move f= orward) I did a complete review of this proposed SACM charter today. Here are my co= mments. Please review and respond! =B7 Now that we have narrowed our focus to UC1 and UC3, we should c= ontinue to narrow the charter to match that focus. One way to do this would= be to change the proposed WG name from =93Security Automation and Continuo= us Monitoring=94 to =93Security Compliance Automation=94 OR =93Security Aut= omation for Compliance=94. The topic of security automation is a really bro= ad one, including many MILE projects and other things that go way beyond UC= 1 and UC3. I'm not opposed to changing the name, but I don't want to loose continuous = monitoring. I agree that we are compliance focused, but there is an aspect= of continuous monitoring that needs to be addressed and which may not be i= mplied by "security automation." Of the two names suggested, I prefer the latter. =B7 In the first paragraph of the WG Description, I=92d like to sug= gest a few changes to this sentence: =93These standards will support securi= ty practitioners to be better utilized within their organizations by allowi= ng them to meet the more advanced needs of the security community (e.g. inf= ormation sharing, continuous monitoring, remediation and response, result a= ggregation and analysis).=94 Right now, the text seems to imply that our fo= cus will be on defining standards to =93meet the more advanced needs of the= security community=94, including information sharing, continuous monitorin= g, remediation and response, and result aggregation and analysis. I don=92t= quite agree. I think that our goal now is to automate routine tasks relate= d to gathering and managing information about endpoint security so that inf= ormation security practitioners can focus on more advanced needs. Our scope= may include some aspects of information sharing, continuous monitoring, re= mediation and response, and result aggregation and analysis but not the com= plete and total extent of any of those broad topics. So I suggest this repl= acement sentence: =93These standards will help security practitioners to be= better utilized within their organizations by automating routine tasks rel= ated to endpoint security so that practitioners can focus on more advanced = work.=94 Essentially, remove the word "support" from the first sentence and shorten = it up a bit. I agree. =B7 We should delete =93and SOHO=94 from this sentence: =93The init= ial focus of this work is to address enterprise and SOHO use cases.=94 We n= eed to maintain our focus and avoid the added complexities of SOHO. Anyway,= that=92s my view. Agree. This was discussed on the list previously, and I had the sense that= we wanted to remove it, but retain it as an option in the future. =B7 I think the last sentence in the first paragraph (about consumi= ng and continuing work) belongs at the start of the second paragraph. The s= econd paragraph is about how we=92re going to use and enhance standards dev= eloped elsewhere. The first paragraph explains why our work is needed. =B7 In the third paragraph, I=92d say =93use of standard interfaces= =94 not just =93use of interfaces=94. We only want to develop and use stand= ard interfaces. We don=92t want to design a system that will be based on pr= oprietary interfaces. Agree. =B7 The first area of focus is =931. Define, either by normative re= ference, adoption, or creation, a set of standards that can be used for the= purpose of assessing, aggregating and comparing device states against expe= cted values, and reporting on those results in a predefined or ad hoc manne= r.=94 I suggest changing =93assessing, aggregating and comparing device sta= tes against expected values=94 to =93assessing and aggregating device state= s and comparing these device states against expected values=94. Otherwise i= t=92s not clear which verbs are modified by the adverbial phrase =93against= expected values=94. Good catch. =B7 I don=92t think that the third area of focus is needed to addre= ss UC1 and UC3. Therefore, we should take it out. That area is =933. Create= relationships between existing operations management standards to enable a= comprehensive view of security automation, leveraging existing work and im= plementations.=94 This depends on whether "security automation" implies "continuous monitorin= g." Referencing your proposed name change above, if we call the WG "Securi= ty Compliance Automation," would that imply continuous monitoring? If the = suggestion is that it would not, then where and when do we work on continuo= us monitoring? =B7 Let=92s narrow the reference model document to UC1 and UC3 and = add requirements in that document for all the standards that we=92re going = to need. That way, we can do all our architecture and requirements definiti= on in one place. And we can delete the other Informational document in our = list of deliverables. Agree. The informational document would not be included in the WG, but cou= ld still be an independent submission. =B7 Delete the parenthetical mentions of specific existing external= specs from the deliverables (e.g. XCCDF, OVAL). We should not prejudge whi= ch standard the working group will choose for each purpose. Agree. =B7 Don=92t call for multiple Standards Track documents on a single= topic at this point. We should aim to have one standard for each purpose. = I think this comment only applies to the device state checking languages. A= sset identification and reporting are separate things, right? If so, they s= hould be separate deliverables. Agree. And I don=92t know what this deliverable means: =93Standards Track document= s specifying interfaces and communication protocols used for security autom= ation and continuous monitoring=94. If we know what it means, let=92s expla= in it more clearly. If we don=92t know what it means, it shouldn=92t be on = the list. We can always add deliverables later if we need to. We should par= e back our list to only things that we understand now and can describe. Here is another point raising the question of whether continuous monitoring= should be included in the WG. If my understanding of your previous commen= ts is correct, continuous monitoring may be on the chopping block until we = get the automated compliance work completed, and this set of "Standards Tra= ck documents specifying interfaces and communication protocols used for sec= urity automation and continuous monitoring" could reasonably be omitted. =B7 I guess we=92re going to break our deliverables into two phases.= Which deliverables should go in Phase 2? It=92s always hard to decide what= can wait but I=92d suggest these: =93Standards Track document describing t= he messages and network protocols for distributing Security Automation Cont= ent=94, =93Standards Track document describing protocols and data formats f= or securely sharing dynamic network state information among security system= s=94, and any of the other deliverables where we don=92t have a mature spec= (stable with several implementations) with good IPR terms that can be publ= ished as an RFC or referenced with a normative reference. This will allow u= s to rapidly get an open standard solution, even if it can=92t do everythin= g we want. We should check whether pushing out all those deliverables will still let u= s meet a useful subset of UC1 and UC3. If not, we may need to pull some thi= ngs in from Phase 2 but doing so will probably slow down the completion of = Phase 1 considerably. We could also define a Phase 1.5 for any such items w= here lots of work is needed but we really need them. Then we could start wo= rk on those Phase 1.5 deliverables right away, knowing that they probably w= on=92t be ready until after the Phase 1 deliverables. And I hope that we=92= ll make the reference model and protocols extensible so that people can try= out draft specs in a prototype implementation or even make up their own so= lution for some problem and experiment with it without causing massive prob= lems. I'm always curious about defining "half phases." Why not just call it thre= e phases? If I were to draw the line on two phases: Phase 1: Cover foundations relevant to talking about assets and collecting = data * A Standards Track document specifying a device state checking languag= e (NOTE CHANGE from multiple to single) * A Standards Track document specifying an interrogative checking langu= age * A Standards Track document specifying platform naming, matching and a= pplicability * Standards Track documents specifying asset identification and reporti= ng information * NEW: Standards Track document specifying asset description format (no= n-identifying information) * A Standards Track document specifying benchmark configuration represe= ntation Phase 2: Cover the rest * An Informational document stating guidelines / requirements for speci= fying checking languages * IN QUESTION: Standards Track documents specifying standard interfaces= and communication protocols used for security automation and continuous mo= nitoring * A Standards Track document describing the messages and network protoc= ols for distributing Security Automation Content (content repository) * Standards Track document describing integrating security automation a= nd Network Endpoint Assessment capabilities * A Standards Track document describing protocols and data formats for = securely sharing dynamic network state information among security systems * NEW: A Standards Track document specifying a control framework repres= entation format So, I guess I'm also suggesting a slight change in scope (after having thou= ght about and worked on the use case document on mornings and evenings this= week). Something I didn't include here was targeting/tasking, but I think= we should perhaps consider that =96 arguably, targeting/tasking could be i= ncluded in the definition of standard interfaces and communications protoco= ls, which is why I haven't included it here. In phase one, I'm proposing the addition of a specification pertaining to h= olding asset information beyond identification attributes. In phase two, I'm proposing the addition of a standard pertaining to descri= bing and referencing control frameworks. To answer Kent=92s question about how we can most easily track differences = between versions of the charter, I suggest that whoever=92s editing the cha= rter (Kent, it seems) provide a plain text file version of each version of = the charter. Send that out as an attachment to your email and we can all us= e our own tools to do a diff. Agree, but add the (implied) requirement that each version be consistently = formatted. Good charter discussion! Thanks, Steve From:sacm-bounces@ietf.org [mailto:sacm-bounc= es@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Monday, August 20, 2012 4:00 PM To: sacm@ietf.org Subject: Re: [sacm] Proposed use cases to move forward Yes, I agree we need to focus. It appears we have consensus on working on U= C1 and UC3. The use case document as it exists is very broad and its inten= t has expanded a great deal from the initial meeting in Paris. ;-) It is time to focus on the charter and what it is we want this working grou= p to do. We need to put a reasonable box around the effort so we can be pro= ductive. To that end, what follows is an updated version of the charter that was pos= ted just prior to the Vancouver meeting. It has taken into consideration r= equests made on the lists. Let's start discussing it as is. I know there a= re some good suggestions that I have not gotten to incorporate yet. One question that I did have is the draft charter talks about remediation. = What are other's thoughts on including that as a 'potential' for the work = to be done under SACM? Please take a look at it and let's talk about what is here. We will need t= o develop the list of deliverables and the milestones we expect to meet but= that will hopefully be driven by the base charter discussions. As a point of reference, how does the list want to see differences from one= version of the charter to the next? Let's keep it simple if possible=85 --------------------------------- Security Automation Continuous Monitoring (SACM) Proposed Working Group Charter Chairs: TBD TBD Security Area Directors: Stephen Farrell > Sean Turner > Security Area Advisor: Sean Turner > Mailing Lists: General Discussion: sacm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm Description of Working Group Securing information and the systems that store, process, and transmit that= information has become a challenging task for organizations of all sizes, = and we find that security practitioners spend most of their time on manual = processes relegating them to ineffectiveness. Security automation is the ke= y to escaping this rut. This working group will develop security automation= standards in support of information security processes and practices where= practical. These standards will support security practitioners to be bette= r utilized within their organizations by allowing them to meet the more adv= anced needs of the security community (e.g. information sharing, continuous= monitoring, remediation and response, result aggregation and analysis). Th= e initial focus of this work is to address enterprise and SOHO use cases. T= he working group will achieve this by consuming and continuing (with cooper= ation) the security automation work already performed by various organizati= ons around the world. The initial work has been fruitful, and the data formats previously publish= ed are ready for expansion on the international stage. Of particular intere= st to this working group are the security automation specifications support= ing asset, change, configuration, and vulnerability management. Of addition= al interest to this working group are the emerging security automation inte= rfaces and data formats relating to event management and continuous monitor= ing. By undertaking this work, we recognize that there are multiple categories o= f problems in the security automation domain: defining expressions for part= icular domain concepts (i.e. data formats), establishing a standards-based = foundation supporting the curation and exchange of security automation cont= ent collections in content repositories and enabling interoperability throu= gh the development and use of interfaces and communications protocols. Cont= ent based on rich data standards and protocols will provide the authoritati= ve instructions needed by data-driven tools to enable the automated collect= ion and exchange of configuration and vulnerability data pertaining to ente= rprise assets. Information produced by these tools will provide accurate an= d timely situational awareness in support of organizational decision making= . This working group will provide solutions to these categories of problems a= nd the main areas of focus for this working group are described as follows: 1. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used for the purpose of assessing, aggregating and com= paring device states against expected values, and reporting on those result= s in a predefined or ad hoc manner. 2. Define, either by normative reference, adoption, or creation, a set of s= tandards that can be used to continuously monitor and report on the state o= f systems, composed of many different types of devices and networks, operat= ed by varying personnel, to ensure security process effectiveness in a pre-= defined or ad-hoc manner. 3. Create relationships between existing operations management standards to= enable a comprehensive view of security automation, leveraging existing wo= rk and implementations. This working group will produce the following: * An Informational document providing an overview of security automation an= d continuous monitoring to include a reference model * A Standards Track document specifying benchmark configuration representat= ion (XCCDF) * An Informational document stating guidelines / requirements for specifyin= g checking languages * Standards Track documents specifying device state checking languages (OVA= L, ECL, ACEML, =85) * A Standards Track document specifying an interrogative checking language = (OCIL) * A Standards Track document specifying platform naming, matching and appli= cability (CPE) * Standards Track documents specifying asset identification and reporting i= nformation (Asset ID, ARF) * Standards Track documents specifying interfaces and communication protoco= ls used for security automation and continuous monitoring * A Standards Track document describing the messages and network protocols = for distributing Security Automation Content (content repository) * Standards Track document describing integrating security automation and N= etwork Endpoint Assessment capabilities (if-m for SCAP?) * A Standards Track document describing protocols and data formats for secu= rely sharing dynamic network state information among security systems (if-m= ap) Goals and Milestones TBD -------------------------------------------- Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville > Date: Friday, August 17, 2012 12:33 PM To: David Waltermire >, Stephen Hanna >, Lui= s Nunez >, Omar Santo= s > Cc: "sacm@ietf.org" > Subject: Re: [sacm] Proposed use cases to move forward I like taking the scope down as well - and I think we all believe we've agreed to UC1 and UC3. I don't have an issue having the other use cases (2, 4, and 5) described in the use case document, but not fleshed out in the functional capabilities, components, and data/protocol sections. The charter can be derived from the use cases we take on, and a separate informational document can help place those use cases in the right context with respect to the "grand scheme of things." No matter how we slice it, right now we need to focus on the use cases and charter, and to focus on the use cases we would ideally need to work on setting the context. I've tried to do that (to a limited extent) with the informational document I sent to the list. Additionally, I think these efforts need to be done in parallel irrespective of any idealistic dependencies. For example, we should be able to work on a charter, a use case doc, and an informational doc all at the same time, but join the threads for a final alignment pass before submitting them. Adam On 8/17/12 9:30 AM, "Waltermire, David A." > wrote: Steve, These are all valid concerns that I completely agree with. What I am struggling with is insuring that the work we are embarking on remains relevant in the broader context. My fear is that if we narrow our thinking too much, we may inadvertently make decisions that drift from addressing the broader set of use cases. I like the idea of working on an individual draft to address the larger context. What I am not sure about is how introduce a feedback loop that would result in minimizing this kind of risk. I guess this type of issue is something that we will need to collectively monitor and address as needed. Sincerely, Dave -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net] Sent: Wednesday, August 15, 2012 3:55 PM To: Waltermire, David A.; Adam Montville; Luis Nunez; Omar Santos Cc: sacm@ietf.org Subject: RE: [sacm] Proposed use cases to move forward I love broad scope. Don't get me wrong! But I'm concerned about having a use cases document and an architecture document for this working group that goes way beyond the charter and initial scope for the group. I'm concerned that this will lead to lots of discussions on the sacm list and lots of effort being spent on topics that are out of scope, diverting us from the tasks at hand and slowing our progress. I'm concerned that the working group chairs won't be able to cut off discussion of topics by saying they're out of scope for the working group. I'm concerned that we'll get sidetracked or even derailed by controversies that aren't relevant to the scope of the group. I'm concerned that by including all of security automation within our use cases and architecture, we may actually prevent the formation of other working groups that could work on those other use cases. We have plenty of work to keep us busy for years with UC1 and UC3. There's agreement that the technology needed is mature enough for IETF standardization. I suggest that we scope this working group to address only those use cases and that our use cases and architecture be limited to them. I'm sorely tempted to create an ambitious architecture for security automation that encompasses all of the use cases that we have described so far and maybe more. I understand that people have a hard time understanding how the NEA and MILE and SACM standards fit together and I would love to address that in an IETF RFC. But I have seen several grand architecture efforts die or come to nothing in IETF. IETF is filled with smart engineers with clever ideas. We're great at solving problems but if we can't agree on the problem to solve or if we choose the wrong problem, we can easily spin an intricate and pointless web. I think we'll do better if we scope our effort properly. Maybe a few people can create an individual submission describing a grand architecture and roadmap for security automation and ask people in SACM to review and provide feedback on that document. That would be a good way to get a grand architecture while still ensuring that the SACM effort keeps its focus. In IETF as in so many things, you must keep your focus or you'll never succeed. Thanks, Steve -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Waltermire, David A. Sent: Wednesday, August 15, 2012 1:13 PM To: Stephen Hanna; Adam Montville; Luis Nunez; Omar Santos Cc: sacm@ietf.org Subject: Re: [sacm] Proposed use cases to move forward +1 on scoping the charter to UC1 and UC3. I think we are better served with a use cases document, and eventually an architecture documemnt, that is broader scoped. Both of these documents will help inform the work we will do under the charter as it relates to the larger context. To this end I would suggest we focus on expanding the use case document primarily in the areas of UC1 and UC3 for now. We can expand the other use cases later. Sincerely, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bo= unces@ietf.org] On Behalf Of > Stephen Hanna > Sent: Wednesday, August 15, 2012 11:24 AM > To: Adam Montville; Luis Nunez; Omar Santos > Cc: sacm@ietf.org > Subject: Re: [sacm] Proposed use cases to move forward > > I agree. Let's work on UC1 and UC3. The other use cases are valuable > but just doing UC1 and UC3 is plenty of work for this group for the > next year or two (maybe five!). > > I saw several emails in favor of this a few weeks ago. I thought > that it was settled. I'd like to see a revised charter and use case > document, scoped down to focus on just UC1 and UC3. > > What do others think? Do we have rough consensus on this? > If so, let's get moving. > > Thanks, > > Steve > > > -----Original Message----- > > From: Adam Montville [mailto:amontville@tripwire.com] > > Sent: Wednesday, August 15, 2012 10:30 AM > > To: Adam Montville; Stephen Hanna; Luis Nunez; Omar Santos > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Proposed use cases to move forward > > > > On 8/6/12 7:27 AM, "Adam Montville" > wrote: > > > > > > > > > > >UC1 and UC3 both require assessment of endpoint state. If not for > the > > NEA > > >ties in UC1, it seems a subset of UC3. So, we should be able to > > >start with the main concern of UC3: Security Configuration > Management. > > > > > > > > > > > > I haven't seen much activity on this thread (there was another > thread, > > "Using the Frame of Reference," discussing some approaches we can use > > to keep us focused and meaningful). > > > > Are there any objections to tackling UC3 followed by UC1? Does > anyone > > disagree with my assertion that UC3 is a subset of UC1 and that a > > reasonable starting point is Security Configuration Management? > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From anton.chuvakin@gmail.com Fri Aug 24 11:18: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 393AB21F85EA for ; Fri, 24 Aug 2012 11:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMhgeVDcA3Ko for ; Fri, 24 Aug 2012 11:18:41 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F09721F85F3 for ; Fri, 24 Aug 2012 11:18:41 -0700 (PDT) Received: by weyu54 with SMTP id u54so1276574wey.31 for ; Fri, 24 Aug 2012 11:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=UaLGgyZOLNMAQb6eYzJs4ary78R0OgNmhsmE+i461+Q=; b=Bs8CKf1DpkboEzvIVPYyqCSBCQkiRaj1b0h+uyqrCD4j1IIzsmskYQ1WtXO+WJdT+J f9q6oCdnYY07STexFKhHcAFm3PTintnc+zK+RqtDhP2LQMM9sUXftwzx32qcBAsHRlYa tavhj6vsJ2MhzIdgS4dyO9mlK45cS9IsEz07RhYhrizCACXY2/rX6hxohDivHOM4vnVN 9O1HAPuQEB2UowORUxoy33kFcFKy1XI7CmyWFNmrbsf0XdwOexj4pbi1tay9ogt+UiCB 8XKGWeudIpkUKK0VLA7G5SaHK8uwDIq3HkPDT+KHQTmx427zjNf+TiZWyRYWWuuxUWCI 0l1w== Received: by 10.216.238.134 with SMTP id a6mr2971675wer.172.1345832320222; Fri, 24 Aug 2012 11:18:40 -0700 (PDT) MIME-Version: 1.0 Sender: anton.chuvakin@gmail.com Received: by 10.223.14.214 with HTTP; Fri, 24 Aug 2012 11:18:09 -0700 (PDT) In-Reply-To: References: From: Anton Chuvakin Date: Fri, 24 Aug 2012 11:18:09 -0700 X-Google-Sender-Auth: j1zxqZTEIM988aBTDO1rjmKNcB8 Message-ID: To: Adam Montville Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed SACM Charter (was re: Proposed use cases to move forward) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 18:18:42 -0000 > I did a complete review of this proposed SACM charter today. Here are my = comments. Please review and respond! > =B7 Now that we have narrowed our focus to UC1 and UC3, we should= continue to narrow the charter to match that focus. One way to do this wou= ld be to change the proposed WG name from =93Security Automation and Contin= uous Monitoring=94 to =93Security Compliance Automation=94 OR =93Security A= utomation for Compliance=94. The topic of security automation is a really b= road one, including many MILE projects and other things that go way beyond = UC1 and UC3. > I'm not opposed to changing the name, but I don't want to loose continuou= s monitoring. I agree that we are compliance focused, but there is an aspe= ct of continuous monitoring that needs to be addressed and which may not be= implied by "security automation." Where is the word "assessment"? Continuous monitoring really isn't monitoring (well, not activity monitoring), but control assessment. Please don't say "security automation" as we all know security cannot be fully automated. Maybe "security assessment automation", "control assessment automation", but not security automation. --=20 Dr. Anton Chuvakin Site: http://www.chuvakin.org Twitter: @anton_chuvakin Work: http://www.linkedin.com/in/chuvakin From shanna@juniper.net Fri Aug 24 11:29:45 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E8121F85AF for ; Fri, 24 Aug 2012 11:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 eMuhEoBe7q1d for ; Fri, 24 Aug 2012 11:29:44 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC2F21F8687 for ; Fri, 24 Aug 2012 11:29:44 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUDfIF4l7SPDCx6MHyCpeVkUOcm/8QS+n@postini.com; Fri, 24 Aug 2012 11:29:44 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 24 Aug 2012 11:29:26 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 24 Aug 2012 11:29:23 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 24 Aug 2012 14:29:11 -0400 From: Stephen Hanna To: Adam Montville Date: Fri, 24 Aug 2012 14:29:09 -0400 Thread-Topic: [sacm] Proposed SACM Charter (was re: Proposed use cases to move forward) Thread-Index: AQHNghlXQdOH1A2xP0eY2r6J1RDJtJdpME1A 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed SACM Charter (was re: Proposed use cases to move forward) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 18:29:45 -0000 Adam, I found it hard to distinguish your comments from mine in your email so I'll mark your comments here with AM>, and respond inline. I'll mark my previous comments with SH>. And I'll edit out a lot. AM> I'm not opposed to changing the name, but I don't want to loose AM> continuous monitoring. I agree that we are compliance focused, but AM> there is an aspect of continuous monitoring that needs to be addressed AM> and which may not be implied by "security automation." The term "continuous monitoring" seems to be causing confusion. I've seen at least three meanings for it: 1) Everything that's in CAESARS-FE 2) Big Brother monitoring user behavior (web sites visited, etc.) 3) The ability to rapidly detect and handle changes in endpoint assessment I suspect you intend meaning 3). Is that right? I'm going to assume so for the rest of this email. But please clarify. And I think you can see why using that term is problematic. I agree that we don't want to lose the idea that changes in things previously assessed are rapidly detected and handled. That's the core of UC3. I'm looking for a name that matches UC1 and UC3. I'm not entirely happy with any of the names that I proposed but I think they match our revised scope better than SACM. Other suggestions are welcome! SH> * I don't think that the third area of focus is needed to SH> address UC1 and UC3. Therefore, we should take it out. That area is "3. SH> Create relationships between existing operations management standards SH> to enable a comprehensive view of security automation, leveraging SH> existing work and implementations." AM> This depends on whether "security automation" implies "continuous AM> monitoring." Referencing your proposed name change above, if we call AM> the WG "Security Compliance Automation," would that imply continuous AM> monitoring? If the suggestion is that it would not, then where and AM> when do we work on continuous monitoring? I don't think that "security automation" is any better defined than "continuous monitoring". Ignore the WG name for a moment and let's stop using those poorly defined terms for now. Let's use UC1 and UC3 as our guide for what's in scope for this WG. UC3 definitely includes the ability to rapidly detect and handle changes in assessed endpoint state. But I still don't think the third area of focus is needed. Can you explain why area 1 and area 2 are not enough? Remember that area 2 includes "a set of standards that can be used to continuously monitor and report on the state of systems". I think that covers UC3. AM> Phase 1: Cover foundations relevant to talking about assets and AM> collecting data AM>=20 AM>=20 AM> * A Standards Track document specifying a device state checking AM> language (NOTE CHANGE from multiple to single) AM> * A Standards Track document specifying an interrogative checking AM> language AM> * A Standards Track document specifying platform naming, matching AM> and applicability AM> * Standards Track documents specifying asset identification and AM> reporting information AM> * NEW: Standards Track document specifying asset description format AM> (non-identifying information) AM> * A Standards Track document specifying benchmark configuration AM> representation AM>=20 AM>=20 AM> Phase 2: Cover the rest AM>=20 AM>=20 AM> * An Informational document stating guidelines / requirements for AM> specifying checking languages AM> * IN QUESTION: Standards Track documents specifying standard AM> interfaces and communication protocols used for security automation and AM> continuous monitoring AM> * A Standards Track document describing the messages and network AM> protocols for distributing Security Automation Content (content AM> repository) AM> * Standards Track document describing integrating security AM> automation and Network Endpoint Assessment capabilities AM> * A Standards Track document describing protocols and data formats AM> for securely sharing dynamic network state information among security AM> systems AM> * NEW: A Standards Track document specifying a control framework AM> representation format Your Phase 1 only includes data formats. How can we satisfy any part of UC1 or UC3 without some protocols? I think we at least need this deliverable in Phase 1: AM> * Standards Track document describing integrating security AM> automation and Network Endpoint Assessment capabilities Thanks, Steve From amontville@tripwire.com Fri Aug 24 12:10:31 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A7D21F8533 for ; Fri, 24 Aug 2012 12:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.962 X-Spam-Level: X-Spam-Status: No, score=-3.962 tagged_above=-999 required=5 tests=[AWL=-0.363, 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 ty4Kw4UequFb for ; Fri, 24 Aug 2012 12:10:30 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 9558921F852B for ; Fri, 24 Aug 2012 12:10:29 -0700 (PDT) Received: from mail42-am1-R.bigfish.com (10.3.201.249) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 24 Aug 2012 19:10:28 +0000 Received: from mail42-am1 (localhost [127.0.0.1]) by mail42-am1-R.bigfish.com (Postfix) with ESMTP id 50A6F1E00B0 for ; Fri, 24 Aug 2012 19:10:28 +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: -26 X-BigFish: VPS-26(zzbb2dI98dI9371I1432I1418I4015Izz1202hzz8275ch1033IL8275dhz2dh2a8h668h839h944he5bhf0ah107ah1155h) Received: from mail42-am1 (localhost.localdomain [127.0.0.1]) by mail42-am1 (MessageSwitch) id 1345835426129019_7739; Fri, 24 Aug 2012 19:10:26 +0000 (UTC) Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.226]) by mail42-am1.bigfish.com (Postfix) with ESMTP id 1CE4540068 for ; Fri, 24 Aug 2012 19:10:26 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 24 Aug 2012 19:10:25 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 6045E23211F1 for ; Fri, 24 Aug 2012 12:08:59 -0700 (PDT) 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 B944C23211EA; Fri, 24 Aug 2012 12:08:58 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 24 Aug 2012 12:13:01 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Fri, 24 Aug 2012 12:10:22 -0700 From: Adam Montville To: Stephen Hanna Thread-Topic: [sacm] Proposed SACM Charter (was re: Proposed use cases to move forward) Thread-Index: AQHNghlXQdOH1A2xP0eY2r6J1RDJtJdpME1AgAAjtQA= Date: Fri, 24 Aug 2012 19:10:21 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: 7bcd395b-c5f6-41a2-b858-e5c14a51b3ea 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] Proposed SACM Charter (was re: Proposed use cases to move forward) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 19:10:31 -0000 On 8/24/12 11:29 AM, "Stephen Hanna" wrote: >Adam, > >I found it hard to distinguish your comments from mine in your email >so I'll mark your comments here with AM>, and respond inline. I'll >mark my previous comments with SH>. And I'll edit out a lot. Thanks, and sorry about that. This thread enjoys plain text; internal people enjoy HTML; Outlook for the Mac doesn't handle the mix gracefully. > >AM> I'm not opposed to changing the name, but I don't want to loose >AM> continuous monitoring. I agree that we are compliance focused, but >AM> there is an aspect of continuous monitoring that needs to be addressed >AM> and which may not be implied by "security automation." > >The term "continuous monitoring" seems to be causing confusion. >I've seen at least three meanings for it: > >1) Everything that's in CAESARS-FE > >2) Big Brother monitoring user behavior (web sites visited, etc.) > >3) The ability to rapidly detect and handle changes in endpoint assessment > >I suspect you intend meaning 3). Is that right? I'm going to >assume so for the rest of this email. But please clarify. And >I think you can see why using that term is problematic. Yes, yes, and yes I can see. Suggest we take Anton's suggestion and consider a different word from "monitoring," such as "assessment." It's concise. > >I agree that we don't want to lose the idea that changes in things >previously assessed are rapidly detected and handled. That's the >core of UC3. > >I'm looking for a name that matches UC1 and UC3. I'm not entirely >happy with any of the names that I proposed but I think they match >our revised scope better than SACM. Other suggestions are welcome! I'm at a loss for names, except for this one. Acceptable State/Security Enforcement and Setting Support =3D ASSESS > >SH> * I don't think that the third area of focus is needed to >SH> address UC1 and UC3. Therefore, we should take it out. That area is >"3. >SH> Create relationships between existing operations management standards >SH> to enable a comprehensive view of security automation, leveraging >SH> existing work and implementations." > >AM> This depends on whether "security automation" implies "continuous >AM> monitoring." Referencing your proposed name change above, if we call >AM> the WG "Security Compliance Automation," would that imply continuous >AM> monitoring? If the suggestion is that it would not, then where and >AM> when do we work on continuous monitoring? > >I don't think that "security automation" is any better defined >than "continuous monitoring". Ignore the WG name for a moment >and let's stop using those poorly defined terms for now. > >Let's use UC1 and UC3 as our guide for what's in scope for this >WG. UC3 definitely includes the ability to rapidly detect and >handle changes in assessed endpoint state. But I still don't think >the third area of focus is needed. Can you explain why area 1 and >area 2 are not enough? Remember that area 2 includes "a set of >standards that can be used to continuously monitor and report >on the state of systems". I think that covers UC3. > >AM> Phase 1: Cover foundations relevant to talking about assets and >AM> collecting data >AM>=20 >AM>=20 >AM> * A Standards Track document specifying a device state checking >AM> language (NOTE CHANGE from multiple to single) >AM> * A Standards Track document specifying an interrogative checking >AM> language >AM> * A Standards Track document specifying platform naming, matching >AM> and applicability >AM> * Standards Track documents specifying asset identification and >AM> reporting information >AM> * NEW: Standards Track document specifying asset description >format >AM> (non-identifying information) >AM> * A Standards Track document specifying benchmark configuration >AM> representation >AM>=20 >AM>=20 >AM> Phase 2: Cover the rest >AM>=20 >AM>=20 >AM> * An Informational document stating guidelines / requirements for >AM> specifying checking languages >AM> * IN QUESTION: Standards Track documents specifying standard >AM> interfaces and communication protocols used for security automation >and >AM> continuous monitoring >AM> * A Standards Track document describing the messages and network >AM> protocols for distributing Security Automation Content (content >AM> repository) >AM> * Standards Track document describing integrating security >AM> automation and Network Endpoint Assessment capabilities >AM> * A Standards Track document describing protocols and data formats >AM> for securely sharing dynamic network state information among security >AM> systems >AM> * NEW: A Standards Track document specifying a control framework >AM> representation format > >Your Phase 1 only includes data formats. How can we satisfy >any part of UC1 or UC3 without some protocols? I think we >at least need this deliverable in Phase 1: > >AM> * Standards Track document describing integrating security >AM> automation and Network Endpoint Assessment capabilities Agreed. Good catch - working too quickly in the face of deadlines and a week-long vacation. We would change the term "security automation" to whatever we consider more appropriate, and potentially split these into two documents. Would it make sense for one document to describe the integration with NEA capabilities and the other to describe the coordination of the data formats for the actual assessment? > >Thanks, > >Steve > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm > > From shanna@juniper.net Fri Aug 24 12:33:27 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C3A21F8599 for ; Fri, 24 Aug 2012 12:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 gCiqAJAlqPAY for ; Fri, 24 Aug 2012 12:33:26 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8A421F845B for ; Fri, 24 Aug 2012 12:33:25 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUDfXBFNFgHAjQVMrxsPKoZbmtQHPJk8R@postini.com; Fri, 24 Aug 2012 12:33:26 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 24 Aug 2012 12:33:04 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 24 Aug 2012 15:33:04 -0400 From: Stephen Hanna To: Adam Montville Date: Fri, 24 Aug 2012 15:33:03 -0400 Thread-Topic: [sacm] Proposed SACM Charter Thread-Index: AQHNghlXQdOH1A2xP0eY2r6J1RDJtJdpME1AgAAjtQCAAAEIQA== 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed SACM Charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 19:33:27 -0000 Adam, Quick response and very thorough, considering you're going away on vacation soon! Now that we're back in plain text, things should work better. I have simplified the Subject line since we're clearly talking about the charter. Adam Montville wrote: > Steve Hanna wrote: > >The term "continuous monitoring" seems to be causing confusion. >=20 > Suggest we take Anton's suggestion and consider a different word > from "monitoring," such as "assessment." It's concise. Good idea! We used "assessment" in the NEA working group so it also remains consistent with previous IETF terminology. So we can talk about assessment. And when we want to specifically mention the ability to rapidly detect and handle changes in assessment, we can talk about "continuous assessment". But "assessment" should do the trick, for the most part. I love your suggested WG name: Acceptable State/Security Enforcement and Setting Support =3D ASSESS! It's a cute acronym in the tradition of mile and kitten and lemonade. I don't think the words will cause any trouble or confusion. We'll see. I'm sure we'll hear from other people with concerns and other ideas. I didn't see any comments from you about why the third area of focus is needed in the charter. Unless I hear otherwise, I'll assume that you're OK with deleting it. I'm glad that you agreed with adding this deliverable to Phase 1: > * Standards Track document describing integrating security > automation and Network Endpoint Assessment capabilities I agree that we should change the term "security automation" there to something more appropriate. How about this text instead? * Standards Track document describing how to use the languages and other content defined in this group with the NEA protocols I don't think we need to split this document into two. TCG has been working on one document that covers all of that handily. If this deliverable gets adopted, I expect that TCG will donate the document to IETF so that it can become an RFC. That's what we did for several of the TNC protocols that became NEA RFCs. Thanks, Steve > -----Original Message----- > From: Adam Montville [mailto:amontville@tripwire.com] > Sent: Friday, August 24, 2012 3:10 PM > To: Stephen Hanna > Cc: sacm@ietf.org > Subject: Re: [sacm] Proposed SACM Charter (was re: Proposed use cases > to move forward) >=20 > On 8/24/12 11:29 AM, "Stephen Hanna" wrote: >=20 > >Adam, > > > >I found it hard to distinguish your comments from mine in your email > >so I'll mark your comments here with AM>, and respond inline. I'll > >mark my previous comments with SH>. And I'll edit out a lot. >=20 >=20 > Thanks, and sorry about that. This thread enjoys plain text; internal > people enjoy HTML; Outlook for the Mac doesn't handle the mix > gracefully. >=20 >=20 >=20 > > > >AM> I'm not opposed to changing the name, but I don't want to loose > >AM> continuous monitoring. I agree that we are compliance focused, > but > >AM> there is an aspect of continuous monitoring that needs to be > addressed > >AM> and which may not be implied by "security automation." > > > >The term "continuous monitoring" seems to be causing confusion. > >I've seen at least three meanings for it: > > > >1) Everything that's in CAESARS-FE > > > >2) Big Brother monitoring user behavior (web sites visited, etc.) > > > >3) The ability to rapidly detect and handle changes in endpoint > assessment > > > >I suspect you intend meaning 3). Is that right? I'm going to > >assume so for the rest of this email. But please clarify. And > >I think you can see why using that term is problematic. >=20 >=20 > Yes, yes, and yes I can see. Suggest we take Anton's suggestion and > consider a different word from "monitoring," such as "assessment." > It's > concise. >=20 >=20 > > > >I agree that we don't want to lose the idea that changes in things > >previously assessed are rapidly detected and handled. That's the > >core of UC3. > > > >I'm looking for a name that matches UC1 and UC3. I'm not entirely > >happy with any of the names that I proposed but I think they match > >our revised scope better than SACM. Other suggestions are welcome! >=20 >=20 > I'm at a loss for names, except for this one. >=20 > Acceptable State/Security Enforcement and Setting Support =3D ASSESS >=20 >=20 >=20 >=20 > > > >SH> * I don't think that the third area of focus is needed to > >SH> address UC1 and UC3. Therefore, we should take it out. That area > is > >"3. > >SH> Create relationships between existing operations management > standards > >SH> to enable a comprehensive view of security automation, leveraging > >SH> existing work and implementations." > > > >AM> This depends on whether "security automation" implies "continuous > >AM> monitoring." Referencing your proposed name change above, if we > call > >AM> the WG "Security Compliance Automation," would that imply > continuous > >AM> monitoring? If the suggestion is that it would not, then where > and > >AM> when do we work on continuous monitoring? > > > >I don't think that "security automation" is any better defined > >than "continuous monitoring". Ignore the WG name for a moment > >and let's stop using those poorly defined terms for now. > > > >Let's use UC1 and UC3 as our guide for what's in scope for this > >WG. UC3 definitely includes the ability to rapidly detect and > >handle changes in assessed endpoint state. But I still don't think > >the third area of focus is needed. Can you explain why area 1 and > >area 2 are not enough? Remember that area 2 includes "a set of > >standards that can be used to continuously monitor and report > >on the state of systems". I think that covers UC3. > > > >AM> Phase 1: Cover foundations relevant to talking about assets and > >AM> collecting data > >AM> > >AM> > >AM> * A Standards Track document specifying a device state > checking > >AM> language (NOTE CHANGE from multiple to single) > >AM> * A Standards Track document specifying an interrogative > checking > >AM> language > >AM> * A Standards Track document specifying platform naming, > matching > >AM> and applicability > >AM> * Standards Track documents specifying asset identification > and > >AM> reporting information > >AM> * NEW: Standards Track document specifying asset description > >format > >AM> (non-identifying information) > >AM> * A Standards Track document specifying benchmark > configuration > >AM> representation > >AM> > >AM> > >AM> Phase 2: Cover the rest > >AM> > >AM> > >AM> * An Informational document stating guidelines / requirements > for > >AM> specifying checking languages > >AM> * IN QUESTION: Standards Track documents specifying standard > >AM> interfaces and communication protocols used for security > automation > >and > >AM> continuous monitoring > >AM> * A Standards Track document describing the messages and > network > >AM> protocols for distributing Security Automation Content (content > >AM> repository) > >AM> * Standards Track document describing integrating security > >AM> automation and Network Endpoint Assessment capabilities > >AM> * A Standards Track document describing protocols and data > formats > >AM> for securely sharing dynamic network state information among > security > >AM> systems > >AM> * NEW: A Standards Track document specifying a control > framework > >AM> representation format > > > >Your Phase 1 only includes data formats. How can we satisfy > >any part of UC1 or UC3 without some protocols? I think we > >at least need this deliverable in Phase 1: > > > >AM> * Standards Track document describing integrating security > >AM> automation and Network Endpoint Assessment capabilities >=20 >=20 > Agreed. Good catch - working too quickly in the face of deadlines and > a > week-long vacation. >=20 > We would change the term "security automation" to whatever we consider > more appropriate, and potentially split these into two documents. > Would > it make sense for one document to describe the integration with NEA > capabilities and the other to describe the coordination of the data > formats for the actual assessment? >=20 >=20 >=20 > > > >Thanks, > > > >Steve > > > >_______________________________________________ > >sacm mailing list > >sacm@ietf.org > >https://www.ietf.org/mailman/listinfo/sacm > > > > >=20 >=20 >=20 From david.oliva@verizon.net Sun Aug 26 11:54:43 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7684B21F84EC for ; Sun, 26 Aug 2012 11:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.64 X-Spam-Level: X-Spam-Status: No, score=0.64 tagged_above=-999 required=5 tests=[AWL=-0.916, BAYES_50=0.001, 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 XKXQ1fHNPBug for ; Sun, 26 Aug 2012 11:54:43 -0700 (PDT) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by ietfa.amsl.com (Postfix) with ESMTP id 15EDC21F84EA for ; Sun, 26 Aug 2012 11:54:43 -0700 (PDT) Received: from vms170025pub.verizon.net ([unknown] [192.168.1.3]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M9D00AUQLUREG90@vms173019.mailsrvcs.net> for sacm@ietf.org; Sun, 26 Aug 2012 13:54:27 -0500 (CDT) Received: from 96.241.55.45 ([96.241.55.45]) by vms170025 (Verizon Webmail) with HTTP; Sun, 26 Aug 2012 13:54:27 -0500 (CDT) Date: Sun, 26 Aug 2012 13:54:27 -0500 (CDT) From: david.oliva@verizon.net To: sacm@ietf.org Message-id: <1863083.990990.1346007267476.JavaMail.root@vms170025> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7bit X-Mailer: Verizon Webmail X-Originating-IP: [96.241.55.45] Subject: [sacm] Continuous Compliance in lieu of Continuous 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: Sun, 26 Aug 2012 18:54:43 -0000
To all:
 
I have followed the discussion about the "continuous monitoring" term and am surprised about the amount of controversy is has caused.
Perhaps replacing it with  the expression "Contiinuous Compliance" does not generate as much debate.
 
David Oliva
From solin@farnamhallventures.com Sun Aug 26 12:05:46 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3CC121F84DC for ; Sun, 26 Aug 2012 12:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5NwriCnsSgd for ; Sun, 26 Aug 2012 12:05:44 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 722C021F84FA for ; Sun, 26 Aug 2012 12:05:37 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so7993031obb.31 for ; Sun, 26 Aug 2012 12:05:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type:x-gm-message-state; bh=uz22moak0ejw5W2vrI9BnySC/9Zdwa6wKIpef4wIjGo=; b=A8LIAlKi8C/j0pg9ASKM20Zm0N6h+DHR8GINWuedr8yeOJyAlHVCCQ65ZhvGIhk9kc zulucjAcjzwqPBtkkjU+mVx4odVNkWg5UL3yDXhp7JTsXZDDCjUDnx3HvyBFGMaDFrCF 0ONeS2pMPvnlCbiZv6eZC+9MkM8li5bGg/cLx6dfOOn/2qbxnGShNyfve3njGUzcutTs gxzkO/pK3fNH5chemod0ngIzX9GQPIFT9cQGbu3ei/FFG7fRBNEajZexlGdpBxjuVsfv +dX+Ah52ErGc8rsgLwyB/t91EipBhzJHq9Wo4iNrXd+bR4C96cSLVIwMjH2e5mInCmSC CiUg== Received: by 10.182.73.65 with SMTP id j1mr8591398obv.42.1346007932816; Sun, 26 Aug 2012 12:05:32 -0700 (PDT) Received: from [192.168.0.113] (cpe-70-123-137-202.austin.res.rr.com. [70.123.137.202]) by mx.google.com with ESMTPS id qk5sm15138963obc.10.2012.08.26.12.05.31 (version=SSLv3 cipher=OTHER); Sun, 26 Aug 2012 12:05:31 -0700 (PDT) Sender: David Solin Message-ID: <503A737A.50808@joval.org> Date: Sun, 26 Aug 2012 14:05:30 -0500 From: David Solin Organization: jOVAL User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sacm@ietf.org References: <1863083.990990.1346007267476.JavaMail.root@vms170025> In-Reply-To: <1863083.990990.1346007267476.JavaMail.root@vms170025> Content-Type: multipart/mixed; boundary="------------010906080502060601040204" X-Gm-Message-State: ALoCoQkrP47cXXbHrn2vVB29WOgseBLjehUPUrQgM5zEKEABmRJRhVmjQ+XfT601hgzkQGpzjVcj Subject: Re: [sacm] Continuous Compliance in lieu of Continuous 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: Sun, 26 Aug 2012 19:05:46 -0000 This is a multi-part message in MIME format. --------------010906080502060601040204 Content-Type: multipart/alternative; boundary="------------010909090602000909080600" --------------010909090602000909080600 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit David, I wholly agree! I made precisely this same recommendation to Dave Waltermire (NIST) in July; see my email, attached! On 8/26/2012 1:54 PM, david.oliva@verizon.net wrote: > To all: > I have followed the discussion about the "continuous monitoring" term > and am surprised about the amount of controversy is has caused. > Perhaps replacing it with the expression "Contiinuous Compliance" > does not generate as much debate. > David Oliva -- jOVAL.org: OVAL implemented in Java. /Scan any machine from any machine. For free!/ Learn More | Features | Download --------------010909090602000909080600 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit David, I wholly agree!  I made precisely this same recommendation to Dave Waltermire (NIST) in July; see my email, attached!

On 8/26/2012 1:54 PM, david.oliva@verizon.net wrote:
To all:
 
I have followed the discussion about the "continuous monitoring" term and am surprised about the amount of controversy is has caused.
Perhaps replacing it with  the expression "Contiinuous Compliance" does not generate as much debate.
 
David Oliva


--

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

--------------010909090602000909080600-- --------------010906080502060601040204 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" Message-ID: <4FFD9680.8060308@farnamhallventures.com> Date: Wed, 11 Jul 2012 10:06:40 -0500 From: David Solin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Waltermire, David A." Subject: Continuous Monitoring Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Dave, From a naming perspective, I think that the use of the word "Monitoring" is very unfortunate, and is likely a source of a lot of the confusion in the community. The word monitoring has been tied for decades specifically with event monitoring software solutions like HP Open-View, Marcury interactive, and BMC PATROL. Analysts now use the word "assurance" to describe this market, but monitoring has stuck. I think that, given all the use-cases covered by CM, a much better name would be something like "continuous compliance". That's a term that BMC has been using for several years to describe its solutions that (1) detect configuration deviations, (2) open tickets, and (3) close those tickets when fixes are deployed. It might resonate much more with the community, and even alleviate a lot of the contention around the word "continuous". Just my $.02. Regards, --David Solin --------------010906080502060601040204-- From dcougias@netfrontiers.com Mon Aug 27 10:34: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 1D40721F84A7 for ; Mon, 27 Aug 2012 10:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[AWL=0.391, 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 UxzEN0cTvDpf for ; Mon, 27 Aug 2012 10:34:52 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 75C9621F846B for ; Mon, 27 Aug 2012 10:34:52 -0700 (PDT) Received: by dadf8 with SMTP id f8so2634116dad.31 for ; Mon, 27 Aug 2012 10:34:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:reply-to:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:x-priority:user-agent:x-mailer :x-zohomail-sender:x-gm-message-state; bh=ddUtfPI3+UtHwEcKBq7oFkkHf10SXT5f1LBG5uNxDLk=; b=jsI6nmV2wKGIFt9xXJ3DLPcFtENxgA1LnbSu9uKdEjBKqRi1qiq4OPXpoYibvN5L/7 R9N8/0nvbaCUQt6tclPIEhmz2CXuuUgriidQWzUxserT1RtktPjvTo9UZ7rvudtB0OHx udC7RNoamHDYNqxyDq4VvXuov4l8dE4QzzCrTmIjFpNREYHEh9EB7iLMLIFYgHmR3aQP 5tYq+0s+CJOXN9nu1cFyp59rSI/DmhgNohPzwXDGwVtnJOZ/sWgBUo7ZG7hsAz9FEqZu 5RQdwr02SS+8bM69ZWRKYUsDLB9ORHOnyJG7SKgGMG8Qu0HQ079jhYELKJF1yqgKZOCz h6JQ== Received: by 10.66.88.198 with SMTP id bi6mr31770299pab.23.1346088886685; Mon, 27 Aug 2012 10:34:46 -0700 (PDT) Received: from mail.zoho.com (sender1.zohomail.com. [72.5.230.103]) by mx.google.com with ESMTPS id st6sm15101068pbc.58.2012.08.27.10.34.45 (version=SSLv3 cipher=OTHER); Mon, 27 Aug 2012 10:34:45 -0700 (PDT) Date: Mon, 27 Aug 2012 10:34:44 -0700 From: Dorian Cougias To: Message-ID: <13969265905.4688488019845754479.6368589883267893577@netfrontiers.com> In-Reply-To: <1863083.990990.1346007267476.JavaMail.root@vms170025> References: <1863083.990990.1346007267476.JavaMail.root@vms170025> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_69544_1637011253.1346088884484" X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-ZohoMail-Sender: 173.11.102.17 X-Gm-Message-State: ALoCoQn75kA2nGVRjv63/ZH0YAXhZWnou4N0AHEwKC/A8abFfg5L6RcdrAMAKYjhi+qZ0i/ghCyC Cc: sacm@ietf.org Subject: Re: [sacm] Continuous Compliance in lieu of Continuous Monitoring X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcougias@netfrontiers.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 17:34:53 -0000 ------=_Part_69544_1637011253.1346088884484 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I don't think the controversy is over monitoring, I think the controversy is over "continuous". So whether to call it monitoring or compliance isn't the case. Dorian J. Cougias Compliance Scientist Unified Compliance Framework ---- On Sun, 26 Aug 2012 11:54:27 -0700 <david.oliva@verizon.net> wrote ---- To all: I have followed the discussion about the "continuous monitoring" term and am surprised about the amount of controversy is has caused. Perhaps replacing it with the expression "Contiinuous Compliance" does not generate as much debate. David Oliva _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_Part_69544_1637011253.1346088884484 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
I don't think the controversy is over monitoring, I think the= controversy is over "continuous".

So whether to call it= monitoring or compliance isn't the case.



Dorian J. Cougias
Compliance Scientist
Unified Compliance Framework


---- On= Sun, 26 Aug 2012 11:54:27 -0700 <david.oliva@verizon.net> wrote ---- <= br>

To all:
 
I have followed the discussion a= bout the "continuous monitoring" term and am surprised about the amount of = controversy is has caused.
Perhaps replacing it with  the ex= pression "Contiinuous Compliance" does not generate as much debate.
 
David Oliva
_______________________________= ________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinf= o/sacm

------=_Part_69544_1637011253.1346088884484-- From kathleen.moriarty@emc.com Mon Aug 27 10:45: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 4D03121F84FD for ; Mon, 27 Aug 2012 10:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.057, 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 TaR-zrsaVR0j for ; Mon, 27 Aug 2012 10:45:50 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2D32721F853D for ; Mon, 27 Aug 2012 10:45:49 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q7RHjlFm007565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2012 13:45:48 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 27 Aug 2012 13:45:31 -0400 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 q7RHjUV9031200; Mon, 27 Aug 2012 13:45:30 -0400 Received: from mx15a.corp.emc.com ([169.254.1.66]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Mon, 27 Aug 2012 13:45:30 -0400 From: "Moriarty, Kathleen" To: "dcougias@netfrontiers.com" , "david.oliva@verizon.net" Date: Mon, 27 Aug 2012 13:45:28 -0400 Thread-Topic: [sacm] Continuous Compliance in lieu of Continuous Monitoring Thread-Index: Ac2EenHcLOWsRcAlR02HRRJxDKD81AAAURFg Message-ID: References: <1863083.990990.1346007267476.JavaMail.root@vms170025> <13969265905.4688488019845754479.6368589883267893577@netfrontiers.com> In-Reply-To: <13969265905.4688488019845754479.6368589883267893577@netfrontiers.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_F5063677821E3B4F81ACFB7905573F2405718FBCMX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "sacm@ietf.org" Subject: Re: [sacm] Continuous Compliance in lieu of Continuous 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: Mon, 27 Aug 2012 17:45:51 -0000 --_000_F5063677821E3B4F81ACFB7905573F2405718FBCMX15Acorpemccom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V291bGQgQ29tcGxpYW5jZSBNb25pdG9yaW5nIHdvcms/DQoNClRoYW5rcywNCkthdGhsZWVuDQoN CkZyb206IHNhY20tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIERvcmlhbiBDb3VnaWFzDQpTZW50OiBNb25kYXksIEF1Z3VzdCAyNywg MjAxMiAxOjM1IFBNDQpUbzogZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQNCkNjOiBzYWNtQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW3NhY21dIENvbnRpbnVvdXMgQ29tcGxpYW5jZSBpbiBsaWV1IG9m IENvbnRpbnVvdXMgTW9uaXRvcmluZw0KDQpJIGRvbid0IHRoaW5rIHRoZSBjb250cm92ZXJzeSBp cyBvdmVyIG1vbml0b3JpbmcsIEkgdGhpbmsgdGhlIGNvbnRyb3ZlcnN5IGlzIG92ZXIgImNvbnRp bnVvdXMiLg0KDQpTbyB3aGV0aGVyIHRvIGNhbGwgaXQgbW9uaXRvcmluZyBvciBjb21wbGlhbmNl IGlzbid0IHRoZSBjYXNlLg0KDQoNCkRvcmlhbiBKLiBDb3VnaWFzDQpDb21wbGlhbmNlIFNjaWVu dGlzdA0KVW5pZmllZCBDb21wbGlhbmNlIEZyYW1ld29yaw0KDQoNCi0tLS0gT24gU3VuLCAyNiBB dWcgMjAxMiAxMTo1NDoyNyAtMDcwMCA8ZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ8bWFpbHRvOmRh dmlkLm9saXZhQHZlcml6b24ubmV0Pj4gd3JvdGUgLS0tLQ0KDQpUbyBhbGw6DQoNCkkgaGF2ZSBm b2xsb3dlZCB0aGUgZGlzY3Vzc2lvbiBhYm91dCB0aGUgImNvbnRpbnVvdXMgbW9uaXRvcmluZyIg dGVybSBhbmQgYW0gc3VycHJpc2VkIGFib3V0IHRoZSBhbW91bnQgb2YgY29udHJvdmVyc3kgaXMg aGFzIGNhdXNlZC4NClBlcmhhcHMgcmVwbGFjaW5nIGl0IHdpdGggIHRoZSBleHByZXNzaW9uICJD b250aWludW91cyBDb21wbGlhbmNlIiBkb2VzIG5vdCBnZW5lcmF0ZSBhcyBtdWNoIGRlYmF0ZS4N Cg0KRGF2aWQgT2xpdmENCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpzYWNtIG1haWxpbmcgbGlzdA0Kc2FjbUBpZXRmLm9yZzxtYWlsdG86c2FjbUBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbQ0KDQo= --_000_F5063677821E3B4F81ACFB7905573F2405718FBCMX15Acorpemccom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48aGVhZD48bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlw ZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxp YnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0 IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hl YWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29y ZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldvdWxk IENvbXBsaWFuY2UgTW9uaXRvcmluZyB3b3JrPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhhbmtzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5LYXRobGVlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2 IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIic+IHNhY20tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNhY20tYm91 bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5Eb3JpYW4gQ291Z2lhczxicj48Yj5T ZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgMjcsIDIwMTIgMTozNSBQTTxicj48Yj5Ubzo8L2I+IGRh dmlkLm9saXZhQHZlcml6b24ubmV0PGJyPjxiPkNjOjwvYj4gc2FjbUBpZXRmLm9yZzxicj48Yj5T dWJqZWN0OjwvYj4gUmU6IFtzYWNtXSBDb250aW51b3VzIENvbXBsaWFuY2UgaW4gbGlldSBvZiBD b250aW51b3VzIE1vbml0b3Jpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwi c2Fucy1zZXJpZiInPkkgZG9uJ3QgdGhpbmsgdGhlIGNvbnRyb3ZlcnN5IGlzIG92ZXIgbW9uaXRv cmluZywgSSB0aGluayB0aGUgY29udHJvdmVyc3kgaXMgb3ZlciAmcXVvdDtjb250aW51b3VzJnF1 b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYi Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz5TbyB3aGV0aGVyIHRvIGNh bGwgaXQgbW9uaXRvcmluZyBvciBjb21wbGlhbmNlIGlzbid0IHRoZSBjYXNlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48ZGl2IGlkPSIiPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMt c2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRh bmEiLCJzYW5zLXNlcmlmIic+RG9yaWFuIEouIENvdWdpYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+Q29tcGxpYW5jZSBTY2llbnRp c3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNl cmlmIic+VW5pZmllZCBDb21wbGlhbmNlIEZyYW1ld29yazxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxkaXYgaWQ9MT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+PGJyPi0tLS0g T24gU3VuLCAyNiBBdWcgMjAxMiAxMTo1NDoyNyAtMDcwMCA8Yj4mbHQ7PGEgaHJlZj0ibWFpbHRv OmRhdmlkLm9saXZhQHZlcml6b24ubmV0IiB0YXJnZXQ9Il9ibGFuayI+ZGF2aWQub2xpdmFAdmVy aXpvbi5uZXQ8L2E+Jmd0OzwvYj4gd3JvdGUgLS0tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA1LjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQnPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz5UbyBhbGw6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5JIGhhdmUgZm9sbG93ZWQg dGhlIGRpc2N1c3Npb24gYWJvdXQgdGhlICZxdW90O2NvbnRpbnVvdXMgbW9uaXRvcmluZyZxdW90 OyB0ZXJtIGFuZCBhbSBzdXJwcmlzZWQgYWJvdXQgdGhlIGFtb3VudCBvZiBjb250cm92ZXJzeSBp cyBoYXMgY2F1c2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5QZXJoYXBzIHJlcGxhY2luZyBpdCB3aXRoICZuYnNw O3RoZSBleHByZXNzaW9uICZxdW90O0NvbnRpaW51b3VzIENvbXBsaWFuY2UmcXVvdDsgZG9lcyBu b3QgZ2VuZXJhdGUgYXMgbXVjaCBkZWJhdGUuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz5EYXZpZCBPbGl2YTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRh bmEiLCJzYW5zLXNlcmlmIic+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18gPGJyPnNhY20gbWFpbGluZyBsaXN0IDxicj48YSBocmVmPSJtYWlsdG86c2FjbUBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNhY21AaWV0Zi5vcmc8L2E+IDxicj48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20iIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY208L2E+IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Jsb2NrcXVvdGU+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1s Pg== --_000_F5063677821E3B4F81ACFB7905573F2405718FBCMX15Acorpemccom_-- From solin@farnamhallventures.com Mon Aug 27 13:40: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 7096221F849A for ; Mon, 27 Aug 2012 13:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNfcsef1aFXr for ; Mon, 27 Aug 2012 13:40:10 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED5821F8499 for ; Mon, 27 Aug 2012 13:40:09 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so10340126obb.31 for ; Mon, 27 Aug 2012 13:40:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type:x-gm-message-state; bh=qhmcj7D8ajepS1koGsCxs3N8yIw1MLFwJFNc6ACEPac=; b=V8ya+sUZExlVoj2aFqOdXAHSu+8C+xDC0bMcKxLvyso5InV0rVT3GuLtPBlLW79kB3 isliotek2ZX0ALJhS0gWlB1yz/TqrnZAMctTUchCaX0ov/Fl4U4Qtaol7xo7f1/DlRNF Hn04VSnR2PSD5UN/+FKos7qmwdRDqjlbl9KkljtOJnyhbi6DqNrXRs9I8kmqWoBQFVsq 9AMR8Jy2LAjcqILQsqrXp908uD4aBng6vW32DCCw1m1l0NXs6UiNjR+pZJYqURUtmmaY odhyy6+NHgvqWuF6uRhTN1GM1tT2YiSlWUkVjoiW1HJ7MNW6WkEGv72EOUnS01qdwjwd GzRA== Received: by 10.60.19.168 with SMTP id g8mr11148474oee.134.1346100009348; Mon, 27 Aug 2012 13:40:09 -0700 (PDT) Received: from [192.168.0.113] (cpe-70-123-137-202.austin.res.rr.com. [70.123.137.202]) by mx.google.com with ESMTPS id a3sm13240622oeb.6.2012.08.27.13.40.06 (version=SSLv3 cipher=OTHER); Mon, 27 Aug 2012 13:40:08 -0700 (PDT) Sender: David Solin Message-ID: <503BDB24.9060307@joval.org> Date: Mon, 27 Aug 2012 15:40:04 -0500 From: David Solin Organization: jOVAL User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sacm@ietf.org References: <1863083.990990.1346007267476.JavaMail.root@vms170025> <13969265905.4688488019845754479.6368589883267893577@netfrontiers.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020303010308050508080608" X-Gm-Message-State: ALoCoQnJPnw6qdD9MtqSleAis+rdinGaKEG8WRO8V2C/fWQdbdCIg7kq/31WcYgkBkDTw5wrtTIR Subject: Re: [sacm] Continuous Compliance in lieu of Continuous 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: Mon, 27 Aug 2012 20:40:11 -0000 This is a multi-part message in MIME format. --------------020303010308050508080608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit My reason for not piping up earlier is that I don't personally care. It's a rose by any other name, right? The name doesn't offend me. But clearly the name is causing indigestion. I believe that the reason is what I have described -- that companies selling billions of dollars of products, and analysts from which customers who buy those products seek guidance, have together trained the marketplace to respond to certain keywords in certain ways. In our case, I think it's the gerund (verb functioning as a noun) -- monitoring -- that is causing angst. When people hear the word monitoring they have been conditioned to expect to see a solution that processes certain types of events. Then adjective continuous takes on a real-time connotation, that has little to do with SCAP. I believe that what SCAP standards address is the compliance market, because the standards let you make assertions about the configuration state of an environment. So I would make compliance our noun. The adjective we pick is just additional branding. Do we want to be pigeon-holed into security? If so, we could call it security compliance. Do we want it to seem timely and all-encompassing? Then we should keep the adjective continuous. Google "continuous monitoring" (~7 million results), and you'll see why people who have spent a long time working with the US government think it's a good fit for what we're talking about. Google "continuous compliance" (~48 million results), and you'll see why people who have spent a long time working with commercial enterprise software think it's a good fit for what we're talking about. You'll also notice a lot of the same links from the first list. And that's why I think "continuous compliance" is a better fit. It also has the benefit of being in current use by vendors and analysts, and so the marketplace wouldn't need to be trained to understand it. However, Kathleen's suggestion of compliance monitoring is also quite descriptive, and I believe differentiates itself sufficiently from the unadorned word "monitoring" that it could also probably work just fine. Regards. --David Solin On 8/27/2012 12:45 PM, Moriarty, Kathleen wrote: > > Would Compliance Monitoring work? > > Thanks, > > Kathleen > > *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf > Of *Dorian Cougias > *Sent:* Monday, August 27, 2012 1:35 PM > *To:* david.oliva@verizon.net > *Cc:* sacm@ietf.org > *Subject:* Re: [sacm] Continuous Compliance in lieu of Continuous > Monitoring > > I don't think the controversy is over monitoring, I think the > controversy is over "continuous". > > So whether to call it monitoring or compliance isn't the case. > > Dorian J. Cougias > > Compliance Scientist > > Unified Compliance Framework > > > ---- On Sun, 26 Aug 2012 11:54:27 -0700 * >* wrote ---- > > To all: > > I have followed the discussion about the "continuous monitoring" > term and am surprised about the amount of controversy is has caused. > > Perhaps replacing it with the expression "Contiinuous Compliance" > does not generate as much debate. > > David Oliva > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm -- jOVAL.org: OVAL implemented in Java. /Scan any machine from any machine. For free!/ Learn More | Features | Download --------------020303010308050508080608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit My reason for not piping up earlier is that I don't personally care.  It's a rose by any other name, right?  The name doesn't offend me.  But clearly the name is causing indigestion.  I believe that the reason is what I have described -- that companies selling billions of dollars of products, and analysts from which customers who buy those products seek guidance, have together trained the marketplace to respond to certain keywords in certain ways.

In our case, I think it's the gerund (verb functioning as a noun) -- monitoring -- that is causing angst.  When people hear the word monitoring they have been conditioned to expect to see a solution that processes certain types of events.  Then adjective continuous takes on a real-time connotation, that has little to do with SCAP.

I believe that what SCAP standards address is the compliance market, because the standards let you make assertions about the configuration state of an environment.  So I would make compliance our noun.  The adjective we pick is just additional branding.  Do we want to be pigeon-holed into security?  If so, we could call it security compliance.  Do we want it to seem timely and all-encompassing?  Then we should keep the adjective continuous.

Google "continuous monitoring" (~7 million results), and you'll see why people who have spent a long time working with the US government think it's a good fit for what we're talking about.

Google "continuous compliance" (~48 million results), and you'll see why people who have spent a long time working with commercial enterprise software think it's a good fit for what we're talking about.  You'll also notice a lot of the same links from the first list.

And that's why I think "continuous compliance" is a better fit.  It also has the benefit of being in current use by vendors and analysts, and so the marketplace wouldn't need to be trained to understand it.

However, Kathleen's suggestion of compliance monitoring is also quite descriptive, and I believe differentiates itself sufficiently from the unadorned word "monitoring" that it could also probably work just fine.

Regards.
--David Solin

On 8/27/2012 12:45 PM, Moriarty, Kathleen wrote:

Would Compliance Monitoring work?

 

Thanks,

Kathleen

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Dorian Cougias
Sent: Monday, August 27, 2012 1:35 PM
To: david.oliva@verizon.net
Cc: sacm@ietf.org
Subject: Re: [sacm] Continuous Compliance in lieu of Continuous Monitoring

 

I don't think the controversy is over monitoring, I think the controversy is over "continuous".

 

So whether to call it monitoring or compliance isn't the case.

 

 

Dorian J. Cougias

Compliance Scientist

Unified Compliance Framework

 


---- On Sun, 26 Aug 2012 11:54:27 -0700 <david.oliva@verizon.net> wrote ----

 

To all:

 

I have followed the discussion about the "continuous monitoring" term and am surprised about the amount of controversy is has caused.

Perhaps replacing it with  the expression "Contiinuous Compliance" does not generate as much debate.

 

David Oliva

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

 



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


--

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

--------------020303010308050508080608-- From david.oliva@verizon.net Wed Aug 29 04:54:59 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 114A521F8616 for ; Wed, 29 Aug 2012 04:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.166 X-Spam-Level: * X-Spam-Status: No, score=1.166 tagged_above=-999 required=5 tests=[AWL=-1.274, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, 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 3PmcRsYbm9wT for ; Wed, 29 Aug 2012 04:54:58 -0700 (PDT) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA1321F84AF for ; Wed, 29 Aug 2012 04:54:58 -0700 (PDT) Received: from vms170025pub.verizon.net ([unknown] [192.168.1.3]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M9I004B3MFAF470@vms173005.mailsrvcs.net> for sacm@ietf.org; Wed, 29 Aug 2012 06:54:47 -0500 (CDT) Received: from 96.241.55.45 ([96.241.55.45]) by vms170025 (Verizon Webmail) with HTTP; Wed, 29 Aug 2012 06:54:46 -0500 (CDT) Date: Wed, 29 Aug 2012 06:54:46 -0500 (CDT) From: david.oliva@verizon.net To: sacm@ietf.org Message-id: <9062004.1217302.1346241286638.JavaMail.root@vms170025> MIME-version: 1.0 Content-type: multipart/mixed; boundary="----=_Part_1217301_2206622.1346241286457" X-Mailer: Verizon Webmail X-Originating-IP: [96.241.55.45] Subject: [sacm] SACM in support of protecting personal and health info under ISO 27001 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 29 Aug 2012 11:54:59 -0000 ------=_Part_1217301_2206622.1346241286457 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hel= lo all: 
 

The attached spreadsheet i= s an abstraction of SP 800-53, SP 800-122, and SP 800-66 to show how SACM p= roducts can assist international organizations pursuing the protection of p= ersonal and health information.  This capability can only be achieved when the SCAP/SACM content used is= tier IV (see SP 800-70), and your products (as a minimum) display the cont= ent.  More marketable still, =  is that your products genera= te SCAP/SACM content that other (perhaps validated) products can use.<= o:p>

For instance, if a SACM configurat= ion scanner finds a non-compliant remote access control (AC-17) configurati= on issue, your product can display the finding as a HIPAA issue (because it= maps to 800-122), as PII issue (because it maps to 800-66), or as an OSI 2= 7001 issue (because it maps to A.10.6.1, A.10.8.1, or others).  Notice also that SACM products may be = able to later support compliance with the CobiT and COSO models (future wor= k).

 
David Oliva
------=_Part_1217301_2206622.1346241286457 Content-Type: application/octet-stream; name="HIPAA-PII--SP-800-53 Security Control mappings.xlsx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="HIPAA-PII--SP-800-53 Security Control mappings.xlsx" UEsDBBQABgAIAAAAIQBBN4LPcgEAAAQFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACs lMtuwjAQRfeV+g+Rt1Vi6KKqKgKLPpYtEvQDTDwkFo5teQYKf99JeKhCPBSVTaLYnnvudTwejNa1 TVYQ0XiXi37WEwm4wmvjylx8Tz/SZ5EgKaeV9Q5ysQEUo+H93WC6CYAJVzvMRUUUXqTEooJaYeYD OJ6Z+1gr4s9YyqCKhSpBPvZ6T7LwjsBRSo2GGA7eYK6WlpL3NQ9vncyME8nrdl2DyoUKwZpCERuV K6ePIKmfz00B2hfLmqUzDBGUxgqAapuFaJgYJ0DEwVDIk8wIFrtBd6kyrmyNYWUCPnD0M4Rm5nyq Xd0X/45oNCRjFelT1Zxdrq388XEx836RXRbpujXtFmW1Mm7v+wK/XYyyffVvbKTJ1wpf8UF8xkC2 z/9baGWuAJE2FvDGabei18iViqAnxKe3vLmBv9qXfHBLjaMPyF0bofsu7FukqU4DC0EkA4cmOXXY DkRu+e7Ao4sAmjtFgz7Blu0dNvwFAAD//wMAUEsDBBQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAgC X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjJLPTsMwDMbvSLxD5PvqbkgIoaW7TEi7IVQewCTuH7WNoyRA9/aE A4JKY9vR9ufPP1ve7uZpVB8cYi9Ow7ooQbEzYnvXanitn1YPoGIiZ2kUxxqOHGFX3d5sX3iklJti 1/uosouLGrqU/CNiNB1PFAvx7HKlkTBRymFo0ZMZqGXclOU9hr8eUC081cFqCAd7B6o++jz5src0 TW94L+Z9YpdOjECeEzvLduVDZgupz9uomkLLSYMV85zTEcn7ImMDnibaXE/0/7Y4cSJLidBI4PM8 34pzQOvrgS6faKn4vc484qeE4U1k+GHBxQ9UXwAAAP//AwBQSwMEFAAGAAgAAAAhAIE+lJf0AAAA ugIAABoACAF4bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKySz0rEMBDG74LvEOZu064iIpvuRYS9an2AkEybsm0SMuOfvr2hotuFZb30 EvhmyPf9Mpnt7mscxAcm6oNXUBUlCPQm2N53Ct6a55sHEMTaWz0EjwomJNjV11fbFxw050vk+kgi u3hS4Jjjo5RkHI6aihDR504b0qg5y9TJqM1Bdyg3ZXkv09ID6hNPsbcK0t7egmimmJP/9w5t2xt8 CuZ9RM9nIiTxNOQHiEanDlnBjy4yI8jz8Zs14zmPBY/ps5TzWV1iqNZk+AzpQA6Rjxx/JZJz5yLM 3Zow5HRC+8opr9vyW5bl38nIk42rvwEAAP//AwBQSwMEFAAGAAgAAAAhAEaRQd1HAQAAFAIAAA8A AAB4bC93b3JrYm9vay54bWyMUctOwzAQvCPxD5bv1EnaRqVqUgkBoheERKFnE28aq35EtkPav2ed KDxunNazux7PjDfbs1bkE5yX1hQ0nSWUgKmskOZY0Lf9482KEh+4EVxZAwW9gKfb8vpq01t3+rD2 RJDA+II2IbRrxnzVgOZ+ZlswOKmt0zwgdEfmWwdc+AYgaMWyJMmZ5tLQkWHt/sNh61pWcG+rToMJ I4kDxQPK941sPS03tVTwPjoivG2fuUbdZ0WJ4j48CBlAFHSJ0Pbwp+G69q6TCqe382ROWflt8sUR ATXvVNijvYkd88oWWZbHzRjFu4Te/1yKkJwP0gjbx1WM9jKhOYJ+mBykCA2OV/kCNY29J5DHJqCM JF1GcvaLfcgPXxkqMYO515hpih8V6w7149mtJR7cTqQDw3St4qpCN7EMi4tlno0b04eWXwAAAP// AwBQSwMEFAAGAAgAAAAhADGiQtXgCAAA4iQAABQAAAB4bC9zaGFyZWRTdHJpbmdzLnhtbKxa2W7b VhB9D5B/uNBTCkSr5SWB7YBVNgFxI1j2B9DUjU1EIlUudt2v75m7keKMvAAFAuRmOMuZMwvJUKef /tms1b0uyjTPznrjwaindJbkqzS7PetdX33tn/RUWcXZKl7nmT7rPeqy9+n87ZvTsqwUbLPyrHdX VduPw2GZ3OlNXA7yrc5w5VdebOIK/yxuh+W20PGqvNO62qyHk9HoaLiJ06ynkrzOqrPewfG4p+os /bvWMyuZTKe989MyPT+tzqNZ/+B0WJ2fDunfQXYoyI4E2fhYEE7GgnD8gQmv+5Ou7GIhyhhE6E0F Ww77us9gw5bJlrM+wwfZ5KQbZDnngS+jPssYMpYcZCwRyFgiix8c4GLZZ1ii6z6jfxZx2fyyz4iB jJEAW4YFMqaHnmH5QsZsSY8lfBFxMEiOOYSMEQgZ8wcZCwwZSxgylghkjECAZnGjK44PMkmP4YMe wwcZw4fGkmTMH/RYI8yFZoOMxYWMxYCM8QIZ4wUNw2oEGeMAMoYZMo7lkseYLXgMyFgMyFgMyFgM yFi+kLF8IWP5QsZ4hoxtCcjGo+6WwNQwsiDjiQgbYRnxIIsv3B9kzB9kjBjIGDGQMWIg49scq0gK whiEMWMQMsYgpp8RAxmLARmLQeuEGZOQWZOQ5UdC5pOSZiBnFwJwoTUxJoxt3DT4zsOi5sCvuTH0 WKngkAHEDmD+IGMVIDCMHPQXC4IyM4eQsexORqP+IZMu5nP1ji6NJ5M/uqPwfb6IInv56IhdnS9/ DudfZmpyPBoxBNHhYDwYv1fm7wn+Hhw5gTkckOTEScYjfwknCOnaGNbhNKGTFR4PjLOxdz/ACZcj 6E/MJRymwfC4dZq876ZHCA4GBoox94GtI4IwGUwBRuF0ODjCyQbjfsYTKLDKIIsRZWvyaWc2HRy6 HKeDY3fyiSGkS3GPT+Jxhz6K4kQA2rAGGjhSwbpt06TekDg1JBAdU0MCnZCtw+3zI9ysu8AAkLl8 6OTJPhzwGR+AggFrebiQSdxJNNBpu4OgeoAN6DbZvtaIyUlCxCb9dhwPH30lWFG/eL9iJqFp6fDM UNiqWnfBbl//HbnmDyOFgyvlB4Sy3WaS4rD9FHZMuCK1DltTEVrBMfTKpNC0I9cZwYXNzxTzEN0i kWzM/EhRoYy2kdo0nzbkacEH/XFunghqW6sVCbrOjhIQGtq6FhosJLyHM7cuTW6hPuStFc+3BnqO J0W1OqGUqDNs147CIJqN6UgW+5SMjPu2tR90mkZPhV/WtNwm79++iYjKk9Z2E3InaL5oWA1PYN/p BhEo5tACpUPXFb2Gfyy3cYLXc7xnl7q4173zVzYsjY9Ha2LJeA0hbV30hmEYe6R1sryRzNaETtY7 nYQO2hnjRlNYtERrB8Vu7BdGbJIwMHm6jUKzl1+gik4PhFgo1PtCIjt3DG8FclzT0Um22nf/gSXP AlHay9oiojuURfmSeMAm+MW4OR+Un/VGJ3p8cA8r3Cqo0sFUkcppjOlg0El7oNlAmCTStzGauOJy ME3FQYQOGpMz26p0EtgmVZuQQcB9vSqhDwiyM2OGqGeSMEY8cONrzwPJq5C1Vu4Ijye2mnSy7NDJ d04Dt33ynS7WwTzvmLbYdS4QDiDt8NYtySxv1Lg+lDhURIu5PdLBPnLKHvFELJNqy71r1GKhY/T/ 7l4Cbbingw/a0OwuYqS9bHe4rYUrfAco7ge00PzzeOPKByJXwpM9GTlIbmJJYmoQ/NHB0kb1sSjM k6mMoWssTh75NJ5COLQGxtG0kQkjOw82/lkQZsJaDNip85vHM7F9Q0+BePExOpTNrnQO7JlZNJif 3H/Bwf4HY0cXFLCqOASzVWWxQA+9Lxqq6WDgmTdIbk+oDdNha9PBVJi2b+gcXw1cdRX0Y244dfcM +JJCuCe7Vgjn2cTiFhS52RKCy0AnHQL7BtmTZaDbv1EHy34EzUMmx0A7z6ZqjLhCePak9nNwJ6HD 9xjh/dvHpbdmIbVQkOA/PNty/kxoi5JA2NQaOLtPwPbqnrDw5F/nmzFt22Pg3B0A02JOiBfSFlsW PpGNs2qexSVPsj38S7MPEl13mzKy/2/7Cx+6eL1MhsJgQY4/NiW4dYDpJMwVVYc2paKDvT01NX/W 2kII5HEahQ2+1EldpNWjmuVZVeRrdZVWa55ekuiyDDqLfJ0mjwpf/dSiyBO9qvFawShJzMc7dRFn 8a3e6KwSNMjrlwyfAhNRY06X8JUQHx/V13X+8JTuUm/jwqrmv9Tnuko5ph86xmfJRZHep2t9y9Jc Ag6F+pEnv7tgA1FRVRXpTV1x75d6k1daRYasrr2VBgqRl7rIbwBDfdb3KejtGszy9Tq+yV1KxHWb jeVdXOAbbNeoQfkQFzojesnyqsDXVKirF1WOO9kbxjt+VkFd6iQvVkKWWRUnVake0upOhcjfirze WuxRWeZJagrLrKN6lVYmQ9BLH4ZjMErd/KI8jXV8gxJ8uUd7Mu80EpArtJMNtCcHe3FZoVa3Ws1i vGoDQ5cS7+I+1Q+Y0SxeP5Zp+d6gv9TbvKiEenqjVZ2YIaBiWmX1DeW1zdGNFFgEdegAGj3LUV3d 5UX6rx0SQxFmxFzaP8aCM0bUTmM+lpXeUJ9n2mBm2o3HNp5uEkR+mtV5XWJOshTkCvSIgTdbLGik PM+oqnnBKmFd3+J3DGiUdZy9fDK6ljJo63nfaHR9qCtdiqVfV7rIYiwU31nLtGIrKwpapoTYX5hy SfFKrzGBmw1+RZHYYcK0FeLmEVj9M05+19tuuoIijQh+LmJvDvSPDMlVWMZ5xqxXKE/6y8EJHUpC i1C9w29D4sw1bLxWNf7vqmTfX+z+7Fd5357U/DnH+5Bo7OT9dyt0q8NGu/uFel+1Xt2AvG7IWfG4 rfLbIt7epQk6fFVjDUVNCImvLEkpMyyAEi1e6pdtuTkz29eZgqbcmkHxO/bRWpxLB/Wp0Q3Z7Nl9 IUrIF/sspR8bJWwMZriVXql3X+sKjyKsQ2Y/lz+Fi0P8Run8PwAAAP//AwBQSwMEFAAGAAgAAAAh ADttMkvBAAAAQgEAACMAAAB4bC93b3Jrc2hlZXRzL19yZWxzL3NoZWV0MS54bWwucmVsc4SPwYrC MBRF9wP+Q3h7k9aFDENTNyK4VecDYvraBtuXkPcU/XuzHGXA5eVwz+U2m/s8qRtmDpEs1LoCheRj F2iw8HvaLb9BsTjq3BQJLTyQYdMuvpoDTk5KiceQWBULsYVRJP0Yw37E2bGOCamQPubZSYl5MMn5 ixvQrKpqbfJfB7QvTrXvLOR9V4M6PVJZ/uyOfR88bqO/zkjyz4RJOZBgPqJIOchF7fKAYkHrd/ae a30OBKZtzMvz9gkAAP//AwBQSwMEFAAGAAgAAAAhAPtipW2UBgAApxsAABMAAAB4bC90aGVtZS90 aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9tJ7YbB3WK2LGbrU0bxG6HHmmZllhTokDSSX0b2uOAAcO6 YZcBu+0wbCvQArt0nyZbh60D+hX2SEqyGMtL0gYb1tWHRCJ/fP/f4yN19dqDiKFDIiTlcdurXa56 iMQ+H9M4aHt3hv1LGx6SCsdjzHhM2t6cSO/a1vvvXcWbKiQRQbA+lpu47YVKJZuVivRhGMvLPCEx zE24iLCCVxFUxgIfAd2IVdaq1WYlwjT2UIwjIHt7MqE+QUNN0tvKiPcYvMZK6gGfiYEmTZwVBjue 1jRCzmWXCXSIWdsDPmN+NCQPlIcYlgom2l7V/LzK1tUK3kwXMbVibWFd3/zSdemC8XTN8BTBKGda 69dbV3Zy+gbA1DKu1+t1e7WcngFg3wdNrSxFmvX+Rq2T0SyA7OMy7W61Ua27+AL99SWZW51Op9FK ZbFEDcg+1pfwG9VmfXvNwRuQxTeW8PXOdrfbdPAGZPHNJXz/SqtZd/EGFDIaT5fQ2qH9fko9h0w4 2y2FbwB8o5rCFyiIhjy6NIsJj9WqWIvwfS76ANBAhhWNkZonZIJ9iOIujkaCYs0AbxJcmLFDvlwa 0ryQ9AVNVNv7MMGQEQt6r55//+r5U/Tq+ZPjh8+OH/50/OjR8cMfLS1n4S6Og+LCl99+9ufXH6M/ nn7z8vEX5XhZxP/6wye//Px5ORAyaCHRiy+f/PbsyYuvPv39u8cl8G2BR0X4kEZEolvkCB3wCHQz hnElJyNxvhXDEFNnBQ6Bdgnpngod4K05ZmW4DnGNd1dA8SgDXp/dd2QdhGKmaAnnG2HkAPc4Zx0u Sg1wQ/MqWHg4i4Ny5mJWxB1gfFjGu4tjx7W9WQJVMwtKx/bdkDhi7jMcKxyQmCik5/iUkBLt7lHq 2HWP+oJLPlHoHkUdTEtNMqQjJ5AWi3ZpBH6Zl+kMrnZss3cXdTgr03qHHLpISAjMSoQfEuaY8Tqe KRyVkRziiBUNfhOrsEzIwVz4RVxPKvB0QBhHvTGRsmzNbQH6Fpx+A0O9KnX7HptHLlIoOi2jeRNz XkTu8Gk3xFFShh3QOCxiP5BTCFGM9rkqg+9xN0P0O/gBxyvdfZcSx92nF4I7NHBEWgSInpmJEl9e J9yJ38GcTTAxVQZKulOpIxr/XdlmFOq25fCubLe9bdjEypJn90SxXoX7D5boHTyL9wlkxfIW9a5C v6vQ3ltfoVfl8sXX5UUphiqtGxLba5vOO1rZeE8oYwM1Z+SmNL23hA1o3IdBvc4cOkl+EEtCeNSZ DAwcXCCwWYMEVx9RFQ5CnEDfXvM0kUCmpAOJEi7hvGiGS2lrPPT+yp42G/ocYiuHxGqPj+3wuh7O jhs5GSNVYM60GaN1TeCszNavpERBt9dhVtNCnZlbzYhmiqLDLVdZm9icy8HkuWowmFsTOhsE/RBY uQnHfs0azjuYkbG2u/VR5hbjhYt0kQzxmKQ+0nov+6hmnJTFypIiWg8bDPrseIrVCtxamuwbcDuL k4rs6ivYZd57Ey9lEbzwElA7mY4sLiYni9FR22s11hoe8nHS9iZwVIbHKAGvS91MYhbAfZOvhA37 U5PZZPnCm61MMTcJanD7Ye2+pLBTBxIh1Q6WoQ0NM5WGAIs1Jyv/WgPMelEKlFSjs0mxvgHB8K9J AXZ0XUsmE+KrorMLI9p29jUtpXymiBiE4yM0YjNxgMH9OlRBnzGVcONhKoJ+ges5bW0z5RbnNOmK l2IGZ8cxS0KclludolkmW7gpSLkM5q0gHuhWKrtR7vyqmJS/IFWKYfw/U0XvJ3AFsT7WHvDhdlhg pDOl7XGhQg5VKAmp3xfQOJjaAdECV7wwDUEFd9TmvyCH+r/NOUvDpDWcJNUBDZCgsB+pUBCyD2XJ RN8pxGrp3mVJspSQiaiCuDKxYo/IIWFDXQObem/3UAihbqpJWgYM7mT8ue9pBo0C3eQU882pZPne a3Pgn+58bDKDUm4dNg1NZv9cxLw9WOyqdr1Znu29RUX0xKLNqmdZAcwKW0ErTfvXFOGcW62tWEsa rzUy4cCLyxrDYN4QJXCRhPQf2P+o8Jn94KE31CE/gNqK4PuFJgZhA1F9yTYeSBdIOziCxskO2mDS pKxp09ZJWy3brC+40835njC2luws/j6nsfPmzGXn5OJFGju1sGNrO7bS1ODZkykKQ5PsIGMcY76U FT9m8dF9cPQOfDaYMSVNMMGnKoGhhx6YPIDktxzN0q2/AAAA//8DAFBLAwQUAAYACAAAACEAUbzN DKACAABxBgAADQAAAHhsL3N0eWxlcy54bWykVVtr2zAUfh/sPwi9p7KzpGuC7bI0DRS2MWgGe1Vs 2RHVxUhKa3fsv+/Ichx3XVlHX+Kjo6PvfOea5LKRAt0zY7lWKY7PIoyYynXBVZXi79vN5AIj66gq qNCKpbhlFl9m798l1rWC3e4ZcwgglE3x3rl6SYjN90xSe6ZrpuCm1EZSB0dTEVsbRgvrH0lBplF0 TiTlCgeEpcxfAyKpuTvUk1zLmjq+44K7tsPCSObLm0ppQ3cCqDbxjOZH7O7wDF7y3GirS3cGcESX Jc/Zc5YLsiCAlCWlVs6iXB+US/EUoL2H5Z3SD2rjryCBvVWW2Ed0TwVoYkyyJNdCG+QgM0Cs0ygq WbC4ooLvDPdmJZVctEE99Youmb2d5BCaVxLPI7D508/bUTtwC+hciFGsQZElkHPHjNrALerlbVtD UAraI5CDq39aV4a28XQ+ekA6h1my06aAdjxm2Sc0qLJEsNJB+IZXe/91uobfnXYOapclBaeVVlSA SI4vegHCyZkQt75lf5RPsJsSqYPcSHdTpBia36f2KEIgvRjwwsHjj9EC9gh2BpT/HxY15YD/0usY +P2d1PAa0boWre/Gvs9ewvKxvgrrk+CVkiwAZgk0aziiB0PrLWuOjkhTvinuwPxFb3tt+COE5Wcq BzYsjIJ32pUDCjCq8pMaD9VCfjxS/NWvJAHj22cc7Q5cOK6G/J/qC5hFc+qYyDes8+ul66XBCySz YCU9CLcdLlN8kr+wgh8kbIze6hu/166DSPFJ/uwbOz73PiCtny3MOHzRwfAU/7xefVysrzfTyUW0 upjMPrD5ZDFfrSfz2dVqvd4soml09Wu07d6w67qdDLWMZ0srYCOaPtie/O1Jl+LRIdDvRhpoQ1mO QRA7/FdkvwEAAP//AwBQSwMEFAAGAAgAAAAhAO0FtNR/DgAA1k4AABgAAAB4bC93b3Jrc2hlZXRz L3NoZWV0MS54bWycXE1z47gRvacq/0Gl+1oCRH25xrO1BjHJHlKVyubjrJHpsWply5E0M7v59UET ELpf04LJvczYeM1Gv0ajH0hT+vDjb8/70bfmeNodXu7G5mY6HjUv28PD7uXL3fhf//z0w2o8Op03 Lw+b/eGluRv/3pzGP378858+fD8cfz09Nc15FDy8nO7GT+fz6+1kcto+Nc+b083htXkJyOPh+Lw5 h1+PXyan12OzeWgvet5P7HS6mDxvdi/j6OH22MfH4fFxt23qw/brc/Nyjk6OzX5zDvGfnnavp4u3 520fd8+b469fX3/YHp5fg4vPu/3u/HvrdDx63t7+/OXlcNx83gfev5lqs734bn/puH/ebY+H0+Hx fBPcTWKgXc7ryXoSPH388LALDCjto2PzeDf+ydz+xUzn48nHD22G/r1rvp/Ez6Pz5vMvzb7ZnpuH sFDjES3A58PhVzL8OQxNg89Ta0A+N9vz7lvjmv3+buzNLCzif9tp6OcwxSTPIX++zPepXbS/H0cP zePm6/78j8P3vza7L0/nMPE8JIFycfvwe92ctmERwtQ3tg18e9gHF+Hf0fOOqikkcfNbDHb3cH4K P5mb1XxeLVbL4OZzczp/2pHP8Wj79XQ+PP8nWVGE2YtNXsL/3xNe3djV3MwXYda+XqrkJfyfvMzC xYVpA9oGH/5PF1Trm8rOlytD0xauXKQrl/lKM+tNexJz2C5PvTlvPn44Hr6PwtYISTq9bmijmdvg +e01CGkj25/IuL0kZPcU6uLbx1BaHybfwmJvk819sBHoAlGHaIVoDejaIOrj7KHmhP8l2nySHmxl Ef0LorOMTkIyckZCQciMUHVWYWXKmaGLKDNUYZSq+zCQw7SrPFMLuhJYS9CsFQUfJwKbKbsHIrQ7 ey8tGQMBmefZWhEogbUEzZqz3HL3cSIkwO6BQNhU/QmQMdbmFIO+DxZ5SRTmClgtMbNWNevjvMDH sHfgE6pI8qHKmgVhLFcWXQQLEwYyDcuZi5VVAmsJmrXauD5OhER4CwKR0IokkTIBMsaFYa9xrwSL zEhhroDVgK1Vq/FxXuTDuwn4hMYn+fRbGLoIebH3yCtYZF4KcwWslphZqxbn47zIizcZ8KJDVu8O QMZQaGEgh79S1eJKYC1Bs+b2FDtAnAgJ8K4CAushBMgYCIQBJqDKw5VAH13Z9kgjtcGE7do/o601 REQjOaQZt4m4eYuoT97eCIqEsfcymyijQqpoJAe1UuXmiqhP3t4IKqzvgKDIGjMl62OlSsiZEloD ataqR3qCw2TShTFc31CA7RFX5LZfa2ivIjqcV96hsTeQSU66Al0JrAEMdzuocvFQrtlx8SM7Ei/B rtzITZQ6yYqzllhJrVSgo+szZQXWANqpkgGf5sY141JFVqRk/VlF3ZOsuBmlfSmFU4E13blkVnaq +rwnuFNsXM4YOEmWCLxnsUWhkxtaCmOlCsSZEloTquK1U1Wf/g0jY3ibISnSqwupkIx3aiyqmyQj 1bBSdeFMCa0BtVO1dJ5gxdVYThfSINXqTyNqnKQhNVHfmDhTQmtArb7j8gR3aHCikAYpW38aUQcl DSmblaoLZ0poDaidck9qd5knWNNYsRHQsFKHQ1H12yntVaAyNJI3b6XqwxXROnmTLclOuSVFUm8Y Gcs9AkmFHiTXpicpugpJyV6m71ecLaE1oWoRrLi/TKS6RsZyLSApEtveBWfJGoWTK6Cd/J5M8pIp 0JXAGkA75X6VWMW5pXtjuSSQFd3F9mcV73nFNrJS/fWdmCuiNaBW3GsmGnEypMFqizSk/r/bm+1F //khh1R0fQPmyD6vlEZrQK3hfpVoxMmQBi830iCN7b8aZI01pme/p0dxOXSNuiJaA2oNb/ZELE6P xLhtIDES4/7EonTLMpNSL9pOG4mzJbRG1PD2TjTiZEjjyrnGks4KGtTYejxSi+os6UixX/BkiU4J rdsY8FhsDe/uRCpOiaS4T+DakOoKUuVzjY0aLclIyV/wJIlMCa3JWy5PK+5dEo04GdAQN5tIg1RX 0OgpOlGrJR0p/Us+RCU6JbS2ErWGd3miEydDOtwvgA49T5N0yqvSWoN20ghnVkXiiqhP3rr3wjPS S5Hjd4KK6ipyS9dzUNwrYm6LaI2oURf7NjTcFmbGLQtzG1ZgAA2yxtzKFRTnhUSjhNYzQI3a+x5g M+NmhQQGqfaso9o0ktdhrWu8iNaAWnGzFGscYDPjxoQESBRFIfXbrLMopbKgpDLPVTId2WeaGq2T N1gPcdOU6MQppZGZXTmE0B/M/gCpi4rnwwj54bB1Qy2iNaDWcnNJdN7Q7Bk3B1wjEkaxRu9s9iij cm2kKi86RVZC65lErRZ8D7CZcS9AAiSC/QlEyZQEQIdVKt2shNaAWt0jPMBmxoWLBEj++hOIYikJ SHVdcDNMfeoKiiGQZPUPIQqcDEEq4oLbWQqhhNYziVpxB5NqWcJG/GUPCFSDdLS1hl5PI3kzLrid RQJFtAbUWm4bkQDA1wkM0tyqo7k0wgRUDK6I1oBay40iEZCujXg+hysQmmf/EqrIGldANt+FisGR PdNTaA2otdwoEgF5sRHP5JCAUtt+YlV1VJdGOFQViyuidfIm47X6r/EeXFwvKJI0saV70olCKLZ2 JdW14haWdkYJrenasMpIRymdhwmMeNSIq/OHVJfu2lSZSdXVbys4ss9rp9E6eQM64j4lFZt0YcQj R6RDOipWp6y6FVnjbpHKWamUOrLPNDRaA2pnSvE8wEY8ZEQCg1S36qgujeQQ5/rYUERrQK04/qcV kK5Nxb0QCQxS3aqjujTCBFQSXRGtAbXi+J8ISNem4m6HBIIwDighssYSksI618eGqoTWgFpx/E8E 5MWm4h4IBOZKs/t1qPYqIEIjvBL68FFEa0CtOPJHImkyueON6IFIZ5CCzzsKTiNMQx9BimgNqBVH /URDujaiISCBQLN/Qc3JGtdBpmnO266NwZE901NoDai9dtSfK4kud83WGiOU0jznfZUiLKE1ecvx W3GWTymWsBENDVNMgti77c+jfAoxphEOolMjJbTGa68dpOekmP0jJGtMsZQ/fRZ25J3j7xQBoOKg mVIsYTPnlospHqSs846y0kgOcc6tK9VICa3hWnvtoDlX0tmz73UklPzkSFe6gRdR38aAJzMjNAAz Okgp5x2lpBGOs9OfS6iHa82cL8YISdz6Fy1ZY9FKvdIHIjcvoR5QM+c9CREulNaVO1drDRHSCOeQ J4lVWUQ9oFdzuFDyRVX5/h892qswUqk1+p1oR/aZh0Z98iaVwgghwYyS/vRe8wVZU5w8u9ra92SS Q1OgK4EewPA+fn7DCQMOCjEgYLLGgNW91/1CSo4CXQn0AF4PeJBYLS5ixUlUtyX3ZJIzrEBXAj2A RnRlzHAQiAEZJmvMsP7j9P0CJEffpRRRj6h4Lo0xD5KrxUWuOI/6D7b3ZJOzrFFXRD2ic14jjPkN AevRKjoCtpACttQCVkQ9oWH15J414ukzxjtIwBYdAaORnNEla1BqviXUw7VmceXQslAC1u9I0F6F zVdK1bIjEyXUJ2+YUV4UyOhykJy11hAnjXBG1TnQFVEPqBEPmzFCJWdlwV2SNUYIUsEtPa452XP8 CvWAGvE0GSMkSeotYEuyxgjlSi15q6YIS6gnbzl+s+AFwAgHKdbyolj5L1w0kmdZ6e55DcUQBmnQ 8qJBHIKUnBXvvpSkEurJWw7fiEfSGOEg0aEP/KlllBKz1OcOss8xaNQDahZ8MUY4SGKWF4nhHEpB WXUKrYR68pbjN+IdGIzwDUGhtxPe2bQdQVlKQTH63WZXhj3BHUlhuhjxIElZdiSFRnJelvrwVkQ9 oEa8u4IRKkl5J5dkje1FioXRr1S75TUYglgN0onWGoKgkZwm/Vd7dw3FEJQQ9JPWVUcQaCSHop85 uyLqkzdouuKVCow3WPWXhRVZY8rkLPrRsiN7ZqGOMh5Qs+R2iREOkoVVRxZohGPQh5Qi6gE14syI EZIO9JbWFVljDmXn1w+FHdlz/KydraZ4QI04LWKEg1Rj1VENGuEY1AHEFVEP6PUISQdEDnvuG7oK cykVQDzYjQq8KqGe0OBN1qwRp1rMqNKQcr9bdbSDRjijuiMXUQ+oWXJJYISDNGPV0QwayRHqd35c EfWAmiUXDEaoNKPnmne0YwXiwJOlNS+hnq7trPmVk816kLy01lCbNJIzqt81dEXUK5QLBjK6VupT rsrWGiOUqqNfI3Rkz/FzCLETISruEDBCUhCxz9+JkKwxQtidfFyKa72+gmIIgwRl3REUGuE06M/i uTLsERa3KRijkpR+W2PdkRYaybEKhU3pKqE+eYOUinsajFcJTM94O0KzlkKjP9vtiqgnVG9l8XcK jJdaff8yjMIA5a8OM/drKS368wCuiHpEV+waYx4kOeuO5NBIrgWjPxnryrBHeMXnKIxxkOisO6JD IzlG/eUYroh6QI34SD5GSA2//8pHeYCVZ+ppF4HAKNSvAb32ib2wHBhWvw0UL4MG2Q5xClWXdmU4 fIqe4lBnoGv3DmYa8tI/l9FcBSszK149iZltr8hcNByClVcb8dl8WPFwZz4sTDKnMLkS9WdI7luf OTINhyxD1+QTWssrBA6w+Py+CnyQUoW75hR4fpbSDuUwxbtJl/xKKdNwCFPCRjyLUWEqsSprupl2 VKodymHqbyQI2ZQ6peEQpoSN+OSBClNp1HthdsSJviiMa0K8Z3TJZgkOYUrYdDpB/HKw+O1Tr5sv zd82xy+7l9No3zyG1ExvQvc+xm8Da38+H17b0eD08+Ecvsbr8ttT+La3JnzH0vQmrN7j4XC+/BKq gvz+0py/vo4Ox134ErH2C9zuxvvwTXOn7ea1CR8VDsD/DgHZ16+74GRMX1N33m359+Pt7uFufPz5 oX1RZJK/ke7j/wEAAP//AwBQSwMEFAAGAAgAAAAhAJPHj4RFAQAAWwIAABEACAFkb2NQcm9wcy9j b3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAISSX0vDMBTF3wW/Q8l7 m/7RsYW2Ax17ciBYUXwLyd0WbNKQxHX79qbtVisThLzknpPfPfeSfHmUdXAAY0WjCpREMQpAsYYL tSvQa7UO5yiwjipO60ZBgU5g0bK8vcmZJqwx8GwaDcYJsIEnKUuYLtDeOU0wtmwPktrIO5QXt42R 1Pmr2WFN2SfdAU7jeIYlOMqpo7gDhnokojOSsxGpv0zdAzjDUIME5SxOogT/eB0Yaf980CsTpxTu pP1M57hTNmeDOLqPVozGtm2jNutj+PwJft88vfSjhkJ1u2KAypwzwgxQ15hyRQ+C53hS6bZXU+s2 ftFbAfzhdDFdC57UBx9wwAMfhQzBL8pb9riq1qhM4yQN41mYplUck/vUn4+u76/3XbShIM/d/yXO w3RRJQm5W5AsmxAvgDLHV9+h/AYAAP//AwBQSwMEFAAGAAgAAAAhAFJIMl9dAQAAUAcAACcAAAB4 bC9wcmludGVyU2V0dGluZ3MvcHJpbnRlclNldHRpbmdzMS5iaW7kU81Kw0AQ/matNdZbn6DeerFU wUNPYqJCIWqp4EEQEaooqBHNQd9A8Km8+BQ+Qc/VW1lndrNNij9Ea0RwYbOzs/N9880w8XGFCDFO cMRWDZvYQIAFLKGFZba22Nfhl1NccJTEjC8qzU0/IS4H96QUCP1K5PX4nMFQyx2Y4h0yMn4XP86W 7yasshy7nM5nHpJPnVN3uu1d1LLeYu39h6pNoImgSH0n21ALylaVrStrf8arVBpJ3H9C5PUratYy WiQpYoE2ixMpZ4p0CoDkfSWbc95cBibcYeR0djb2rS24KrtfSrcyHrzKvJ+1NpUbR/oxlKtmBg9x lvq/bAl9b4SiD7W6GkSasw9wjUvOfo5jNLGIBk/0De+8y0O9JLEJH/fe1rqXl+APxj3ijlWlHZ1U 4m/NwKQ6i8TzjOqf62iRSv8nt/y/frcdNlt+Yy0MR00Q//r2TvAKAAD//wMAUEsDBBQABgAIAAAA IQA8AjD+gQEAAP4CAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAJySQW/bMAyF7wP6HwzdEzltMAyBrKJoWvTQYgGSdmdVpmMhimSIrJHs14+2 kcXZeuqN5Ht4+kRJ3R72PmshoYuhELNpLjIINpYubAvxunmc/BAZkgml8TFAIY6A4lZffVOrFBtI 5AAzjghYiJqoWUiJtoa9wSnLgZUqpr0hbtNWxqpyFpbRfuwhkLzO8+8SDgShhHLS/A0UQ+Kipa+G ltF2fPi2OTYMrNVd03hnDfEt9YuzKWKsKHs4WPBKjkXFdGuwH8nRUedKjlu1tsbDPQfryngEJc8D 9QSmW9rKuIRatbRowVJMGbrfvLZrkb0bhA6nEK1JzgRirM42NH3tG6Skf8W0wxqAUEk2DMO+HHvH tZvrWW/g4tLYBQwgLFwibhx5wJ/VyiT6hHg2Ju4ZBt4BZ93xDWeO+for80n/ZD+7sMPXZhOXhuC0 u8uhWtcmQcnrPunngXritSXfhdzXJmyhPHn+F7qXfhu+s57Np/lNzo84mil5/rj6DwAAAP//AwBQ SwECLQAUAAYACAAAACEAQTeCz3IBAAAEBQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbFBLAQItABQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAAAAAAAAAAAAAAAAKsDAABfcmVs cy8ucmVsc1BLAQItABQABgAIAAAAIQCBPpSX9AAAALoCAAAaAAAAAAAAAAAAAAAAANEGAAB4bC9f cmVscy93b3JrYm9vay54bWwucmVsc1BLAQItABQABgAIAAAAIQBGkUHdRwEAABQCAAAPAAAAAAAA AAAAAAAAAAUJAAB4bC93b3JrYm9vay54bWxQSwECLQAUAAYACAAAACEAMaJC1eAIAADiJAAAFAAA AAAAAAAAAAAAAAB5CgAAeGwvc2hhcmVkU3RyaW5ncy54bWxQSwECLQAUAAYACAAAACEAO20yS8EA AABCAQAAIwAAAAAAAAAAAAAAAACLEwAAeGwvd29ya3NoZWV0cy9fcmVscy9zaGVldDEueG1sLnJl bHNQSwECLQAUAAYACAAAACEA+2KlbZQGAACnGwAAEwAAAAAAAAAAAAAAAACNFAAAeGwvdGhlbWUv dGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQBRvM0MoAIAAHEGAAANAAAAAAAAAAAAAAAAAFIbAAB4 bC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAO0FtNR/DgAA1k4AABgAAAAAAAAAAAAAAAAAHR4A AHhsL3dvcmtzaGVldHMvc2hlZXQxLnhtbFBLAQItABQABgAIAAAAIQCTx4+ERQEAAFsCAAARAAAA AAAAAAAAAAAAANIsAABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQBSSDJfXQEAAFAH AAAnAAAAAAAAAAAAAAAAAE4vAAB4bC9wcmludGVyU2V0dGluZ3MvcHJpbnRlclNldHRpbmdzMS5i aW5QSwECLQAUAAYACAAAACEAPAIw/oEBAAD+AgAAEAAAAAAAAAAAAAAAAADwMAAAZG9jUHJvcHMv YXBwLnhtbFBLBQYAAAAADAAMACYDAACnMwAAAAA= ------=_Part_1217301_2206622.1346241286457-- From david.oliva@verizon.net Wed Aug 29 05:01:45 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E5611E80E2 for ; Wed, 29 Aug 2012 05:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.83 X-Spam-Level: X-Spam-Status: No, score=0.83 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_50=0.001, 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 cG8qCiRoIpqV for ; Wed, 29 Aug 2012 05:01:42 -0700 (PDT) Received: from vms173015pub.verizon.net (vms173015pub.verizon.net [206.46.173.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF4011E80E0 for ; Wed, 29 Aug 2012 05:01:42 -0700 (PDT) Received: from vms170025pub.verizon.net ([unknown] [192.168.1.3]) by vms173015.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M9I001J9MQFI8W0@vms173015.mailsrvcs.net> for sacm@ietf.org; Wed, 29 Aug 2012 07:01:27 -0500 (CDT) Received: from 96.241.55.45 ([96.241.55.45]) by vms170025 (Verizon Webmail) with HTTP; Wed, 29 Aug 2012 07:01:27 -0500 (CDT) Date: Wed, 29 Aug 2012 07:01:27 -0500 (CDT) From: david.oliva@verizon.net To: sacm@ietf.org Message-id: <15630089.1217691.1346241687199.JavaMail.root@vms170025> 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.55.45] Subject: [sacm] Perception 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, 29 Aug 2012 12:01:45 -0000
&nb= sp;
 
 

Hello all

=

After David Solin=E2=80=99s Google query abo= ut the term monitoring, it oc= curred to me to run a couple of academic queries on my university=E2=80=99s= research database.

A large number of hits as= sociate monitoring with employee monitoring, ethical monitoring, telephone-= use employee monitoring, performance monitoring, computer behavior monitori= ng, etc.

Perhaps it is not a bad idea to diss= ociate the SACM effort from the perceived impression that we are building t= ools for a =E2=80=9CBig Brother=E2=80=9D kind of society.

=

 

David Oliva


 
On 08/27/12, David Solin<david@joval.org> wrote:
 
My reason for not piping up earlier is that I don't personally = care.  It's a rose by any other name, right?  The name doesn't of= fend me.  But clearly the name is causing indigestion.  I believe= that the reason is what I have described -- that companies selling billion= s of dollars of products, and analysts from which customers who buy those p= roducts seek guidance, have together trained the marketplace to respond to = certain keywords in certain ways.

In our case, I think it's the geru= nd (verb functioning as a noun) -- monitoring -- that is causing angst.&nbs= p; When people hear the word monitoring they have been conditioned to expec= t to see a solution that processes certain types of events.  Then adje= ctive continuous takes on a real-time connotation, that has little to do wi= th SCAP.

I believe that what SCAP standards address is the complianc= e market, because the standards let you make assertions about the configura= tion state of an environment.  So I would make compliance our noun.&nb= sp; The adjective we pick is just additional branding.  Do we want to = be pigeon-holed into security?  If so, we could call it security compl= iance.  Do we want it to seem timely and all-encompassing?  Then = we should keep the adjective continuous.

Google "continuous monitori= ng" (~7 million results), and you'll see why people who have spent a long t= ime working with the US government think it's a good fit for what we're tal= king about.

Google "continuous compliance" (~48 million results), an= d you'll see why people who have spent a long time working with commercial = enterprise software think it's a good fit for what we're talking about.&nbs= p; You'll also notice a lot of the same links from the first list.

A= nd that's why I think "continuous compliance" is a better fit.  It als= o has the benefit of being in current use by vendors and analysts, and so t= he marketplace wouldn't need to be trained to understand it.

However= , Kathleen's suggestion of compliance monitoring is also quite descriptive,= and I believe differentiates itself sufficiently from the unadorned word "= monitoring" that it could also probably work just fine.

Regards.
= --David Solin

On 8/27/2012 12:45 PM, Mo= riarty, Kathleen wrote:

Would Compliance Monitoring work?

 

= Thanks,

Kathleen<= /P>

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Dorian Coug= ias
Sent: Monday, August 27, 2012 1:35 PM
To: david.oliva@verizon.net
Cc: sacm@ietf.org
Subject: Re: [sacm] = Continuous Compliance in lieu of Continuous Monitoring

 

I don't think the cont= roversy is over monitoring, I think the controversy is over "continuous".

 

So whether to call it monitoring or compliance i= sn't the case.

 

 

Dorian J. Coug= ias

Compliance Scientist

Unified Compliance Framework

 


---- On Sun, = 26 Aug 2012 11:54:27 -0700 <d= avid.oliva@verizon.net> wrote ----

 

To all:

 

I have followed the discussion about the= "continuous monitoring" term and am surprised about the amount of controve= rsy is has caused.

Perhaps r= eplacing it with  the expression "Contiinuous Compliance" does not gen= erate as much debate.

 =

David Oliva

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

 



___________=
____________________________________sacm mailing listsacm@ietf.orghttps://www.ietf.org/mail=
man/listinfo/sacm


= --

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



_____________________= __________________________
sacm mailing list
sacm@ietf.orghttps://www.ietf.org/mailman/listinfo/sacm

From amontville@tripwire.com Wed Aug 29 05:08: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 A119121F8616 for ; Wed, 29 Aug 2012 05:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.026 X-Spam-Level: X-Spam-Status: No, score=-3.026 tagged_above=-999 required=5 tests=[AWL=-1.286, BAYES_20=-0.74, 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 KmmcAQae6FU6 for ; Wed, 29 Aug 2012 05:08:17 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE7121F8567 for ; Wed, 29 Aug 2012 05:08:16 -0700 (PDT) Received: from mail142-co1-R.bigfish.com (10.243.78.237) by CO1EHSOBE007.bigfish.com (10.243.66.70) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Aug 2012 12:08:16 +0000 Received: from mail142-co1 (localhost [127.0.0.1]) by mail142-co1-R.bigfish.com (Postfix) with ESMTP id 3CE1C78010F for ; Wed, 29 Aug 2012 12:08:16 +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: -5 X-BigFish: VPS-5(zzbb2dI98dI9371I1432I1447Izz1202hzz8275ch8275dhz2dh2a8h668h839he5bhf0ah107ah1155h) Received: from mail142-co1 (localhost.localdomain [127.0.0.1]) by mail142-co1 (MessageSwitch) id 134624209552930_6823; Wed, 29 Aug 2012 12:08:15 +0000 (UTC) Received: from CO1EHSMHS026.bigfish.com (unknown [10.243.78.253]) by mail142-co1.bigfish.com (Postfix) with ESMTP id 09B44BC004A for ; Wed, 29 Aug 2012 12:08:15 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CO1EHSMHS026.bigfish.com (10.243.66.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Aug 2012 12:08:12 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id C409E2321202 for ; Wed, 29 Aug 2012 05:06:10 -0700 (PDT) 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 3045623211F9; Wed, 29 Aug 2012 05:06:10 -0700 (PDT) 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, 29 Aug 2012 05:10:43 -0700 Received: from PDXMB03.tripwire.com ([fe80::284f:fde0:d82f:4223]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Wed, 29 Aug 2012 05:08:10 -0700 From: Adam Montville To: "david.oliva@verizon.net" , "sacm@ietf.org" Thread-Topic: [sacm] Perception of the term "Monitoring" Thread-Index: AQHNhd4Xoon6SrAqlUaqsTpHSWMdCZdwsiyA Date: Wed, 29 Aug 2012 12:08:10 +0000 Message-ID: In-Reply-To: <15630089.1217691.1346241687199.JavaMail.root@vms170025> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4ECA2E9390D540449F9B624FCB80609A@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: 2ca31353-6747-480f-98d2-bfc783ff7e39 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: "Adam W. Montville" Subject: Re: [sacm] Perception 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, 29 Aug 2012 12:08:17 -0000 Responding on vacation - copying a personal address for off-thread contact, if needed. Remaining comments inline. On 8/29/12 5:01 AM, "david.oliva@verizon.net" wrote: >=20 >=20 >=20 > >A large number of hits associate monitoring with employee monitoring, >ethical monitoring, telephone-use employee monitoring, performance >monitoring, computer behavior monitoring, > etc. >Perhaps it is not a bad idea to dissociate the SACM effort from the >perceived impression that we are building tools for a =B3Big Brother=B2 ki= nd >of society. Thanks for the additional insight, David - I think it bolsters the case nicely. >=20 >David Oliva > > >=20 >On 08/27/12,=20 >David Solin wrote: > > >Google "continuous monitoring" (~7 million results), and you'll see why >people who have spent a long time working with the US government think >it's a good fit for what we're talking about. > >Google "continuous compliance" (~48 million results), and you'll see why >people who have spent a long time working with commercial enterprise >software think it's a good fit for what we're talking about. You'll also >notice a lot of the same links from the first > list. > >And that's why I think "continuous compliance" is a better fit. It also >has the benefit of being in current use by vendors and analysts, and so >the marketplace wouldn't need to be trained to understand it. It's the "continuous" part that matters to the effort, not the "monitoring" part.=20 To me, it's 100% acceptable to drop the term "monitoring" in favor of a replacement, and I would, in fact, prefer to do so. Others? From shanna@juniper.net Wed Aug 29 05:19:55 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FAD21F8667 for ; Wed, 29 Aug 2012 05:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 O8RGvk0L9qJm for ; Wed, 29 Aug 2012 05:19:55 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id A114621F85D5 for ; Wed, 29 Aug 2012 05:19:54 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUD4I6FAAcatwh+iMWA7K4SFDw1jQSpGP@postini.com; Wed, 29 Aug 2012 05:19:55 PDT 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; Wed, 29 Aug 2012 05:19:00 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 29 Aug 2012 05:19:00 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 29 Aug 2012 08:18:59 -0400 From: Stephen Hanna To: Adam Montville , "david.oliva@verizon.net" , "sacm@ietf.org" Date: Wed, 29 Aug 2012 08:18:58 -0400 Thread-Topic: [sacm] Perception of the term "Monitoring" Thread-Index: AQHNhd4Xoon6SrAqlUaqsTpHSWMdCZdwsiyAgAABHpA= Message-ID: References: <15630089.1217691.1346241687199.JavaMail.root@vms170025> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Adam W. Montville" Subject: Re: [sacm] Perception 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, 29 Aug 2012 12:19:56 -0000 I agree. Many users are uncomfortable with the idea of having someone or something monitoring their *activities*, which is what people often think when they think of monitoring. However, there's not much problem with taking existing systems for checking security compliance of corporate-owned devices and moving that from periodic and occasional compliance assessments to continuous ones. I think that's what we're talking about here. So I think that "continuous compliance" or "continuous assessment" would be a good terms. Let's drop the word "monitoring" altogether since it is often misunderstood. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Wednesday, August 29, 2012 8:08 AM > To: david.oliva@verizon.net; sacm@ietf.org > Cc: Adam W. Montville > Subject: Re: [sacm] Perception of the term "Monitoring" >=20 > Responding on vacation - copying a personal address for off-thread > contact, if needed. >=20 > Remaining comments inline. >=20 >=20 > On 8/29/12 5:01 AM, "david.oliva@verizon.net" > wrote: >=20 > > > > > > > > > >A large number of hits associate monitoring with employee monitoring, > >ethical monitoring, telephone-use employee monitoring, performance > >monitoring, computer behavior monitoring, > > etc. > >Perhaps it is not a bad idea to dissociate the SACM effort from the > >perceived impression that we are building tools for a =B3Big Brother=B2 > kind > >of society. >=20 >=20 >=20 > Thanks for the additional insight, David - I think it bolsters the case > nicely. >=20 >=20 >=20 > > > >David Oliva > > > > > > > >On 08/27/12, > >David Solin wrote: > > > > > >Google "continuous monitoring" (~7 million results), and you'll see > why > >people who have spent a long time working with the US government think > >it's a good fit for what we're talking about. > > > >Google "continuous compliance" (~48 million results), and you'll see > why > >people who have spent a long time working with commercial enterprise > >software think it's a good fit for what we're talking about. You'll > also > >notice a lot of the same links from the first > > list. > > > >And that's why I think "continuous compliance" is a better fit. It > also > >has the benefit of being in current use by vendors and analysts, and > so > >the marketplace wouldn't need to be trained to understand it. >=20 >=20 >=20 > It's the "continuous" part that matters to the effort, not the > "monitoring" part. >=20 > To me, it's 100% acceptable to drop the term "monitoring" in favor of a > replacement, and I would, in fact, prefer to do so. >=20 > Others? >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From bakerj@mitre.org Wed Aug 29 05:28: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 1D7FC21F8653 for ; Wed, 29 Aug 2012 05:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 hURRroRP2hWG for ; Wed, 29 Aug 2012 05:28:41 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0B97E21F8652 for ; Wed, 29 Aug 2012 05:28:41 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4C2BC21B125D for ; Wed, 29 Aug 2012 08:28:40 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 254B321B1ABA for ; Wed, 29 Aug 2012 08:28:40 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.146]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0309.002; Wed, 29 Aug 2012 08:28:39 -0400 From: "Baker, Jon" To: 'sacm' Thread-Topic: [sacm] Perception of the term "Monitoring" Thread-Index: AQHNhd4SNRBf5wzVP0e2ue2eISjMgJdw9TsAgAADBQD//7+m+g== Date: Wed, 29 Aug 2012 12:28:39 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D386513020ED179@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.56] Content-Type: multipart/alternative; boundary="_000_6C1C15D8B5510B4B8FF132B10D386513020ED179IMCMBX03MITREOR_" MIME-Version: 1.0 Subject: Re: [sacm] Perception 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, 29 Aug 2012 12:28:42 -0000 --_000_6C1C15D8B5510B4B8FF132B10D386513020ED179IMCMBX03MITREOR_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHRoZXJlIGFyZSBzb21lIFVTIEdvdiBsZWFkcyB0aGF0IGFyZSBjb25zaWRlcmlu ZyB1c2luZyAiY29udGludW91cyBkaWFnbm9zdGljcyBhbmQgTWl0aWdhdGlvbnMiIGFzIGEgcmVw bGFjZW1lbnQgZm9yIGNvbnRpbnVvdXMgbW9uaXRvcmluZy4gSXQgbWlnaHQgYmUgbmljZSB0byBh bGlnbiBzYWNtIHRlcm1zLg0KDQoNCg0KU2VudCB3aXRoIEdvb2QgKHd3dy5nb29kLmNvbSkNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3RlcGhlbiBIYW5uYSBbc2hhbm5h QGp1bmlwZXIubmV0PG1haWx0bzpzaGFubmFAanVuaXBlci5uZXQ+XQ0KU2VudDogV2VkbmVzZGF5 LCBBdWd1c3QgMjksIDIwMTIgMDg6MTkgQU0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQpUbzogQWRh bSBNb250dmlsbGU7IGRhdmlkLm9saXZhQHZlcml6b24ubmV0OyBzYWNtQGlldGYub3JnDQpDYzog QWRhbSBXLiBNb250dmlsbGUNClN1YmplY3Q6IFJlOiBbc2FjbV0gUGVyY2VwdGlvbiBvZiB0aGUg dGVybSAiTW9uaXRvcmluZyINCg0KDQpJIGFncmVlLiBNYW55IHVzZXJzIGFyZSB1bmNvbWZvcnRh YmxlIHdpdGggdGhlIGlkZWEgb2YgaGF2aW5nDQpzb21lb25lIG9yIHNvbWV0aGluZyBtb25pdG9y aW5nIHRoZWlyICphY3Rpdml0aWVzKiwgd2hpY2ggaXMNCndoYXQgcGVvcGxlIG9mdGVuIHRoaW5r IHdoZW4gdGhleSB0aGluayBvZiBtb25pdG9yaW5nLg0KDQpIb3dldmVyLCB0aGVyZSdzIG5vdCBt dWNoIHByb2JsZW0gd2l0aCB0YWtpbmcgZXhpc3Rpbmcgc3lzdGVtcw0KZm9yIGNoZWNraW5nIHNl Y3VyaXR5IGNvbXBsaWFuY2Ugb2YgY29ycG9yYXRlLW93bmVkIGRldmljZXMgYW5kDQptb3Zpbmcg dGhhdCBmcm9tIHBlcmlvZGljIGFuZCBvY2Nhc2lvbmFsIGNvbXBsaWFuY2UgYXNzZXNzbWVudHMN CnRvIGNvbnRpbnVvdXMgb25lcy4gSSB0aGluayB0aGF0J3Mgd2hhdCB3ZSdyZSB0YWxraW5nIGFi b3V0IGhlcmUuDQoNClNvIEkgdGhpbmsgdGhhdCAiY29udGludW91cyBjb21wbGlhbmNlIiBvciAi Y29udGludW91cyBhc3Nlc3NtZW50Ig0Kd291bGQgYmUgYSBnb29kIHRlcm1zLiBMZXQncyBkcm9w IHRoZSB3b3JkICJtb25pdG9yaW5nIiBhbHRvZ2V0aGVyDQpzaW5jZSBpdCBpcyBvZnRlbiBtaXN1 bmRlcnN0b29kLg0KDQpUaGFua3MsDQoNClN0ZXZlDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogc2FjbS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2FjbS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gQWRhbSBNb250dmlsbGUNCj4gU2VudDogV2VkbmVz ZGF5LCBBdWd1c3QgMjksIDIwMTIgODowOCBBTQ0KPiBUbzogZGF2aWQub2xpdmFAdmVyaXpvbi5u ZXQ7IHNhY21AaWV0Zi5vcmcNCj4gQ2M6IEFkYW0gVy4gTW9udHZpbGxlDQo+IFN1YmplY3Q6IFJl OiBbc2FjbV0gUGVyY2VwdGlvbiBvZiB0aGUgdGVybSAiTW9uaXRvcmluZyINCj4NCj4gUmVzcG9u ZGluZyBvbiB2YWNhdGlvbiAtIGNvcHlpbmcgYSBwZXJzb25hbCBhZGRyZXNzIGZvciBvZmYtdGhy ZWFkDQo+IGNvbnRhY3QsIGlmIG5lZWRlZC4NCj4NCj4gUmVtYWluaW5nIGNvbW1lbnRzIGlubGlu ZS4NCj4NCj4NCj4gT24gOC8yOS8xMiA1OjAxIEFNLCAiZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQi IDxkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldD4NCj4gd3JvdGU6DQo+DQo+ID4NCj4gPg0KPiA+DQo+ ID4NCj4gPkEgbGFyZ2UgbnVtYmVyIG9mIGhpdHMgYXNzb2NpYXRlIG1vbml0b3Jpbmcgd2l0aCBl bXBsb3llZSBtb25pdG9yaW5nLA0KPiA+ZXRoaWNhbCBtb25pdG9yaW5nLCB0ZWxlcGhvbmUtdXNl IGVtcGxveWVlIG1vbml0b3JpbmcsIHBlcmZvcm1hbmNlDQo+ID5tb25pdG9yaW5nLCBjb21wdXRl ciBiZWhhdmlvciBtb25pdG9yaW5nLA0KPiA+IGV0Yy4NCj4gPlBlcmhhcHMgaXQgaXMgbm90IGEg YmFkIGlkZWEgdG8gZGlzc29jaWF0ZSB0aGUgU0FDTSBlZmZvcnQgZnJvbSB0aGUNCj4gPnBlcmNl aXZlZCBpbXByZXNzaW9uIHRoYXQgd2UgYXJlIGJ1aWxkaW5nIHRvb2xzIGZvciBhIMKzQmlnIEJy b3RoZXLCsg0KPiBraW5kDQo+ID5vZiBzb2NpZXR5Lg0KPg0KPg0KPg0KPiBUaGFua3MgZm9yIHRo ZSBhZGRpdGlvbmFsIGluc2lnaHQsIERhdmlkIC0gSSB0aGluayBpdCBib2xzdGVycyB0aGUgY2Fz ZQ0KPiBuaWNlbHkuDQo+DQo+DQo+DQo+ID4NCj4gPkRhdmlkIE9saXZhDQo+ID4NCj4gPg0KPiA+ DQo+ID5PbiAwOC8yNy8xMiwNCj4gPkRhdmlkIFNvbGluPGRhdmlkQGpvdmFsLm9yZz4gd3JvdGU6 DQo+ID4NCj4gPg0KPiA+R29vZ2xlICJjb250aW51b3VzIG1vbml0b3JpbmciICh+NyBtaWxsaW9u IHJlc3VsdHMpLCBhbmQgeW91J2xsIHNlZQ0KPiB3aHkNCj4gPnBlb3BsZSB3aG8gaGF2ZSBzcGVu dCBhIGxvbmcgdGltZSB3b3JraW5nIHdpdGggdGhlIFVTIGdvdmVybm1lbnQgdGhpbmsNCj4gPml0 J3MgYSBnb29kIGZpdCBmb3Igd2hhdCB3ZSdyZSB0YWxraW5nIGFib3V0Lg0KPiA+DQo+ID5Hb29n bGUgImNvbnRpbnVvdXMgY29tcGxpYW5jZSIgKH40OCBtaWxsaW9uIHJlc3VsdHMpLCBhbmQgeW91 J2xsIHNlZQ0KPiB3aHkNCj4gPnBlb3BsZSB3aG8gaGF2ZSBzcGVudCBhIGxvbmcgdGltZSB3b3Jr aW5nIHdpdGggY29tbWVyY2lhbCBlbnRlcnByaXNlDQo+ID5zb2Z0d2FyZSB0aGluayBpdCdzIGEg Z29vZCBmaXQgZm9yIHdoYXQgd2UncmUgdGFsa2luZyBhYm91dC4gIFlvdSdsbA0KPiBhbHNvDQo+ ID5ub3RpY2UgYSBsb3Qgb2YgdGhlIHNhbWUgbGlua3MgZnJvbSB0aGUgZmlyc3QNCj4gPiBsaXN0 Lg0KPiA+DQo+ID5BbmQgdGhhdCdzIHdoeSBJIHRoaW5rICJjb250aW51b3VzIGNvbXBsaWFuY2Ui IGlzIGEgYmV0dGVyIGZpdC4gIEl0DQo+IGFsc28NCj4gPmhhcyB0aGUgYmVuZWZpdCBvZiBiZWlu ZyBpbiBjdXJyZW50IHVzZSBieSB2ZW5kb3JzIGFuZCBhbmFseXN0cywgYW5kDQo+IHNvDQo+ID50 aGUgbWFya2V0cGxhY2Ugd291bGRuJ3QgbmVlZCB0byBiZSB0cmFpbmVkIHRvIHVuZGVyc3RhbmQg aXQuDQo+DQo+DQo+DQo+IEl0J3MgdGhlICJjb250aW51b3VzIiBwYXJ0IHRoYXQgbWF0dGVycyB0 byB0aGUgZWZmb3J0LCBub3QgdGhlDQo+ICJtb25pdG9yaW5nIiBwYXJ0Lg0KPg0KPiBUbyBtZSwg aXQncyAxMDAlIGFjY2VwdGFibGUgdG8gZHJvcCB0aGUgdGVybSAibW9uaXRvcmluZyIgaW4gZmF2 b3Igb2YgYQ0KPiByZXBsYWNlbWVudCwgYW5kIEkgd291bGQsIGluIGZhY3QsIHByZWZlciB0byBk byBzby4NCj4NCj4gT3RoZXJzPw0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBzYWNtIG1haWxpbmcgbGlzdA0KPiBzYWNtQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbQ0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNhY20gbWFpbGluZyBs aXN0DQpzYWNtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NhY20NCg== --_000_6C1C15D8B5510B4B8FF132B10D386513020ED179IMCMBX03MITREOR_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0bWw+ DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0iSFRN TCBUaWR5IGZvciBXaW5kb3dzICh2ZXJzIDI1IE1hcmNoIDIwMDkpLCBzZWUgd3d3LnczLm9yZyI+ DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1TIEV4Y2hhbmdlIFNlcnZlciB2ZXJz aW9uIDE0LjAyLjAzMDkuMDAwIj4NCjx0aXRsZT5SZTogW3NhY21dIFBlcmNlcHRpb24gb2YgdGhl IHRlcm0gJnF1b3Q7TW9uaXRvcmluZyZxdW90OzwvdGl0bGU+DQo8L2hlYWQ+DQo8Ym9keT4NCkkg YmVsaWV2ZSB0aGVyZSBhcmUgc29tZSBVUyBHb3YgbGVhZHMgdGhhdCBhcmUgY29uc2lkZXJpbmcg dXNpbmcgJnF1b3Q7Y29udGludW91cyBkaWFnbm9zdGljcyBhbmQgTWl0aWdhdGlvbnMmcXVvdDsg YXMgYSByZXBsYWNlbWVudCBmb3IgY29udGludW91cyBtb25pdG9yaW5nLiBJdCBtaWdodCBiZSBu aWNlIHRvIGFsaWduIHNhY20gdGVybXMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KU2VudCB3aXRo IEdvb2QgKHd3dy5nb29kLmNvbSk8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj4NCjxiPkZyb206Jm5ic3A7PC9iPlN0ZXBoZW4gSGFubmEgWzxhIGhyZWY9Im1h aWx0bzpzaGFubmFAanVuaXBlci5uZXQiPnNoYW5uYUBqdW5pcGVyLm5ldDwvYT5dPGJyPg0KPGI+ U2VudDombmJzcDs8L2I+V2VkbmVzZGF5LCBBdWd1c3QgMjksIDIwMTIgMDg6MTkgQU0gRWFzdGVy biBTdGFuZGFyZCBUaW1lPGJyPg0KPGI+VG86Jm5ic3A7PC9iPkFkYW0gTW9udHZpbGxlOyBkYXZp ZC5vbGl2YUB2ZXJpem9uLm5ldDsgc2FjbUBpZXRmLm9yZzxicj4NCjxiPkNjOiZuYnNwOzwvYj5B ZGFtIFcuIE1vbnR2aWxsZTxicj4NCjxiPlN1YmplY3Q6Jm5ic3A7PC9iPlJlOiBbc2FjbV0gUGVy Y2VwdGlvbiBvZiB0aGUgdGVybSAmcXVvdDtNb25pdG9yaW5nJnF1b3Q7PGJyPg0KPGJyPg0KPCEt LSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3BsYWluIGZvcm1hdCAtLT4NCjxwPjxmb250IHNpemU9IjIi PkkgYWdyZWUuIE1hbnkgdXNlcnMgYXJlIHVuY29tZm9ydGFibGUgd2l0aCB0aGUgaWRlYSBvZiBo YXZpbmc8YnI+DQpzb21lb25lIG9yIHNvbWV0aGluZyBtb25pdG9yaW5nIHRoZWlyICphY3Rpdml0 aWVzKiwgd2hpY2ggaXM8YnI+DQp3aGF0IHBlb3BsZSBvZnRlbiB0aGluayB3aGVuIHRoZXkgdGhp bmsgb2YgbW9uaXRvcmluZy48YnI+DQo8YnI+DQpIb3dldmVyLCB0aGVyZSdzIG5vdCBtdWNoIHBy b2JsZW0gd2l0aCB0YWtpbmcgZXhpc3Rpbmcgc3lzdGVtczxicj4NCmZvciBjaGVja2luZyBzZWN1 cml0eSBjb21wbGlhbmNlIG9mIGNvcnBvcmF0ZS1vd25lZCBkZXZpY2VzIGFuZDxicj4NCm1vdmlu ZyB0aGF0IGZyb20gcGVyaW9kaWMgYW5kIG9jY2FzaW9uYWwgY29tcGxpYW5jZSBhc3Nlc3NtZW50 czxicj4NCnRvIGNvbnRpbnVvdXMgb25lcy4gSSB0aGluayB0aGF0J3Mgd2hhdCB3ZSdyZSB0YWxr aW5nIGFib3V0IGhlcmUuPGJyPg0KPGJyPg0KU28gSSB0aGluayB0aGF0ICZxdW90O2NvbnRpbnVv dXMgY29tcGxpYW5jZSZxdW90OyBvciAmcXVvdDtjb250aW51b3VzIGFzc2Vzc21lbnQmcXVvdDs8 YnI+DQp3b3VsZCBiZSBhIGdvb2QgdGVybXMuIExldCdzIGRyb3AgdGhlIHdvcmQgJnF1b3Q7bW9u aXRvcmluZyZxdW90OyBhbHRvZ2V0aGVyPGJyPg0Kc2luY2UgaXQgaXMgb2Z0ZW4gbWlzdW5kZXJz dG9vZC48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KPGJyPg0KU3RldmU8YnI+DQo8YnI+DQomZ3Q7 IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBzYWNtLWJvdW5jZXNA aWV0Zi5vcmcgWzxhIGhyZWY9Im1haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpz YWNtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2Y8YnI+DQomZ3Q7IEFkYW0gTW9u dHZpbGxlPGJyPg0KJmd0OyBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyOSwgMjAxMiA4OjA4IEFN PGJyPg0KJmd0OyBUbzogZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ7IHNhY21AaWV0Zi5vcmc8YnI+ DQomZ3Q7IENjOiBBZGFtIFcuIE1vbnR2aWxsZTxicj4NCiZndDsgU3ViamVjdDogUmU6IFtzYWNt XSBQZXJjZXB0aW9uIG9mIHRoZSB0ZXJtICZxdW90O01vbml0b3JpbmcmcXVvdDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBSZXNwb25kaW5nIG9uIHZhY2F0aW9uIC0gY29weWluZyBhIHBlcnNvbmFsIGFk ZHJlc3MgZm9yIG9mZi10aHJlYWQ8YnI+DQomZ3Q7IGNvbnRhY3QsIGlmIG5lZWRlZC48YnI+DQom Z3Q7PGJyPg0KJmd0OyBSZW1haW5pbmcgY29tbWVudHMgaW5saW5lLjxicj4NCiZndDs8YnI+DQom Z3Q7PGJyPg0KJmd0OyBPbiA4LzI5LzEyIDU6MDEgQU0sICZxdW90O2RhdmlkLm9saXZhQHZlcml6 b24ubmV0JnF1b3Q7ICZsdDtkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldCZndDs8YnI+DQomZ3Q7IHdy b3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtBIGxhcmdlIG51bWJlciBvZiBoaXRzIGFz c29jaWF0ZSBtb25pdG9yaW5nIHdpdGggZW1wbG95ZWUgbW9uaXRvcmluZyw8YnI+DQomZ3Q7ICZn dDtldGhpY2FsIG1vbml0b3JpbmcsIHRlbGVwaG9uZS11c2UgZW1wbG95ZWUgbW9uaXRvcmluZywg cGVyZm9ybWFuY2U8YnI+DQomZ3Q7ICZndDttb25pdG9yaW5nLCBjb21wdXRlciBiZWhhdmlvciBt b25pdG9yaW5nLDxicj4NCiZndDsgJmd0OyBldGMuPGJyPg0KJmd0OyAmZ3Q7UGVyaGFwcyBpdCBp cyBub3QgYSBiYWQgaWRlYSB0byBkaXNzb2NpYXRlIHRoZSBTQUNNIGVmZm9ydCBmcm9tIHRoZTxi cj4NCiZndDsgJmd0O3BlcmNlaXZlZCBpbXByZXNzaW9uIHRoYXQgd2UgYXJlIGJ1aWxkaW5nIHRv b2xzIGZvciBhIMKzQmlnIEJyb3RoZXLCsjxicj4NCiZndDsga2luZDxicj4NCiZndDsgJmd0O29m IHNvY2lldHkuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3Mg Zm9yIHRoZSBhZGRpdGlvbmFsIGluc2lnaHQsIERhdmlkIC0gSSB0aGluayBpdCBib2xzdGVycyB0 aGUgY2FzZTxicj4NCiZndDsgbmljZWx5Ljxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O0RhdmlkIE9saXZhPGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7T24gMDgvMjcvMTIsPGJy Pg0KJmd0OyAmZ3Q7RGF2aWQgU29saW4mbHQ7ZGF2aWRAam92YWwub3JnJmd0OyB3cm90ZTo8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtHb29nbGUgJnF1b3Q7Y29u dGludW91cyBtb25pdG9yaW5nJnF1b3Q7ICh+NyBtaWxsaW9uIHJlc3VsdHMpLCBhbmQgeW91J2xs IHNlZTxicj4NCiZndDsgd2h5PGJyPg0KJmd0OyAmZ3Q7cGVvcGxlIHdobyBoYXZlIHNwZW50IGEg bG9uZyB0aW1lIHdvcmtpbmcgd2l0aCB0aGUgVVMgZ292ZXJubWVudCB0aGluazxicj4NCiZndDsg Jmd0O2l0J3MgYSBnb29kIGZpdCBmb3Igd2hhdCB3ZSdyZSB0YWxraW5nIGFib3V0Ljxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0O0dvb2dsZSAmcXVvdDtjb250aW51b3VzIGNvbXBsaWFuY2Um cXVvdDsgKH40OCBtaWxsaW9uIHJlc3VsdHMpLCBhbmQgeW91J2xsIHNlZTxicj4NCiZndDsgd2h5 PGJyPg0KJmd0OyAmZ3Q7cGVvcGxlIHdobyBoYXZlIHNwZW50IGEgbG9uZyB0aW1lIHdvcmtpbmcg d2l0aCBjb21tZXJjaWFsIGVudGVycHJpc2U8YnI+DQomZ3Q7ICZndDtzb2Z0d2FyZSB0aGluayBp dCdzIGEgZ29vZCBmaXQgZm9yIHdoYXQgd2UncmUgdGFsa2luZyBhYm91dC4mbmJzcDsgWW91J2xs PGJyPg0KJmd0OyBhbHNvPGJyPg0KJmd0OyAmZ3Q7bm90aWNlIGEgbG90IG9mIHRoZSBzYW1lIGxp bmtzIGZyb20gdGhlIGZpcnN0PGJyPg0KJmd0OyAmZ3Q7IGxpc3QuPGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7QW5kIHRoYXQncyB3aHkgSSB0aGluayAmcXVvdDtjb250aW51b3VzIGNvbXBs aWFuY2UmcXVvdDsgaXMgYSBiZXR0ZXIgZml0LiZuYnNwOyBJdDxicj4NCiZndDsgYWxzbzxicj4N CiZndDsgJmd0O2hhcyB0aGUgYmVuZWZpdCBvZiBiZWluZyBpbiBjdXJyZW50IHVzZSBieSB2ZW5k b3JzIGFuZCBhbmFseXN0cywgYW5kPGJyPg0KJmd0OyBzbzxicj4NCiZndDsgJmd0O3RoZSBtYXJr ZXRwbGFjZSB3b3VsZG4ndCBuZWVkIHRvIGJlIHRyYWluZWQgdG8gdW5kZXJzdGFuZCBpdC48YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEl0J3MgdGhlICZxdW90O2NvbnRp bnVvdXMmcXVvdDsgcGFydCB0aGF0IG1hdHRlcnMgdG8gdGhlIGVmZm9ydCwgbm90IHRoZTxicj4N CiZndDsgJnF1b3Q7bW9uaXRvcmluZyZxdW90OyBwYXJ0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRv IG1lLCBpdCdzIDEwMCUgYWNjZXB0YWJsZSB0byBkcm9wIHRoZSB0ZXJtICZxdW90O21vbml0b3Jp bmcmcXVvdDsgaW4gZmF2b3Igb2YgYTxicj4NCiZndDsgcmVwbGFjZW1lbnQsIGFuZCBJIHdvdWxk LCBpbiBmYWN0LCBwcmVmZXIgdG8gZG8gc28uPGJyPg0KJmd0Ozxicj4NCiZndDsgT3RoZXJzPzxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHNhY20gbWFpbGluZyBsaXN0 PGJyPg0KJmd0OyBzYWNtQGlldGYub3JnPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20iPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2FjbTwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnNhY20gbWFpbGluZyBsaXN0PGJyPg0Kc2FjbUBpZXRmLm9y Zzxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Fj bSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtPC9hPjxicj4NCjwv Zm9udD48L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6C1C15D8B5510B4B8FF132B10D386513020ED179IMCMBX03MITREOR_-- From kathleen.moriarty@emc.com Wed Aug 29 05:43: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 2BD7E21F8616 for ; Wed, 29 Aug 2012 05:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 FURXno8TdNtu for ; Wed, 29 Aug 2012 05:43:40 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1A23F21F860B for ; Wed, 29 Aug 2012 05:43:39 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q7TChVWp004757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 08:43:32 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 29 Aug 2012 08:43:14 -0400 Received: from mxhub17.corp.emc.com (mxhub17.corp.emc.com [10.254.93.46]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q7TChCn5016685; Wed, 29 Aug 2012 08:43:12 -0400 Received: from mx15a.corp.emc.com ([169.254.1.66]) by mxhub17.corp.emc.com ([10.254.93.46]) with mapi; Wed, 29 Aug 2012 08:43:12 -0400 From: "Moriarty, Kathleen" To: "Baker, Jon" , "'sacm'" Date: Wed, 29 Aug 2012 08:42:23 -0400 Thread-Topic: [sacm] Perception of the term "Monitoring" Thread-Index: AQHNhd4SNRBf5wzVP0e2ue2eISjMgJdw9TsAgAADBQD//7+m+oAAA9fc Message-ID: References: <6C1C15D8B5510B4B8FF132B10D386513020ED179@IMCMBX03.MITRE.ORG> In-Reply-To: <6C1C15D8B5510B4B8FF132B10D386513020ED179@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] Perception 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, 29 Aug 2012 12:43:41 -0000 Interesting suggestion, that could also let us keep the acronym and list in= tact with the use of a lower case d... Thanks, Kathleen ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Baker, Jon= [bakerj@mitre.org] Sent: Wednesday, August 29, 2012 8:28 AM To: 'sacm' Subject: Re: [sacm] Perception of the term "Monitoring" I believe there are some US Gov leads that are considering using "continuou= s diagnostics and Mitigations" as a replacement for continuous monitoring. = It might be nice to align sacm terms. Sent with Good (www.good.com) -----Original Message----- From: Stephen Hanna [shanna@juniper.net] Sent: Wednesday, August 29, 2012 08:19 AM Eastern Standard Time To: Adam Montville; david.oliva@verizon.net; sacm@ietf.org Cc: Adam W. Montville Subject: Re: [sacm] Perception of the term "Monitoring" I agree. Many users are uncomfortable with the idea of having someone or something monitoring their *activities*, which is what people often think when they think of monitoring. However, there's not much problem with taking existing systems for checking security compliance of corporate-owned devices and moving that from periodic and occasional compliance assessments to continuous ones. I think that's what we're talking about here. So I think that "continuous compliance" or "continuous assessment" would be a good terms. Let's drop the word "monitoring" altogether since it is often misunderstood. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Wednesday, August 29, 2012 8:08 AM > To: david.oliva@verizon.net; sacm@ietf.org > Cc: Adam W. Montville > Subject: Re: [sacm] Perception of the term "Monitoring" > > Responding on vacation - copying a personal address for off-thread > contact, if needed. > > Remaining comments inline. > > > On 8/29/12 5:01 AM, "david.oliva@verizon.net" > wrote: > > > > > > > > > > >A large number of hits associate monitoring with employee monitoring, > >ethical monitoring, telephone-use employee monitoring, performance > >monitoring, computer behavior monitoring, > > etc. > >Perhaps it is not a bad idea to dissociate the SACM effort from the > >perceived impression that we are building tools for a =B3Big Brother=B2 > kind > >of society. > > > > Thanks for the additional insight, David - I think it bolsters the case > nicely. > > > > > > >David Oliva > > > > > > > >On 08/27/12, > >David Solin wrote: > > > > > >Google "continuous monitoring" (~7 million results), and you'll see > why > >people who have spent a long time working with the US government think > >it's a good fit for what we're talking about. > > > >Google "continuous compliance" (~48 million results), and you'll see > why > >people who have spent a long time working with commercial enterprise > >software think it's a good fit for what we're talking about. You'll > also > >notice a lot of the same links from the first > > list. > > > >And that's why I think "continuous compliance" is a better fit. It > also > >has the benefit of being in current use by vendors and analysts, and > so > >the marketplace wouldn't need to be trained to understand it. > > > > It's the "continuous" part that matters to the effort, not the > "monitoring" part. > > To me, it's 100% acceptable to drop the term "monitoring" in favor of a > replacement, and I would, in fact, prefer to do so. > > Others? > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From shanna@juniper.net Wed Aug 29 05:52: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 C3B8621F8673 for ; Wed, 29 Aug 2012 05:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 vLgrapjypz75 for ; Wed, 29 Aug 2012 05:52:18 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 14CE411E808E for ; Wed, 29 Aug 2012 05:52:16 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUD4QfxcohnxaQclRdqXG15ce7WCRcWZX@postini.com; Wed, 29 Aug 2012 05:52:18 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 29 Aug 2012 05:50:29 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 29 Aug 2012 08:50:28 -0400 From: Stephen Hanna To: "Moriarty, Kathleen" , "Baker, Jon" , 'sacm' Date: Wed, 29 Aug 2012 08:50:26 -0400 Thread-Topic: [sacm] Perception of the term "Monitoring" Thread-Index: AQHNhd4SNRBf5wzVP0e2ue2eISjMgJdw9TsAgAADBQD//7+m+oAAA9fcgAABR5A= Message-ID: References: <6C1C15D8B5510B4B8FF132B10D386513020ED179@IMCMBX03.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Perception 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, 29 Aug 2012 12:52:19 -0000 I'm not sure that would be beneficial, overall. The term "security automation" has many broad definitions that far exceed the proposed charter. I'd like to see a WG name that reflects the actual scope of the charter. But we could consider Continuous Diagnostics and Mitigations for the WG/BOF name. I still like Adam's suggestion: Acceptable State/Security Enforcement and Setting Support (ASSESS). It's cute, has a good acronym, and reflects the proposed scope. But I'm sure the group will reach consensus on a good name. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Moriarty, Kathleen > Sent: Wednesday, August 29, 2012 8:42 AM > To: Baker, Jon; 'sacm' > Subject: Re: [sacm] Perception of the term "Monitoring" >=20 > Interesting suggestion, that could also let us keep the acronym and > list in tact with the use of a lower case d... >=20 > Thanks, > Kathleen > ________________________________________ > From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Baker, > Jon [bakerj@mitre.org] > Sent: Wednesday, August 29, 2012 8:28 AM > To: 'sacm' > Subject: Re: [sacm] Perception of the term "Monitoring" >=20 > I believe there are some US Gov leads that are considering using > "continuous diagnostics and Mitigations" as a replacement for > continuous monitoring. It might be nice to align sacm terms. >=20 >=20 >=20 > Sent with Good (www.good.com) >=20 >=20 > -----Original Message----- > From: Stephen Hanna [shanna@juniper.net] > Sent: Wednesday, August 29, 2012 08:19 AM Eastern Standard Time > To: Adam Montville; david.oliva@verizon.net; sacm@ietf.org > Cc: Adam W. Montville > Subject: Re: [sacm] Perception of the term "Monitoring" >=20 >=20 > I agree. Many users are uncomfortable with the idea of having > someone or something monitoring their *activities*, which is > what people often think when they think of monitoring. >=20 > However, there's not much problem with taking existing systems > for checking security compliance of corporate-owned devices and > moving that from periodic and occasional compliance assessments > to continuous ones. I think that's what we're talking about here. >=20 > So I think that "continuous compliance" or "continuous assessment" > would be a good terms. Let's drop the word "monitoring" altogether > since it is often misunderstood. >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of > > Adam Montville > > Sent: Wednesday, August 29, 2012 8:08 AM > > To: david.oliva@verizon.net; sacm@ietf.org > > Cc: Adam W. Montville > > Subject: Re: [sacm] Perception of the term "Monitoring" > > > > Responding on vacation - copying a personal address for off-thread > > contact, if needed. > > > > Remaining comments inline. > > > > > > On 8/29/12 5:01 AM, "david.oliva@verizon.net" > > > wrote: > > > > > > > > > > > > > > > > >A large number of hits associate monitoring with employee > monitoring, > > >ethical monitoring, telephone-use employee monitoring, performance > > >monitoring, computer behavior monitoring, > > > etc. > > >Perhaps it is not a bad idea to dissociate the SACM effort from the > > >perceived impression that we are building tools for a =B3Big Brother= =B2 > > kind > > >of society. > > > > > > > > Thanks for the additional insight, David - I think it bolsters the > case > > nicely. > > > > > > > > > > > >David Oliva > > > > > > > > > > > >On 08/27/12, > > >David Solin wrote: > > > > > > > > >Google "continuous monitoring" (~7 million results), and you'll see > > why > > >people who have spent a long time working with the US government > think > > >it's a good fit for what we're talking about. > > > > > >Google "continuous compliance" (~48 million results), and you'll see > > why > > >people who have spent a long time working with commercial enterprise > > >software think it's a good fit for what we're talking about. You'll > > also > > >notice a lot of the same links from the first > > > list. > > > > > >And that's why I think "continuous compliance" is a better fit. It > > also > > >has the benefit of being in current use by vendors and analysts, and > > so > > >the marketplace wouldn't need to be trained to understand it. > > > > > > > > It's the "continuous" part that matters to the effort, not the > > "monitoring" part. > > > > To me, it's 100% acceptable to drop the term "monitoring" in favor of > a > > replacement, and I would, in fact, prefer to do so. > > > > Others? > > > > > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From adam@stoicsecurity.com Wed Aug 29 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 25A5921F863F for ; Wed, 29 Aug 2012 05:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=-0.086, 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 l6gMEjamJB4d for ; Wed, 29 Aug 2012 05:53:22 -0700 (PDT) Received: from p3plsmtpa07-10.prod.phx3.secureserver.net (p3plsmtpa07-10.prod.phx3.secureserver.net [173.201.192.239]) by ietfa.amsl.com (Postfix) with SMTP id D8D6821F84C9 for ; Wed, 29 Aug 2012 05:53:21 -0700 (PDT) Received: (qmail 22114 invoked from network); 29 Aug 2012 12:53:20 -0000 Received: from unknown (50.137.24.91) by p3plsmtpa07-10.prod.phx3.secureserver.net (173.201.192.239) with ESMTP; 29 Aug 2012 12:53:20 -0000 From: Adam Montville Content-Type: multipart/alternative; boundary="Apple-Mail=_993576BA-B12C-4B93-AA57-7A4C683696B3" Message-Id: <785452FC-3D90-4376-B686-D8F36227EEBC@stoicsecurity.com> Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Date: Wed, 29 Aug 2012 05:53:18 -0700 References: <6C1C15D8B5510B4B8FF132B10D386513020ED179@IMCMBX03.MITRE.ORG> To: Jon Baker , "sacm@ietf.org" In-Reply-To: <6C1C15D8B5510B4B8FF132B10D386513020ED179@IMCMBX03.MITRE.ORG> X-Mailer: Apple Mail (2.1486) Subject: Re: [sacm] Perception 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, 29 Aug 2012 12:53:23 -0000 --Apple-Mail=_993576BA-B12C-4B93-AA57-7A4C683696B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Aug 29, 2012, at 5:28 AM, "Baker, Jon" wrote: > I believe there are some US Gov leads that are considering using = "continuous diagnostics and Mitigations" as a replacement for continuous = monitoring. It might be nice to align sacm terms. In terms of replacing the term "monitoring" with something else, this = seems good - especially when looking at the larger picture where = compliance is not the only diagnostic in which we may be interested. = However, given that we are focusing on UC1 and UC2, which are compliance = focused, and given that we have decided to wait on tackling remediation, = which is a form of mitigation, I'm not sure that the label "Continuous = Diagnostics and Mitigations" would be accurate for our present list of = proposed deliverables. Of course, by that line of reasoning, we should revisit the label = "Security Automation" as well (as I believe several others on the list = have pointed out in the past), as it reasonably implies a broader scope = than just compliance. =20 I know we would prefer a clever working group name, but do any of these = resonate with anyone? =20 Continuous Compliance - "concom" ?? Security Configuration - "seconf" ?? Security Configuration and Continuous Compliance - "SC3" ?? Security Configuration Management - "seconman" ?? (OK, "conman" isn't = great, right?) Security Configuration Management and Continuous Compliance - "scmcc" or = "seconmc" ?? Security Configuration Assessment and Compliance - "seconac" Security Configuration Diagnostics - "second" Configuration Assessment and Compliance - "cac" It's going to be difficult to find a name to please everyone, but I = think what matters more than a clever abbreviation is that the name = describes the effort as clearly as possible. Others? =20 For what it's worth, "diagnostics" is a noun with a couple of = definitions, one of which is "the practice or techniques of diagnosis." = It seems UC1 and UC2 are essentially doing this with respect to = compliance. The more I mull it over, the more I actually like "Security = Configuration Diagnostics." >=20 >=20 >=20 > Sent with Good (www.good.com) >=20 >=20 > -----Original Message----- > From: Stephen Hanna [shanna@juniper.net] > Sent: Wednesday, August 29, 2012 08:19 AM Eastern Standard Time > To: Adam Montville; david.oliva@verizon.net; sacm@ietf.org > Cc: Adam W. Montville > Subject: Re: [sacm] Perception of the term "Monitoring" >=20 > I agree. Many users are uncomfortable with the idea of having > someone or something monitoring their *activities*, which is > what people often think when they think of monitoring. >=20 > However, there's not much problem with taking existing systems > for checking security compliance of corporate-owned devices and > moving that from periodic and occasional compliance assessments > to continuous ones. I think that's what we're talking about here. >=20 > So I think that "continuous compliance" or "continuous assessment" > would be a good terms. Let's drop the word "monitoring" altogether > since it is often misunderstood. >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of > > Adam Montville > > Sent: Wednesday, August 29, 2012 8:08 AM > > To: david.oliva@verizon.net; sacm@ietf.org > > Cc: Adam W. Montville > > Subject: Re: [sacm] Perception of the term "Monitoring" > > > > Responding on vacation - copying a personal address for off-thread > > contact, if needed. > > > > Remaining comments inline. > > > > > > On 8/29/12 5:01 AM, "david.oliva@verizon.net" = > > wrote: > > > > > > > > > > > > > > > > >A large number of hits associate monitoring with employee = monitoring, > > >ethical monitoring, telephone-use employee monitoring, performance > > >monitoring, computer behavior monitoring, > > > etc. > > >Perhaps it is not a bad idea to dissociate the SACM effort from the > > >perceived impression that we are building tools for a =B3Big = Brother=B2 > > kind > > >of society. > > > > > > > > Thanks for the additional insight, David - I think it bolsters the = case > > nicely. > > > > > > > > > > > >David Oliva > > > > > > > > > > > >On 08/27/12, > > >David Solin wrote: > > > > > > > > >Google "continuous monitoring" (~7 million results), and you'll see > > why > > >people who have spent a long time working with the US government = think > > >it's a good fit for what we're talking about. > > > > > >Google "continuous compliance" (~48 million results), and you'll = see > > why > > >people who have spent a long time working with commercial = enterprise > > >software think it's a good fit for what we're talking about. = You'll > > also > > >notice a lot of the same links from the first > > > list. > > > > > >And that's why I think "continuous compliance" is a better fit. It > > also > > >has the benefit of being in current use by vendors and analysts, = and > > so > > >the marketplace wouldn't need to be trained to understand it. > > > > > > > > It's the "continuous" part that matters to the effort, not the > > "monitoring" part. > > > > To me, it's 100% acceptable to drop the term "monitoring" in favor = of a > > replacement, and I would, in fact, prefer to do so. > > > > Others? > > > > > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --Apple-Mail=_993576BA-B12C-4B93-AA57-7A4C683696B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 bakerj@mitre.org> = wrote:

Re: [sacm] Perception of the term "Monitoring"
I believe there are some US Gov leads that are considering using = "continuous diagnostics and Mitigations" as a replacement for continuous = monitoring. It might be nice to align sacm = terms.


In terms = of replacing the term "monitoring" with something else, this seems good = - especially when looking at the larger picture where compliance is not = the only diagnostic in which we may be interested.  However, given = that we are focusing on UC1 and UC2, which are compliance focused, and = given that we have decided to wait on tackling remediation, which is a = form of mitigation, I'm not sure that the label "Continuous Diagnostics = and Mitigations" would be accurate for our present list of proposed = deliverables.

Of course, by that line of = reasoning, we should revisit the label "Security Automation" as well (as = I believe several others on the list have pointed out in the past), as = it reasonably implies a broader scope than just compliance. =  

I know we would prefer a clever working = group name, but do any of these resonate with anyone? =  

Continuous Compliance - "concom" = ??
Security Configuration - "seconf" ??
Security = Configuration and Continuous Compliance - "SC3" ??
Security = Configuration Management - "seconman" ?? (OK, "conman" isn't great, = right?)
Security Configuration Management and Continuous = Compliance - "scmcc" or "seconmc" ??
Security Configuration = Assessment and Compliance - "seconac"
Security Configuration = Diagnostics - "second"
Configuration Assessment and Compliance = - "cac"

It's going to be difficult to find a = name to please everyone, but I think what matters more than a clever = abbreviation is that the name describes the effort as clearly as = possible.

Others? =  

For what it's worth, "diagnostics" is a = noun with a couple of definitions, one of which is "the practice or = techniques of diagnosis."  It seems UC1 and UC2 are essentially = doing this with respect to compliance.  The more I mull it over, = the more I actually like "Security Configuration = Diagnostics."





Sent with Good (www.good.com)


-----Original Message-----
From: Stephen Hanna [shanna@juniper.net]
Sent: Wednesday, August 29, 2012 08:19 AM Eastern Standard = Time
To: Adam Montville; david.oliva@verizon.net; sacm@ietf.org
Cc: Adam W. Montville
Subject: Re: [sacm] Perception of the term "Monitoring"

I agree. = Many users are uncomfortable with the idea of having
someone or something monitoring their *activities*, which is
what people often think when they think of monitoring.

However, there's not much problem with taking existing systems
for checking security compliance of corporate-owned devices and
moving that from periodic and occasional compliance assessments
to continuous ones. I think that's what we're talking about here.

So I think that "continuous compliance" or "continuous assessment"
would be a good terms. Let's drop the word "monitoring" altogether
since it is often misunderstood.

Thanks,

Steve

> -----Original Message-----
> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] = On Behalf Of
> Adam Montville
> Sent: Wednesday, August 29, 2012 8:08 AM
> To: david.oliva@verizon.net; sacm@ietf.org
> Cc: Adam W. Montville
> Subject: Re: [sacm] Perception of the term "Monitoring"
>
> Responding on vacation - copying a personal address for = off-thread
> contact, if needed.
>
> Remaining comments inline.
>
>
> On 8/29/12 5:01 AM, "david.oliva@verizon.net" = <david.oliva@verizon.net> > wrote:
>
> >
> >
> >
> >
> >A large number of hits associate monitoring with employee = monitoring,
> >ethical monitoring, telephone-use employee monitoring, = performance
> >monitoring, computer behavior monitoring,
> > etc.
> >Perhaps it is not a bad idea to dissociate the SACM effort from = the
> >perceived impression that we are building tools for a =B3Big = Brother=B2
> kind
> >of society.
>
>
>
> Thanks for the additional insight, David - I think it bolsters the = case
> nicely.
>
>
>
> >
> >David Oliva
> >
> >
> >
> >On 08/27/12,
> >David Solin<david@joval.org> wrote:
> >
> >
> >Google "continuous monitoring" (~7 million results), and you'll = see
> why
> >people who have spent a long time working with the US = government think
> >it's a good fit for what we're talking about.
> >
> >Google "continuous compliance" (~48 million results), and = you'll see
> why
> >people who have spent a long time working with commercial = enterprise
> >software think it's a good fit for what we're talking = about.  You'll
> also
> >notice a lot of the same links from the first
> > list.
> >
> >And that's why I think "continuous compliance" is a better = fit.  It
> also
> >has the benefit of being in current use by vendors and = analysts, and
> so
> >the marketplace wouldn't need to be trained to understand = it.
>
>
>
> It's the "continuous" part that matters to the effort, not the
> "monitoring" part.
>
> To me, it's 100% acceptable to drop the term "monitoring" in favor = of a
> replacement, and I would, in fact, prefer to do so.
>
> Others?
>
>
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.ietf.org/m= ailman/listinfo/sacm
_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/m= ailman/listinfo/sacm

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

= --Apple-Mail=_993576BA-B12C-4B93-AA57-7A4C683696B3-- From solin@farnamhallventures.com Wed Aug 29 05:56: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 44A6021F866D for ; Wed, 29 Aug 2012 05:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0d7Glnw+jK2 for ; Wed, 29 Aug 2012 05:56:10 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 93C9F21F84C9 for ; Wed, 29 Aug 2012 05:56:09 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1027592obb.31 for ; Wed, 29 Aug 2012 05:56:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type:x-gm-message-state; bh=JMrT8DKipiVYWX07AVBoIVOY5gnvScyyRUBkvoNyEjo=; b=E3pcIUwdiye82PUmwAN5oIyAUQRPRGapC7QVLHYaLcNzX5N8wE7hKRKf5F5lcQxoQA wTeN0r/kYUODftNy5lgdu+Nkv3Ynx3CQAgdtThk2b1LcRbWWtnWWh75lmhSffQx21FS4 XqPn89Po9s2pmttEqrs9tDa5pJEjDcP4X+gpDKU3c269dTY6a8G7UM96Go+AwT7W53XM CmTwyVRQGT0EeoLlN10qSbp7lGquwdL11ZWz9jL0kdeph9JIwU15Dk6HtB9MLqGO47LL 52PqSWReSu6PVtcyE6V4XlLgjB9ZYeafVMFd8VUzl5lg9g/cN/9/zM0u8zTtY+QMkwGi 4fsQ== Received: by 10.60.13.232 with SMTP id k8mr1061522oec.81.1346244968826; Wed, 29 Aug 2012 05:56:08 -0700 (PDT) Received: from [192.168.0.113] (cpe-70-123-137-202.austin.res.rr.com. [70.123.137.202]) by mx.google.com with ESMTPS id d6sm22427589obx.15.2012.08.29.05.56.05 (version=SSLv3 cipher=OTHER); Wed, 29 Aug 2012 05:56:05 -0700 (PDT) Sender: David Solin Message-ID: <503E1162.4080703@joval.org> Date: Wed, 29 Aug 2012 07:56:02 -0500 From: David Solin Organization: jOVAL User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sacm@ietf.org References: <6C1C15D8B5510B4B8FF132B10D386513020ED179@IMCMBX03.MITRE.ORG> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090005000506000800000301" X-Gm-Message-State: ALoCoQknNGNDyD1G1tzlZhXFr6QKemjtKerRRoTaQk8Hyipmy5n/yQvIeVcyU3wbYVxbWXVYrTDY Subject: Re: [sacm] Perception 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, 29 Aug 2012 12:56:11 -0000 This is a multi-part message in MIME format. --------------090005000506000800000301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit When you invent new terms for anything you're trying to introduce into the marketplace, you're swimming against the current. Also, we really aren't addressing mitigation at this point. I'm also sure the idea of continuous mitigation would raise eyebrows for anyone who works in a change-controlled environment. And, since the door has been opened ... I'm not a fan of SACM. It's too close to SCAM. I'd hate for us to introduce another contentious or unfamiliar term to keep a marginal acronym. Regards, --David Solin On 8/29/2012 7:42 AM, Moriarty, Kathleen wrote: > Interesting suggestion, that could also let us keep the acronym and list in tact with the use of a lower case d... > > Thanks, > Kathleen > ________________________________________ > From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Baker, Jon [bakerj@mitre.org] > Sent: Wednesday, August 29, 2012 8:28 AM > To: 'sacm' > Subject: Re: [sacm] Perception of the term "Monitoring" > > I believe there are some US Gov leads that are considering using "continuous diagnostics and Mitigations" as a replacement for continuous monitoring. It might be nice to align sacm terms. > > > > Sent with Good (www.good.com) > > > -----Original Message----- > From: Stephen Hanna [shanna@juniper.net] > Sent: Wednesday, August 29, 2012 08:19 AM Eastern Standard Time > To: Adam Montville; david.oliva@verizon.net; sacm@ietf.org > Cc: Adam W. Montville > Subject: Re: [sacm] Perception of the term "Monitoring" > > > I agree. Many users are uncomfortable with the idea of having > someone or something monitoring their *activities*, which is > what people often think when they think of monitoring. > > However, there's not much problem with taking existing systems > for checking security compliance of corporate-owned devices and > moving that from periodic and occasional compliance assessments > to continuous ones. I think that's what we're talking about here. > > So I think that "continuous compliance" or "continuous assessment" > would be a good terms. Let's drop the word "monitoring" altogether > since it is often misunderstood. > > Thanks, > > Steve > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Adam Montville >> Sent: Wednesday, August 29, 2012 8:08 AM >> To: david.oliva@verizon.net; sacm@ietf.org >> Cc: Adam W. Montville >> Subject: Re: [sacm] Perception of the term "Monitoring" >> >> Responding on vacation - copying a personal address for off-thread >> contact, if needed. >> >> Remaining comments inline. >> >> >> On 8/29/12 5:01 AM, "david.oliva@verizon.net" >> wrote: >> >>> >>> >>> >>> A large number of hits associate monitoring with employee monitoring, >>> ethical monitoring, telephone-use employee monitoring, performance >>> monitoring, computer behavior monitoring, >>> etc. >>> Perhaps it is not a bad idea to dissociate the SACM effort from the >>> perceived impression that we are building tools for a ³Big Brother² >> kind >>> of society. >> >> >> Thanks for the additional insight, David - I think it bolsters the case >> nicely. >> >> >> >>> David Oliva >>> >>> >>> >>> On 08/27/12, >>> David Solin wrote: >>> >>> >>> Google "continuous monitoring" (~7 million results), and you'll see >> why >>> people who have spent a long time working with the US government think >>> it's a good fit for what we're talking about. >>> >>> Google "continuous compliance" (~48 million results), and you'll see >> why >>> people who have spent a long time working with commercial enterprise >>> software think it's a good fit for what we're talking about. You'll >> also >>> notice a lot of the same links from the first >>> list. >>> >>> And that's why I think "continuous compliance" is a better fit. It >> also >>> has the benefit of being in current use by vendors and analysts, and >> so >>> the marketplace wouldn't need to be trained to understand it. >> >> >> It's the "continuous" part that matters to the effort, not the >> "monitoring" part. >> >> To me, it's 100% acceptable to drop the term "monitoring" in favor of a >> replacement, and I would, in fact, prefer to do so. >> >> Others? >> >> >> >> _______________________________________________ >> sacm mailing 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 -- jOVAL.org: OVAL implemented in Java. /Scan any machine from any machine. For free!/ Learn More | Features | Download --------------090005000506000800000301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit When you invent new terms for anything you're trying to introduce into the marketplace, you're swimming against the current.  Also, we really aren't addressing mitigation at this point.  I'm also sure the idea of continuous mitigation would raise eyebrows for anyone who works in a change-controlled environment.

And, since the door has been opened ... I'm not a fan of SACM.  It's too close to SCAM.  I'd hate for us to introduce another contentious or unfamiliar term to keep a marginal acronym.

Regards,
--David Solin


On 8/29/2012 7:42 AM, Moriarty, Kathleen wrote:
Interesting suggestion, that could also let us keep the acronym and list in tact with the use of a lower case d...

Thanks,
Kathleen
________________________________________
From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Baker, Jon [bakerj@mitre.org]
Sent: Wednesday, August 29, 2012 8:28 AM
To: 'sacm'
Subject: Re: [sacm] Perception of the term "Monitoring"

I believe there are some US Gov leads that are considering using "continuous diagnostics and Mitigations" as a replacement for continuous monitoring. It might be nice to align sacm terms.



Sent with Good (www.good.com)


-----Original Message-----
From: Stephen Hanna [shanna@juniper.net<mailto:shanna@juniper.net>]
Sent: Wednesday, August 29, 2012 08:19 AM Eastern Standard Time
To: Adam Montville; david.oliva@verizon.net; sacm@ietf.org
Cc: Adam W. Montville
Subject: Re: [sacm] Perception of the term "Monitoring"


I agree. Many users are uncomfortable with the idea of having
someone or something monitoring their *activities*, which is
what people often think when they think of monitoring.

However, there's not much problem with taking existing systems
for checking security compliance of corporate-owned devices and
moving that from periodic and occasional compliance assessments
to continuous ones. I think that's what we're talking about here.

So I think that "continuous compliance" or "continuous assessment"
would be a good terms. Let's drop the word "monitoring" altogether
since it is often misunderstood.

Thanks,

Steve


-----Original Message-----
From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of
Adam Montville
Sent: Wednesday, August 29, 2012 8:08 AM
To: david.oliva@verizon.net; sacm@ietf.org
Cc: Adam W. Montville
Subject: Re: [sacm] Perception of the term "Monitoring"

Responding on vacation - copying a personal address for off-thread
contact, if needed.

Remaining comments inline.


On 8/29/12 5:01 AM, "david.oliva@verizon.net" <david.oliva@verizon.net>
wrote:





A large number of hits associate monitoring with employee monitoring,
ethical monitoring, telephone-use employee monitoring, performance
monitoring, computer behavior monitoring,
etc.
Perhaps it is not a bad idea to dissociate the SACM effort from the
perceived impression that we are building tools for a ³Big Brother²

kind

of society.



Thanks for the additional insight, David - I think it bolsters the case
nicely.




David Oliva



On 08/27/12,
David Solin<david@joval.org> wrote:


Google "continuous monitoring" (~7 million results), and you'll see

why

people who have spent a long time working with the US government think
it's a good fit for what we're talking about.

Google "continuous compliance" (~48 million results), and you'll see

why

people who have spent a long time working with commercial enterprise
software think it's a good fit for what we're talking about.  You'll

also

notice a lot of the same links from the first
list.

And that's why I think "continuous compliance" is a better fit.  It

also

has the benefit of being in current use by vendors and analysts, and

so

the marketplace wouldn't need to be trained to understand it.



It's the "continuous" part that matters to the effort, not the
"monitoring" part.

To me, it's 100% acceptable to drop the term "monitoring" in favor of a
replacement, and I would, in fact, prefer to do so.

Others?



_______________________________________________
sacm mailing 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


--

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

--------------090005000506000800000301-- From athiasjerome@gmail.com Wed Aug 29 06:02:38 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A3021F8673 for ; Wed, 29 Aug 2012 06:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 vA3p-tvYZykS for ; Wed, 29 Aug 2012 06:02:37 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 600E321F84C9 for ; Wed, 29 Aug 2012 06:02:37 -0700 (PDT) Received: by eekb45 with SMTP id b45so225102eek.31 for ; Wed, 29 Aug 2012 06:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=paayEl9dcm1UDIbsvZAWc2zFyP7h6BryoXSC+xpYZ7g=; b=U4UMsgW51m7ZHLSdFq4GN4HenHhMyzWkiXzhvkhXYtKlULv3TWRcok8TxTbNf8D5BY i4uk2f5NEi2fK1kA/qLxN4ClSGnxv2Cz7NQ9jXVlT+BL8OYnU4LfotktvqwXFBgpDPv+ UInkHkUVLGa3+NifsVyI7kQ13d2PkFLYTeS6c8kLSDsCOGd5aizPJ4bP1o9t0DKeYVL5 nWYyUyeFH0ACw2ZtN3QXzS12PqHSR7UqaMG1FZkWOWWtrmypjIg7gSzB6ovclByM1zhx aI3jTI63BDPSH/30QnRHDPZmuYXxnOcfz6cfafVeg1Ff0vzuLjORWACRmnEWrs6TcPDm 0k5g== Received: by 10.14.182.134 with SMTP id o6mr1869094eem.26.1346245356611; Wed, 29 Aug 2012 06:02:36 -0700 (PDT) Received: from [41.251.241.201] ([41.251.241.201]) by mx.google.com with ESMTPS id l42sm69859891eep.1.2012.08.29.06.02.35 (version=SSLv3 cipher=OTHER); Wed, 29 Aug 2012 06:02:36 -0700 (PDT) Message-ID: <503E12FE.6030908@gmail.com> Date: Wed, 29 Aug 2012 13:02:54 +0000 From: Jerome Athias User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sacm@ietf.org, david.oliva@verizon.net References: <9062004.1217302.1346241286638.JavaMail.root@vms170025> In-Reply-To: <9062004.1217302.1346241286638.JavaMail.root@vms170025> Content-Type: multipart/alternative; boundary="------------070603060702020005010303" Subject: Re: [sacm] SACM in support of protecting personal and health info under ISO 27001 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 29 Aug 2012 13:02:38 -0000 This is a multi-part message in MIME format. --------------070603060702020005010303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Good job! Thanks for it Regards Jerome Athias Le 29/08/2012 11:54, david.oliva@verizon.net a écrit : > Hello all: > > The attached spreadsheet is an abstraction of SP 800-53, SP 800-122, > and SP 800-66 to show how SACM products can assist international > organizations pursuing the protection of personal and health > information.This capability can only be achieved when the SCAP/SACM > content used is tier IV (see SP 800-70), and your products (as a > minimum) display the content.More marketable still, is that your > products generate SCAP/SACM content that other (perhaps validated) > products can use. > > For instance, if a SACM configuration scanner finds a non-compliant > remote access control (AC-17) configuration issue, your product can > display the finding as a HIPAA issue (because it maps to 800-122), as > PII issue (because it maps to 800-66), or as an OSI 27001 issue > (because it maps to A.10.6.1, A.10.8.1, or others).Notice also that > SACM products may be able to later support compliance with the CobiT > and COSO models (future work). > > David Oliva > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --------------070603060702020005010303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Good job!
Thanks for it

Regards
Jerome Athias

Le 29/08/2012 11:54, david.oliva@verizon.net a écrit :
Hello all: 
 

The attached spreadsheet is an abstraction of SP 800-53, SP 800-122, and SP 800-66 to show how SACM products can assist international organizations pursuing the protection of personal and health information.  This capability can only be achieved when the SCAP/SACM content used is tier IV (see SP 800-70), and your products (as a minimum) display the content.  More marketable still,  is that your products generate SCAP/SACM content that other (perhaps validated) products can use.

For instance, if a SACM configuration scanner finds a non-compliant remote access control (AC-17) configuration issue, your product can display the finding as a HIPAA issue (because it maps to 800-122), as PII issue (because it maps to 800-66), or as an OSI 27001 issue (because it maps to A.10.6.1, A.10.8.1, or others).  Notice also that SACM products may be able to later support compliance with the CobiT and COSO models (future work).

 
David Oliva


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

--------------070603060702020005010303-- From michael.hammer@yaanatech.com Wed Aug 29 06:31: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 73FFC21F866B for ; Wed, 29 Aug 2012 06:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.654 X-Spam-Level: X-Spam-Status: No, score=-0.654 tagged_above=-999 required=5 tests=[AWL=-1.914, BAYES_00=-2.599, FRT_PROFIT1=3.858, 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 5aVpvPtpOBSg for ; Wed, 29 Aug 2012 06:31:39 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 03AF321F861C for ; Wed, 29 Aug 2012 06:31:38 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 29 Aug 2012 06:31:38 -0700 From: Michael Hammer To: "david@joval.org" , "sacm@ietf.org" Thread-Topic: [sacm] Perception of the term "Monitoring" Thread-Index: AQHNhd4SU0vemiacwEidisyPGgLpM5dw9TsAgAADBQD//7+m+oAAeS+AgAAD0AD//5NYwA== Date: Wed, 29 Aug 2012 13:31:37 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB31336F74E@ex2k10mb2.corp.yaanatech.com> References: <6C1C15D8B5510B4B8FF132B10D386513020ED179@IMCMBX03.MITRE.ORG> <503E1162.4080703@joval.org> In-Reply-To: <503E1162.4080703@joval.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.5] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0042_01CD85C9.14F6ED20" MIME-Version: 1.0 Subject: Re: [sacm] Perception 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, 29 Aug 2012 13:31:40 -0000 ------=_NextPart_000_0042_01CD85C9.14F6ED20 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0043_01CD85C9.14F6ED20" ------=_NextPart_001_0043_01CD85C9.14F6ED20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Or just refer to it as compliance management. Probably best not to get too specific to future-proof it. =20 I always get amused how these naming storms take place. And in the end someone in IESG gets the final say. You might want to ping them on magic words to avoid. That might cut down on the churn. =20 Mike =20 =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of David Solin Sent: Wednesday, August 29, 2012 8:56 AM To: sacm@ietf.org Subject: Re: [sacm] Perception of the term "Monitoring" =20 When you invent new terms for anything you're trying to introduce into = the marketplace, you're swimming against the current. Also, we really = aren't addressing mitigation at this point. I'm also sure the idea of = continuous mitigation would raise eyebrows for anyone who works in a = change-controlled environment. And, since the door has been opened ... I'm not a fan of SACM. It's too close to SCAM. I'd hate for us to introduce another contentious or unfamiliar term to keep a marginal acronym. Regards, --David Solin On 8/29/2012 7:42 AM, Moriarty, Kathleen wrote: Interesting suggestion, that could also let us keep the acronym and list = in tact with the use of a lower case d... =20 Thanks, Kathleen ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Baker, = Jon [bakerj@mitre.org] Sent: Wednesday, August 29, 2012 8:28 AM To: 'sacm' Subject: Re: [sacm] Perception of the term "Monitoring" =20 I believe there are some US Gov leads that are considering using = "continuous diagnostics and Mitigations" as a replacement for continuous monitoring. = It might be nice to align sacm terms. =20 =20 =20 Sent with Good (www.good.com) =20 =20 -----Original Message----- From: Stephen Hanna [shanna@juniper.net ] Sent: Wednesday, August 29, 2012 08:19 AM Eastern Standard Time To: Adam Montville; david.oliva@verizon.net; sacm@ietf.org Cc: Adam W. Montville Subject: Re: [sacm] Perception of the term "Monitoring" =20 =20 I agree. Many users are uncomfortable with the idea of having someone or something monitoring their *activities*, which is what people often think when they think of monitoring. =20 However, there's not much problem with taking existing systems for checking security compliance of corporate-owned devices and moving that from periodic and occasional compliance assessments to continuous ones. I think that's what we're talking about here. =20 So I think that "continuous compliance" or "continuous assessment" would be a good terms. Let's drop the word "monitoring" altogether since it is often misunderstood. =20 Thanks, =20 Steve =20 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville Sent: Wednesday, August 29, 2012 8:08 AM To: david.oliva@verizon.net; sacm@ietf.org Cc: Adam W. Montville Subject: Re: [sacm] Perception of the term "Monitoring" =20 Responding on vacation - copying a personal address for off-thread contact, if needed. =20 Remaining comments inline. =20 =20 On 8/29/12 5:01 AM, "david.oliva@verizon.net" wrote: =20 =20 =20 =20 =20 A large number of hits associate monitoring with employee monitoring, ethical monitoring, telephone-use employee monitoring, performance monitoring, computer behavior monitoring, etc. Perhaps it is not a bad idea to dissociate the SACM effort from the perceived impression that we are building tools for a =B3Big Brother=B2 kind of society. =20 =20 =20 Thanks for the additional insight, David - I think it bolsters the case nicely. =20 =20 =20 =20 David Oliva =20 =20 =20 On 08/27/12, David Solin wrote: =20 =20 Google "continuous monitoring" (~7 million results), and you'll see why people who have spent a long time working with the US government think it's a good fit for what we're talking about. =20 Google "continuous compliance" (~48 million results), and you'll see why people who have spent a long time working with commercial enterprise software think it's a good fit for what we're talking about. You'll also notice a lot of the same links from the first list. =20 And that's why I think "continuous compliance" is a better fit. It also has the benefit of being in current use by vendors and analysts, and so the marketplace wouldn't need to be trained to understand it. =20 =20 =20 It's the "continuous" part that matters to the effort, not the "monitoring" part. =20 To me, it's 100% acceptable to drop the term "monitoring" in favor of a replacement, and I would, in fact, prefer to do so. =20 Others? =20 =20 =20 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm =20 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm =20 --=20 jOVAL.org: OVAL implemented in Java. Scan any machine from any machine. For free! Learn More | Features | Download=20 ------=_NextPart_001_0043_01CD85C9.14F6ED20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Or just refer to it as compliance management.

Probably best not to get too specific to future-proof = it.

 

I always get amused how these naming storms take = place.

And in the end someone in IESG gets the final = say.

You might want to ping them on magic words to = avoid.

That might cut down on the churn.

 

Mike

 

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of David Solin
Sent: Wednesday, August 29, 2012 8:56 = AM
To: sacm@ietf.org
Subject: Re: [sacm] Perception = of the term "Monitoring"

 

When you = invent new terms for anything you're trying to introduce into the = marketplace, you're swimming against the current.  Also, we really = aren't addressing mitigation at this point.  I'm also sure the idea = of continuous mitigation would raise eyebrows for anyone who works in a = change-controlled environment.

And, since the door has been = opened ... I'm not a fan of SACM.  It's too close to SCAM.  = I'd hate for us to introduce another contentious or unfamiliar term to = keep a marginal acronym.

Regards,
--David Solin


On = 8/29/2012 7:42 AM, Moriarty, Kathleen = wrote:

Interesting suggestion, that could =
also let us keep the acronym and list in tact with the use of a lower =
case =
d...
 
Thanks,<=
/pre>
Kathleen
_________________________________=
_______
From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On =
Behalf Of Baker, Jon [bakerj@mitre.org]
Sent: Wednesday, August 29, 2012 8:28 AM
To: =
'sacm'
Subject: Re: [sacm] Perception of the term =
"Monitoring"
 
I=
 believe there are some US Gov leads that are considering using =
"continuous diagnostics and Mitigations" as a replacement for =
continuous monitoring. It might be nice to align sacm =
terms.
 
 =

 
Sent with Good (www.good.com)
=
 
 
-----Original =
Message-----
From: Stephen Hanna [shanna@juniper.net<mailto:shanna@juniper.net>]=

Sent: Wednesday, August 29, 2012 08:19 AM Eastern =
Standard Time
To: Adam Montville; david.oliva@verizon.net; sacm@ietf.org
Cc: =
Adam W. Montville
Subject: Re: [sacm] Perception of =
the term =
"Monitoring"
 
<=
o:p> 
I agree. Many users are uncomfortable with =
the idea of having
someone or something monitoring =
their *activities*, which is
what people often =
think when they think of =
monitoring.
 
However, =
there's not much problem with taking existing =
systems
for checking security compliance of =
corporate-owned devices and
moving that from =
periodic and occasional compliance assessments
to =
continuous ones. I think that's what we're talking about =
here.
 
So I think that =
"continuous compliance" or "continuous =
assessment"
would be a good terms. Let's drop =
the word "monitoring" altogether
since it =
is often =
misunderstood.
 
Thanks,
 
Steve
 
-----Original =
Message-----
From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] =
On Behalf Of
Adam =
Montville
Sent: Wednesday, August 29, 2012 8:08 =
AM
To: david.oliva@verizon.net; sacm@ietf.org
Cc: =
Adam W. Montville
Subject: Re: [sacm] Perception of =
the term =
"Monitoring"
 
R=
esponding on vacation - copying a personal address for =
off-thread
contact, if =
needed.
 
Remaining =
comments =
inline.
 
 
On 8/29/12 5:01 AM, "david.oliva@verizon.net&quo=
t; <david.oliva@verizon.net>
wrote:
 
 
 
 
 =
;
A large number of hits associate monitoring with =
employee monitoring,
ethical monitoring, =
telephone-use employee monitoring, =
performance
monitoring, computer behavior =
monitoring,
etc.
Perhaps it is =
not a bad idea to dissociate the SACM effort from =
the
perceived impression that we are building tools =
for a =B3Big =
Brother=B2
kind
of =
society.
 
 
 
Thanks for the =
additional insight, David - I think it bolsters the =
case
nicely.
 <=
/pre>
 
 
 
David =
Oliva
 
 <=
/pre>
 
On =
08/27/12,
David Solin<david@joval.org> =
wrote:
 
 =

Google "continuous monitoring" (~7 million =
results), and you'll =
see
why
people who have =
spent a long time working with the US government =
think
it's a good fit for what we're talking =
about.
 
Google =
"continuous compliance" (~48 million results), and you'll =
see
why
people who have =
spent a long time working with commercial =
enterprise
software think it's a good fit for what =
we're talking about.=A0 =
You'll
also
notice a lot of the =
same links from the =
first
list.
 
And that's why I think "continuous compliance" is a =
better fit.=A0 =
It
also
has the benefit of =
being in current use by vendors and analysts, =
and
so
the marketplace =
wouldn't need to be trained to understand =
it.
 
&n=
bsp;
 
It's the =
"continuous" part that matters to the effort, not =
the
"monitoring" =
part.
 
To me, it's 100% =
acceptable to drop the term "monitoring" in favor of =
a
replacement, and I would, in fact, prefer to do =
so.
 
Others?
 
 
&nb=
sp;
_______________________________________________<=
/o:p>
sacm mailing list
sacm@ietf.org
https://www.ietf.org/=
mailman/listinfo/sacm
_____________=
__________________________________
sacm mailing =
list
sacm@ietf.org
https://www.ietf.org/=
mailman/listinfo/sacm
 
_______________________________________________
sa=
cm mailing list
sacm@ietf.org
https://www.ietf.org/=
mailman/listinfo/sacm
 
-- 
jOVAL.org: OVAL implemented in Java.=

=
Scan any machine from any machine. For free!=

Learn =
More | Features | Download =
------=_NextPart_001_0043_01CD85C9.14F6ED20-- ------=_NextPart_000_0042_01CD85C9.14F6ED20 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgy OTEzMzEzNVowIwYJKoZIhvcNAQkEMRYEFFI54C4f3GlcM/+ADNYSutBEBiWLMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGApzG6I+JxY588ovhFqVGBFlN5gfTsCkYlSJ61S5DEJG2P x/W3W6TN3S22qnSvJZrv1laCPgdmymKtjXwg0gnh9ps6K0ajEUbBpW8AG5IcvBTfcZqZJFluWxe3 +HZN1hFKIQOPqevsZLKCA08uFbD+yRsAhp9ikppbT6Ws4so4ZywAAAAAAAA= ------=_NextPart_000_0042_01CD85C9.14F6ED20-- From lnunez@c3isecurity.com Wed Aug 29 06:58: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 A221111E808E for ; Wed, 29 Aug 2012 06:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599, FRT_PROFIT1=3.858, 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 4Gc2GKh3H+Fl for ; Wed, 29 Aug 2012 06:58:10 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3945C21F84A1 for ; Wed, 29 Aug 2012 06:58:10 -0700 (PDT) Received: by ggnh4 with SMTP id h4so95185ggn.31 for ; Wed, 29 Aug 2012 06:58:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Y5aupwJCDsX5wChZaVS26C40WrxhMN3geagiqm5FcNo=; b=hdfmVymWxSn8i8iDiof32jO2rVleD+TDUUGs5f1U6rvbWUT+IFaH56vnLK6RNDzyZZ N4EGzhzcK8V9nVk/gQG1pUTjgJ7alUPenPhX92tr1U1ZxanOG/jO5oHFxTnZDc/v15jz HKmuNsgp6hgfIdg0aBumeEiGtiAyLi5k9Vvn9KbjhY7zWl4aiXLa2rKbgG2FE9bMk5zh 0hOjYDLAcP3AwZLmaqGjjCMitzM6S9mJIPKsYbV05Q5QXSt/zjyZokQ/Y9/MwvfWrByx 7zTAQGnz7nd6u1WlQz38Otffvm6jCsEMORkAXq7su/1u8zCtrDN8dSQOwz89Ma4GOHaF 2KMQ== Received: by 10.236.72.97 with SMTP id s61mr1499244yhd.52.1346248689684; Wed, 29 Aug 2012 06:58:09 -0700 (PDT) Received: from [192.168.1.46] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id x3sm45405510yhd.9.2012.08.29.06.58.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Aug 2012 06:58:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_35D90346-F8BC-4285-8E83-CCEE81B9EDF6" From: Luis Nunez In-Reply-To: <00C069FD01E0324C9FFCADF539701DB31336F74E@ex2k10mb2.corp.yaanatech.com> Date: Wed, 29 Aug 2012 09:58:07 -0400 Message-Id: <2FB0493A-7FFE-4B76-B394-4C8D107AA160@c3isecurity.com> References: <6C1C15D8B5510B4B8FF132B10D386513020ED179@IMCMBX03.MITRE.ORG> <503E1162.4080703@joval.org> <00C069FD01E0324C9FFCADF539701DB31336F74E@ex2k10mb2.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlKO9m3c00qZmMCMHgfKNJNcLM7kHyO0M4vR/fmuQ4T8cTL0e01nbxPdAK3nwPUEW4sYlwc Cc: "david@joval.org" , "sacm@ietf.org" Subject: Re: [sacm] Perception 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, 29 Aug 2012 13:58:11 -0000 --Apple-Mail=_35D90346-F8BC-4285-8E83-CCEE81B9EDF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 early on we ran into issues with the term "continuous management". Not = sure if the word "management" will ignite another storm.=20 To me I don't see what the big deal is. SACM sounds fine with me. If = it causes controversy great. Getting people interested and engaged is a = good thing. -ln =20 On Aug 29, 2012, at 9:31 AM, Michael Hammer wrote: > Or just refer to it as compliance management. > Probably best not to get too specific to future-proof it. > =20 > I always get amused how these naming storms take place. > And in the end someone in IESG gets the final say. > You might want to ping them on magic words to avoid. > That might cut down on the churn. > =20 > Mike > =20 > =20 > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of David Solin > Sent: Wednesday, August 29, 2012 8:56 AM > To: sacm@ietf.org > Subject: Re: [sacm] Perception of the term "Monitoring" > =20 > When you invent new terms for anything you're trying to introduce into = the marketplace, you're swimming against the current. Also, we really = aren't addressing mitigation at this point. I'm also sure the idea of = continuous mitigation would raise eyebrows for anyone who works in a = change-controlled environment. >=20 > And, since the door has been opened ... I'm not a fan of SACM. It's = too close to SCAM. I'd hate for us to introduce another contentious or = unfamiliar term to keep a marginal acronym. >=20 > Regards, > --David Solin >=20 >=20 > On 8/29/2012 7:42 AM, Moriarty, Kathleen wrote: >=20 > Interesting suggestion, that could also let us keep the acronym and = list in tact with the use of a lower case d... > =20 > Thanks, > Kathleen > ________________________________________ > From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of = Baker, Jon [bakerj@mitre.org] > Sent: Wednesday, August 29, 2012 8:28 AM > To: 'sacm' > Subject: Re: [sacm] Perception of the term "Monitoring" > =20 > I believe there are some US Gov leads that are considering using = "continuous diagnostics and Mitigations" as a replacement for continuous = monitoring. It might be nice to align sacm terms. > =20 > =20 > =20 > Sent with Good (www.good.com) > =20 > =20 > -----Original Message----- > From: Stephen Hanna [shanna@juniper.net] > Sent: Wednesday, August 29, 2012 08:19 AM Eastern Standard Time > To: Adam Montville; david.oliva@verizon.net; sacm@ietf.org > Cc: Adam W. Montville > Subject: Re: [sacm] Perception of the term "Monitoring" > =20 > =20 > I agree. Many users are uncomfortable with the idea of having > someone or something monitoring their *activities*, which is > what people often think when they think of monitoring. > =20 > However, there's not much problem with taking existing systems > for checking security compliance of corporate-owned devices and > moving that from periodic and occasional compliance assessments > to continuous ones. I think that's what we're talking about here. > =20 > So I think that "continuous compliance" or "continuous assessment" > would be a good terms. Let's drop the word "monitoring" altogether > since it is often misunderstood. > =20 > Thanks, > =20 > Steve > =20 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of > Adam Montville > Sent: Wednesday, August 29, 2012 8:08 AM > To: david.oliva@verizon.net; sacm@ietf.org > Cc: Adam W. Montville > Subject: Re: [sacm] Perception of the term "Monitoring" > =20 > Responding on vacation - copying a personal address for off-thread > contact, if needed. > =20 > Remaining comments inline. > =20 > =20 > On 8/29/12 5:01 AM, "david.oliva@verizon.net" = > wrote: > =20 > =20 > =20 > =20 > =20 > A large number of hits associate monitoring with employee monitoring, > ethical monitoring, telephone-use employee monitoring, performance > monitoring, computer behavior monitoring, > etc. > Perhaps it is not a bad idea to dissociate the SACM effort from the > perceived impression that we are building tools for a =B3Big Brother=B2 > kind > of society. > =20 > =20 > =20 > Thanks for the additional insight, David - I think it bolsters the = case > nicely. > =20 > =20 > =20 > =20 > David Oliva > =20 > =20 > =20 > On 08/27/12, > David Solin wrote: > =20 > =20 > Google "continuous monitoring" (~7 million results), and you'll see > why > people who have spent a long time working with the US government think > it's a good fit for what we're talking about. > =20 > Google "continuous compliance" (~48 million results), and you'll see > why > people who have spent a long time working with commercial enterprise > software think it's a good fit for what we're talking about. You'll > also > notice a lot of the same links from the first > list. > =20 > And that's why I think "continuous compliance" is a better fit. It > also > has the benefit of being in current use by vendors and analysts, and > so > the marketplace wouldn't need to be trained to understand it. > =20 > =20 > =20 > It's the "continuous" part that matters to the effort, not the > "monitoring" part. > =20 > To me, it's 100% acceptable to drop the term "monitoring" in favor of = a > replacement, and I would, in fact, prefer to do so. > =20 > Others? > =20 > =20 > =20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > =20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > =20 >=20 > -- > jOVAL.org: OVAL implemented in Java. > Scan any machine from any machine. For free! > Learn More | Features | Download >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --Apple-Mail=_35D90346-F8BC-4285-8E83-CCEE81B9EDF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 early on we ran into issues with the term = "continuous management".  Not sure if the word "management" will = ignite another storm. 

To me I don't see what = the big deal is.  SACM sounds fine with me.  If it causes = controversy great.  Getting people interested and engaged is a good = thing.


-ln
 
On Aug 29, 2012, at 9:31 AM, Michael Hammer wrote:

Or just refer to it as = compliance management.
Probably best not to get too specific to = future-proof it.
 
I always get amused how = these naming storms take place.
And in the end someone = in IESG gets the final say.
You might want to ping = them on magic words to avoid.
That might cut down on = the churn.
 
 
 sacm-bounces@ietf.org = [mailto:sacm-bounces@ietf.org] On Behalf Of David = Solin
Sent: Wednesday, August 29, 2012 = 8:56 AM
To: sacm@ietf.org
Subject: Re: [sacm] Perception of = the term "Monitoring"
 
When you invent new terms for anything you're = trying to introduce into the marketplace, you're swimming against the = current.  Also, we really aren't addressing mitigation at this = point.  I'm also sure the idea of continuous mitigation would raise = eyebrows for anyone who works in a change-controlled = environment.

And, since the door has been opened ... I'm not a = fan of SACM.  It's too close to SCAM.  I'd hate for us to = introduce another contentious or unfamiliar term to keep a marginal = acronym.

Regards,
--David Solin


On 8/29/2012 7:42 = AM, Moriarty, Kathleen wrote:

Interesting suggestion, that could also let us keep the =
acronym and list in tact with the use of a lower case =
d...
 
Thanks,
From: bakerj@mitre.org]
Sent: Wednesday, August 29, 2012 8:28 =
AM
To: 'sacm'
Subject: Re: [sacm] Perception of the term =
"Monitoring"
I believe there are some US =
Gov leads that are considering using "continuous diagnostics and =
Mitigations" as a replacement for continuous monitoring. It might be =
nice to align sacm terms.
 
 
Sent with Good (www.good.com)
 
-----Original Message-----
From: Stephen Hanna [Sent: Wednesday, August 29, 2012 08:19 AM Eastern =
Standard Time
To: Adam Montville; david.oliva@verizon.net; sacm@ietf.org
Cc: Adam W. =
Montville
Subject: Re: [sacm] =
Perception of the term "Monitoring"
 
I agree. Many users are =
uncomfortable with the idea of having
someone or something monitoring their *activities*, =
which is
what people often think when =
they think of monitoring.
However, there's not much =
problem with taking existing systems
for checking security compliance of corporate-owned =
devices and
moving that from periodic =
and occasional compliance assessments
to continuous ones. I think that's what we're talking =
about here.
 
So I think that "continuous compliance" or "continuous =
assessment"
would be a good terms. Let's =
drop the word "monitoring" altogether
since it is often misunderstood.
 
 
Steve
-----Original =
Message-----
From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On =
Behalf Of
Adam =
Montville
Sent: Wednesday, August 29, =
2012 8:08 AM
To: david.oliva@verizon.net; sacm@ietf.org
Cc: Adam W. =
Montville
Subject: Re: [sacm] =
Perception of the term "Monitoring"
 
Responding on vacation =
- copying a personal address for off-thread
contact, if needed.
 
Remaining comments =
inline.
 
 
On 8/29/12 5:01 AM, "david.oliva@verizon.net" wrote:
 
 
 
A large number of hits associate monitoring with =
employee monitoring,
ethical monitoring, =
telephone-use employee monitoring, performance
monitoring, computer behavior =
monitoring,
etc.
Perhaps it is not a bad idea to dissociate the SACM =
effort from the
perceived impression =
that we are building tools for a =B3Big =
Brother=B2
of =
society.
 
 
Thanks for the =
additional insight, David - I think it bolsters the =
case
nicely.
 
 
David Oliva
 
 
On =
08/27/12,
David Solin<david@joval.org> wrote:
 
Google "continuous =
monitoring" (~7 million results), and you'll =
see
people who have spent a long time working =
with the US government think
it's a good =
fit for what we're talking about.
 
Google "continuous =
compliance" (~48 million results), and you'll =
see
people who have spent a long time working =
with commercial enterprise
software =
think it's a good fit for what we're talking about.  =
You'll
notice a lot of the same links from the =
first
list.
 
And that's why I think =
"continuous compliance" is a better fit.  =
It
has the benefit of being in current use =
by vendors and analysts, and
so
the marketplace wouldn't need to be =
trained to understand it.
 
 
It's the "continuous" part that matters to the effort, =
not the
"monitoring" =
part.
 
To me, it's 100% acceptable to drop the term =
"monitoring" in favor of a
 
Others?
 
 
sacm mailing list
sacm@ietf.org
sacm mailing list
sacm@ietf.org
 
sacm mailing list
sacm@ietf.org
 
--
jOVAL.org: OVAL implemented in =
Java.
Scan any machine from any machine. For free!
Learn More |  | sacm@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/sacm

= --Apple-Mail=_35D90346-F8BC-4285-8E83-CCEE81B9EDF6-- From roger.callahan@iaadvisory.com Wed Aug 29 07:01:18 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0031911E80D1 for ; Wed, 29 Aug 2012 07:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ryy5ThLeg4B for ; Wed, 29 Aug 2012 07:01:17 -0700 (PDT) Received: from mail19d.g19.rapidsite.net (mail19d.g19.rapidsite.net [204.202.242.120]) by ietfa.amsl.com (Postfix) with ESMTP id AF46411E80CC for ; Wed, 29 Aug 2012 07:01:16 -0700 (PDT) Received: from mx28.stngva01.us.mxservers.net (204.202.242.9) by mail19d.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 0-0303418875 for ; Wed, 29 Aug 2012 10:01:15 -0400 (EDT) Received: from unknown [161.58.75.77] (EHLO mxw1909.dulles19-verio.com) by va1-mx28.stngva01.us.mxservers.net (mxl_mta-3.1.0-05) with ESMTP id a391e305.2737699744.1451376.00-001.va1-mx28.stngva01.us.mxservers.net (envelope-from ); Wed, 29 Aug 2012 09:29:30 -0400 (EDT) Received: (qmail 30011 invoked from network); 29 Aug 2012 13:54:34 -0000 Received: from unknown (HELO PC1) (74.235.126.173) by with SMTP; 29 Aug 2012 13:54:34 -0000 From: "Roger Callahan" To: "'Stephen Hanna'" Date: Wed, 29 Aug 2012 09:54:34 -0400 Message-ID: <002b01cd85ed$d2acb650$780622f0$@iaadvisory.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: Ac2F7ck+oj/n/SsKShyeRcSyn4Ay3w== Content-Language: en-us X-Spam: [F=0.2000000000; S=0.200(2010122901); MH=0.500(2012082908)] X-MAIL-FROM: X-SOURCE-IP: [161.58.75.77] X-SF-Loop: 1 Cc: "'Moriarty, Kathleen'" , 'sacm' , "'Baker, Jon'" Subject: Re: [sacm] Perception 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, 29 Aug 2012 14:01:18 -0000 Steve, In looking at a version of the original draft charter and recognizing = the groups focus is "security information" , I noted the draft did have a context that went beyond security; namely,=20 " 1.Define, either by normative reference, adoption, or creation, a set = of standards that can be used for the purpose of assessing, aggregating and comparing device states against expected values, and reporting on those results in a predefined or ad hoc manner.", And =20 "3. Create relationships between existing operations management = standards to enable a comprehensive view of security automation, leveraging existing = work and implementations." My personal view is that security management needs to be integral = process and part of the configuration management process. A unique element of = the overall security management is more extensive use of analytics = associated with various information and we know general configuration management = for enterprises ( especially large ones) does require more automation of = the management challenges. In a specific new research initiatives among several Universities we = choose to categorize the overall effort under an umbrella name of = "Configuration Analytics and Automation" for Enterprise IT. =20 Versus monitoring, compliance, diagnostics, continuous, enforcement, = etc. which are all sub-processes or outcomes; and if the context is = specifically to be only "security" - the group may want to consider "Security Configuration Analytics and Automation (SCAA) as a name. Roger Callahan Information Assurance Advisory, LLC Charlotte, NC -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Wednesday, August 29, 2012 8:50 AM To: Moriarty, Kathleen; Baker, Jon; 'sacm' Subject: Re: [sacm] Perception of the term "Monitoring" I'm not sure that would be beneficial, overall. The term "security automation" has many broad definitions that far exceed the proposed = charter. I'd like to see a WG name that reflects the actual scope of the charter. = But we could consider Continuous Diagnostics and Mitigations for the WG/BOF name. I still like Adam's suggestion: Acceptable State/Security Enforcement = and Setting Support (ASSESS). It's cute, has a good acronym, and reflects = the proposed scope. But I'm sure the group will reach consensus on a good = name. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf=20 > Of Moriarty, Kathleen > Sent: Wednesday, August 29, 2012 8:42 AM > To: Baker, Jon; 'sacm' > Subject: Re: [sacm] Perception of the term "Monitoring" >=20 > Interesting suggestion, that could also let us keep the acronym and=20 > list in tact with the use of a lower case d... >=20 > Thanks, > Kathleen > ________________________________________ > From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of=20 > Baker, Jon [bakerj@mitre.org] > Sent: Wednesday, August 29, 2012 8:28 AM > To: 'sacm' > Subject: Re: [sacm] Perception of the term "Monitoring" >=20 > I believe there are some US Gov leads that are considering using=20 > "continuous diagnostics and Mitigations" as a replacement for=20 > continuous monitoring. It might be nice to align sacm terms. >=20 >=20 >=20 > Sent with Good (www.good.com) >=20 >=20 > -----Original Message----- > From: Stephen Hanna [shanna@juniper.net] > Sent: Wednesday, August 29, 2012 08:19 AM Eastern Standard Time > To: Adam Montville; david.oliva@verizon.net; sacm@ietf.org > Cc: Adam W. Montville > Subject: Re: [sacm] Perception of the term "Monitoring" >=20 >=20 > I agree. Many users are uncomfortable with the idea of having someone=20 > or something monitoring their *activities*, which is what people often = > think when they think of monitoring. >=20 > However, there's not much problem with taking existing systems for=20 > checking security compliance of corporate-owned devices and moving=20 > that from periodic and occasional compliance assessments to continuous = > ones. I think that's what we're talking about here. >=20 > So I think that "continuous compliance" or "continuous assessment" > would be a good terms. Let's drop the word "monitoring" altogether=20 > since it is often misunderstood. >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of > > Adam Montville > > Sent: Wednesday, August 29, 2012 8:08 AM > > To: david.oliva@verizon.net; sacm@ietf.org > > Cc: Adam W. Montville > > Subject: Re: [sacm] Perception of the term "Monitoring" > > > > Responding on vacation - copying a personal address for off-thread=20 > > contact, if needed. > > > > Remaining comments inline. > > > > > > On 8/29/12 5:01 AM, "david.oliva@verizon.net" > > > wrote: > > > > > > > > > > > > > > > > >A large number of hits associate monitoring with employee > monitoring, > > >ethical monitoring, telephone-use employee monitoring, performance=20 > > >monitoring, computer behavior monitoring, etc. > > >Perhaps it is not a bad idea to dissociate the SACM effort from the = > > >perceived impression that we are building tools for a =B3Big = Brother=B2 > > kind > > >of society. > > > > > > > > Thanks for the additional insight, David - I think it bolsters the > case > > nicely. > > > > > > > > > > > >David Oliva > > > > > > > > > > > >On 08/27/12, > > >David Solin wrote: > > > > > > > > >Google "continuous monitoring" (~7 million results), and you'll see > > why > > >people who have spent a long time working with the US government > think > > >it's a good fit for what we're talking about. > > > > > >Google "continuous compliance" (~48 million results), and you'll=20 > > >see > > why > > >people who have spent a long time working with commercial=20 > > >enterprise software think it's a good fit for what we're talking=20 > > >about. You'll > > also > > >notice a lot of the same links from the first list. > > > > > >And that's why I think "continuous compliance" is a better fit. It > > also > > >has the benefit of being in current use by vendors and analysts,=20 > > >and > > so > > >the marketplace wouldn't need to be trained to understand it. > > > > > > > > It's the "continuous" part that matters to the effort, not the=20 > > "monitoring" part. > > > > To me, it's 100% acceptable to drop the term "monitoring" in favor=20 > > of > a > > replacement, and I would, in fact, prefer to do so. > > > > Others? > > > > > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From michael.hammer@yaanatech.com Wed Aug 29 07:10: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 DA16321F8552 for ; Wed, 29 Aug 2012 07:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 tagged_above=-999 required=5 tests=[AWL=-1.845, BAYES_00=-2.599, FRT_PROFIT1=3.858, 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 opfpAkJVq8ss for ; Wed, 29 Aug 2012 07:10:46 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 272BF21F853A for ; Wed, 29 Aug 2012 07:10:45 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 29 Aug 2012 07:10:34 -0700 From: Michael Hammer To: "lnunez@c3isecurity.com" Thread-Topic: [sacm] Perception of the term "Monitoring" Thread-Index: AQHNhd4SU0vemiacwEidisyPGgLpM5dw9TsAgAADBQD//7+m+oAAeS+AgAAD0AD//5NYwIAAfgGA//+M6JA= Date: Wed, 29 Aug 2012 14:10:33 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB31336F81E@ex2k10mb2.corp.yaanatech.com> References: <6C1C15D8B5510B4B8FF132B10D386513020ED179@IMCMBX03.MITRE.ORG> <503E1162.4080703@joval.org> <00C069FD01E0324C9FFCADF539701DB31336F74E@ex2k10mb2.corp.yaanatech.com> <2FB0493A-7FFE-4B76-B394-4C8D107AA160@c3isecurity.com> In-Reply-To: <2FB0493A-7FFE-4B76-B394-4C8D107AA160@c3isecurity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.5] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_008C_01CD85CE.855E9D60" MIME-Version: 1.0 Cc: "david@joval.org" , "sacm@ietf.org" Subject: Re: [sacm] Perception 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, 29 Aug 2012 14:10:52 -0000 ------=_NextPart_000_008C_01CD85CE.855E9D60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_008D_01CD85CE.855E9D60" ------=_NextPart_001_008D_01CD85CE.855E9D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BTW, the reason I used those two words was to be less precise. One can read a number of things into both compliance and management. =20 You have the option of trying to be more granular or more specific. The danger I see in too much specificity is that you leave out = someone=92s favorite element. And hence a battle between whose favorites get in or don=92t. =20 My 2 cents. Now, I will avoid commenting again like the plague. J =20 Enjoy, Mike =20 From: Luis Nunez [mailto:lnunez@c3isecurity.com]=20 Sent: Wednesday, August 29, 2012 9:58 AM To: Michael Hammer Cc: david@joval.org; sacm@ietf.org Subject: Re: [sacm] Perception of the term "Monitoring" =20 early on we ran into issues with the term "continuous management". Not = sure if the word "management" will ignite another storm.=20 =20 To me I don't see what the big deal is. SACM sounds fine with me. If = it causes controversy great. Getting people interested and engaged is a = good thing. =20 =20 -ln =20 On Aug 29, 2012, at 9:31 AM, Michael Hammer wrote: Or just refer to it as compliance management. Probably best not to get too specific to future-proof it. =20 I always get amused how these naming storms take place. And in the end someone in IESG gets the final say. You might want to ping them on magic words to avoid. That might cut down on the churn. =20 Mike =20 =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of David Solin Sent: Wednesday, August 29, 2012 8:56 AM To: sacm@ietf.org Subject: Re: [sacm] Perception of the term "Monitoring" =20 When you invent new terms for anything you're trying to introduce into = the marketplace, you're swimming against the current. Also, we really = aren't addressing mitigation at this point. I'm also sure the idea of = continuous mitigation would raise eyebrows for anyone who works in a = change-controlled environment. And, since the door has been opened ... I'm not a fan of SACM. It's too close to SCAM. I'd hate for us to introduce another contentious or unfamiliar term to keep a marginal acronym. Regards, --David Solin On 8/29/2012 7:42 AM, Moriarty, Kathleen wrote: Interesting suggestion, that could also let us keep the acronym and list = in tact with the use of a lower case d... =20 Thanks, Kathleen ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Baker, = Jon [bakerj@mitre.org] Sent: Wednesday, August 29, 2012 8:28 AM To: 'sacm' Subject: Re: [sacm] Perception of the term "Monitoring" =20 I believe there are some US Gov leads that are considering using = "continuous diagnostics and Mitigations" as a replacement for continuous monitoring. = It might be nice to align sacm terms. =20 =20 =20 Sent with Good (www.good.com) =20 =20 -----Original Message----- From: Stephen Hanna [shanna@juniper.net ] Sent: Wednesday, August 29, 2012 08:19 AM Eastern Standard Time To: Adam Montville; david.oliva@verizon.net; sacm@ietf.org Cc: Adam W. Montville Subject: Re: [sacm] Perception of the term "Monitoring" =20 =20 I agree. Many users are uncomfortable with the idea of having someone or something monitoring their *activities*, which is what people often think when they think of monitoring. =20 However, there's not much problem with taking existing systems for checking security compliance of corporate-owned devices and moving that from periodic and occasional compliance assessments to continuous ones. I think that's what we're talking about here. =20 So I think that "continuous compliance" or "continuous assessment" would be a good terms. Let's drop the word "monitoring" altogether since it is often misunderstood. =20 Thanks, =20 Steve =20 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville Sent: Wednesday, August 29, 2012 8:08 AM To: david.oliva@verizon.net; sacm@ietf.org Cc: Adam W. Montville Subject: Re: [sacm] Perception of the term "Monitoring" =20 Responding on vacation - copying a personal address for off-thread contact, if needed. =20 Remaining comments inline. =20 =20 On 8/29/12 5:01 AM, "david.oliva@verizon.net" wrote: =20 =20 =20 =20 =20 A large number of hits associate monitoring with employee monitoring, ethical monitoring, telephone-use employee monitoring, performance monitoring, computer behavior monitoring, etc. Perhaps it is not a bad idea to dissociate the SACM effort from the perceived impression that we are building tools for a =B3Big Brother=B2 kind of society. =20 =20 =20 Thanks for the additional insight, David - I think it bolsters the case nicely. =20 =20 =20 =20 David Oliva =20 =20 =20 On 08/27/12, David Solin wrote: =20 =20 Google "continuous monitoring" (~7 million results), and you'll see why people who have spent a long time working with the US government think it's a good fit for what we're talking about. =20 Google "continuous compliance" (~48 million results), and you'll see why people who have spent a long time working with commercial enterprise software think it's a good fit for what we're talking about. You'll also notice a lot of the same links from the first list. =20 And that's why I think "continuous compliance" is a better fit. It also has the benefit of being in current use by vendors and analysts, and so the marketplace wouldn't need to be trained to understand it. =20 =20 =20 It's the "continuous" part that matters to the effort, not the "monitoring" part. =20 To me, it's 100% acceptable to drop the term "monitoring" in favor of a replacement, and I would, in fact, prefer to do so. =20 Others? =20 =20 =20 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm =20 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm =20 -- jOVAL.org: OVAL implemented in Java. Scan any machine from any machine. For free! Learn More | Features | Download _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm =20 ------=_NextPart_001_008D_01CD85CE.855E9D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

BTW, the reason I used those two words was to be less = precise.

One can read a number of things into both compliance and = management.

 

You have the option of trying to be more granular or more = specific.

The danger I see in too much specificity is that you leave out = someone’s favorite element.

And hence a battle between whose favorites get in or = don’t.

 

My 2 cents.=A0 Now, I will avoid commenting again like the plague.=A0 = J

 

Enjoy,

Mike

 

From:= = Luis Nunez [mailto:lnunez@c3isecurity.com]
Sent: Wednesday, = August 29, 2012 9:58 AM
To: Michael Hammer
Cc: = david@joval.org; sacm@ietf.org
Subject: Re: [sacm] Perception = of the term "Monitoring"

 

early on we = ran into issues with the term "continuous management". =  Not sure if the word "management" will ignite another = storm. 

 

To me I don't see what the big deal is.  SACM = sounds fine with me.  If it causes controversy great.  Getting = people interested and engaged is a good = thing.

 

 

-ln

 

On = Aug 29, 2012, at 9:31 AM, Michael Hammer wrote:



Or just refer to it as compliance management.

Probably best not to get too specific to future-proof it.

 

I always get amused how these naming storms take place.

And in the end someone in IESG gets the final say.

You might want to ping them on magic words to avoid.

That might cut down on the churn.

 

Mike

 

 

From:=  sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf = Of David = Solin
Sent: Wednesday, August 29, 2012 = 8:56 AM
To: sacm@ietf.org
Subject: Re: [sacm] Perception of the = term "Monitoring"

 

When you invent new terms = for anything you're trying to introduce into the marketplace, you're = swimming against the current.  Also, we really aren't addressing = mitigation at this point.  I'm also sure the idea of continuous = mitigation would raise eyebrows for anyone who works in a = change-controlled environment.

And, since the door has been = opened ... I'm not a fan of SACM.  It's too close to SCAM.  = I'd hate for us to introduce another contentious or unfamiliar term to = keep a marginal acronym.

Regards,
--David Solin


On = 8/29/2012 7:42 AM, Moriarty, Kathleen = wrote:


Interesting suggestion, that could also let us =
keep the acronym and list in tact with the use of a lower case =
d...
 
Thanks,
Kathleen
________________________________________=

From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On =
Behalf Of Baker, Jon [bakerj@mitre.org]<=
/pre>
Sent: Wednesday, August 29, 2012 =
8:28 AM
To: =
'sacm'
Subject: =
Re: [sacm] Perception of the term =
"Monitoring"
 
I believe there are some US Gov leads that are =
considering using "continuous diagnostics and Mitigations" as =
a replacement for continuous monitoring. It might be nice to align sacm =
terms.
 
 
 
Sent with Good (www.good.com)
 
 
-----Original =
Message-----
From: Stephen Hanna [shanna@juniper.net<mailto:shanna@juniper.net>]=

Sent: =
Wednesday, August 29, 2012 08:19 AM Eastern Standard =
Time
To: Adam =
Montville; david.oliva@verizon.net; sacm@ietf.org
Cc: Adam W. = Montville
Subject: Re: [sacm] Perception of the term =
"Monitoring"
 
 
I agree. Many users are uncomfortable with the =
idea of having
someone or something monitoring their =
*activities*, which is
what people often think when they think of =
monitoring.
 
However, there's not much problem with taking =
existing systems
for checking security compliance of =
corporate-owned devices and
moving that from periodic and occasional =
compliance assessments
to continuous ones. I think that's what we're =
talking about here.
 
So I think that "continuous compliance" =
or "continuous assessment"
would be a good terms. Let's drop the word =
"monitoring" altogether
since it is often =
misunderstood.
 
Thanks,
 
Steve
 
-----Original =
Message-----
From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] =
On Behalf Of
Adam Montville
Sent: Wednesday, August 29, 2012 8:08 =
AM
To: david.oliva@verizon.net; sacm@ietf.org
Cc: Adam W. = Montville
Subject: Re: [sacm] Perception of the term =
"Monitoring"
 
Responding on vacation - copying a personal =
address for off-thread
contact, if =
needed.
 
Remaining comments =
inline.
 
 
On 8/29/12 5:01 AM, "david.oliva@verizon.net&quo=
t; <david.oliva@verizon.net>
wrote:
 
 
 
 
 
A large number of hits associate monitoring with =
employee monitoring,
ethical monitoring, telephone-use employee =
monitoring, performance
monitoring, computer behavior =
monitoring,
etc.
Perhaps it is not a bad idea to dissociate the =
SACM effort from the
perceived impression that we are building tools =
for a =B3Big Brother=B2
kind
of =
society.
 
 
 
Thanks for the additional insight, David - I think =
it bolsters the case
nicely.
 
 
 
 
David Oliva
 
 
 
On 08/27/12,
David Solin<david@joval.org> =
wrote:
 
 
Google "continuous monitoring" (~7 =
million results), and you'll =
see
why
people who have spent a long time working with the =
US government think
it's a good fit for what we're talking =
about.
 
Google "continuous compliance" (~48 =
million results), and you'll =
see
why
people who have spent a long time working with =
commercial enterprise
software think it's a good fit for what we're =
talking about.  =
You'll
also
notice a lot of the same links from the =
first
list.
 
And that's why I think "continuous =
compliance" is a better fit.  =
It
also
has the benefit of being in current use by vendors =
and analysts, and
so
the marketplace wouldn't need to be trained to =
understand it.
 
 
 
It's the "continuous" part that matters =
to the effort, not the
"monitoring" =
part.
 
To me, it's 100% acceptable to drop the term =
"monitoring" in favor of a
replacement, and I would, in fact, prefer to do =
so.
 
Others?
 
 
 
_______________________________________________
sacm mailing =
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

 

--

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

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

 

------=_NextPart_001_008D_01CD85CE.855E9D60-- ------=_NextPart_000_008C_01CD85CE.855E9D60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgy OTE0MTAzMVowIwYJKoZIhvcNAQkEMRYEFILvKQC9PGEBnoy9zCLu7qtYsFmGMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAmI9DxbQgkQGN8yYq3Atf3LpmWdDdGypDkQQI/rXhkwN2 AIOjSzYbBTb2WRlrkhXXBeQh3JeYnSYSDzNdKdbM400K3v8OtO03EU0sGLGYFYjucMvcxjB+m8Qv d1427PswtSSHpslog2wkqyUgd3aNboio0qeP++Xe5f/14o/pyzoAAAAAAAA= ------=_NextPart_000_008C_01CD85CE.855E9D60-- From kathleen.moriarty@emc.com Wed Aug 29 07:13: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 61B0021F857A for ; Wed, 29 Aug 2012 07:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.618 X-Spam-Level: X-Spam-Status: No, score=-0.618 tagged_above=-999 required=5 tests=[AWL=-1.877, BAYES_00=-2.599, FRT_PROFIT1=3.858] 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 w0+8KJsrCCHC for ; Wed, 29 Aug 2012 07:13:49 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 357CE21F8570 for ; Wed, 29 Aug 2012 07:13:48 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q7TEDjQh011110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 10:13:46 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 29 Aug 2012 10:13:24 -0400 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q7TEDKuC030127; Wed, 29 Aug 2012 10:13:22 -0400 Received: from mx15a.corp.emc.com ([169.254.1.66]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Wed, 29 Aug 2012 10:13:20 -0400 From: "Moriarty, Kathleen" To: Michael Hammer , "lnunez@c3isecurity.com" Date: Wed, 29 Aug 2012 10:11:50 -0400 Thread-Topic: [sacm] Perception of the term "Monitoring" Thread-Index: AQHNhd4SU0vemiacwEidisyPGgLpM5dw9TsAgAADBQD//7+m+oAAeS+AgAAD0AD//5NYwIAAfgGA//+M6JAAADKkZA== Message-ID: References: <6C1C15D8B5510B4B8FF132B10D386513020ED179@IMCMBX03.MITRE.ORG> <503E1162.4080703@joval.org> <00C069FD01E0324C9FFCADF539701DB31336F74E@ex2k10mb2.corp.yaanatech.com> <2FB0493A-7FFE-4B76-B394-4C8D107AA160@c3isecurity.com>, <00C069FD01E0324C9FFCADF539701DB31336F81E@ex2k10mb2.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB31336F81E@ex2k10mb2.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "david@joval.org" , "sacm@ietf.org" Subject: Re: [sacm] Perception 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, 29 Aug 2012 14:13:50 -0000 T25lIG1vcmUgcG9pbnQgdG8gY29uc2lkZXIgaXMgdGhhdCB0aGUgV0cgbmFtZSB3aWxsIGV2ZW50 dWFsbHkgZ28gYXdheSAoYWZ0ZXIgd2UgYXJlIGRvbmUgd2l0aCB0aGUgd29yayBpdGVtcyBhbmQg YSBncm91cCBpcyBjbG9zZWQgb3V0KSBhbmQgd2hhdCB3aWxsIGxpdmUgb24gYXJlIHRoZSBuYW1l cyBvZiBzdGFuZGFyZHMgcHJvZHVjZWQgYnkgYSB3b3JraW5nIGdyb3VwLg0KDQpCZXN0IHJlZ2Fy ZHMsDQpLYXRobGVlbiANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkZyb206IHNhY20tYm91bmNlc0BpZXRmLm9yZyBbc2FjbS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgTWljaGFlbCBIYW1tZXIgW21pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb21dDQpT ZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyOSwgMjAxMiAxMDoxMCBBTQ0KVG86IGxudW5lekBjM2lz ZWN1cml0eS5jb20NCkNjOiBkYXZpZEBqb3ZhbC5vcmc7IHNhY21AaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbc2FjbV0gUGVyY2VwdGlvbiBvZiB0aGUgdGVybSAiTW9uaXRvcmluZyINCg0KQlRXLCB0 aGUgcmVhc29uIEkgdXNlZCB0aG9zZSB0d28gd29yZHMgd2FzIHRvIGJlIGxlc3MgcHJlY2lzZS4N Ck9uZSBjYW4gcmVhZCBhIG51bWJlciBvZiB0aGluZ3MgaW50byBib3RoIGNvbXBsaWFuY2UgYW5k IG1hbmFnZW1lbnQuDQoNCllvdSBoYXZlIHRoZSBvcHRpb24gb2YgdHJ5aW5nIHRvIGJlIG1vcmUg Z3JhbnVsYXIgb3IgbW9yZSBzcGVjaWZpYy4NClRoZSBkYW5nZXIgSSBzZWUgaW4gdG9vIG11Y2gg c3BlY2lmaWNpdHkgaXMgdGhhdCB5b3UgbGVhdmUgb3V0IHNvbWVvbmXigJlzIGZhdm9yaXRlIGVs ZW1lbnQuDQpBbmQgaGVuY2UgYSBiYXR0bGUgYmV0d2VlbiB3aG9zZSBmYXZvcml0ZXMgZ2V0IGlu IG9yIGRvbuKAmXQuDQoNCk15IDIgY2VudHMuICBOb3csIEkgd2lsbCBhdm9pZCBjb21tZW50aW5n IGFnYWluIGxpa2UgdGhlIHBsYWd1ZS4gIOKYug0KDQpFbmpveSwNCk1pa2UNCg0KRnJvbTogTHVp cyBOdW5leiBbbWFpbHRvOmxudW5lekBjM2lzZWN1cml0eS5jb21dDQpTZW50OiBXZWRuZXNkYXks IEF1Z3VzdCAyOSwgMjAxMiA5OjU4IEFNDQpUbzogTWljaGFlbCBIYW1tZXINCkNjOiBkYXZpZEBq b3ZhbC5vcmc7IHNhY21AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2FjbV0gUGVyY2VwdGlvbiBv ZiB0aGUgdGVybSAiTW9uaXRvcmluZyINCg0KZWFybHkgb24gd2UgcmFuIGludG8gaXNzdWVzIHdp dGggdGhlIHRlcm0gImNvbnRpbnVvdXMgbWFuYWdlbWVudCIuICBOb3Qgc3VyZSBpZiB0aGUgd29y ZCAibWFuYWdlbWVudCIgd2lsbCBpZ25pdGUgYW5vdGhlciBzdG9ybS4NCg0KVG8gbWUgSSBkb24n dCBzZWUgd2hhdCB0aGUgYmlnIGRlYWwgaXMuICBTQUNNIHNvdW5kcyBmaW5lIHdpdGggbWUuICBJ ZiBpdCBjYXVzZXMgY29udHJvdmVyc3kgZ3JlYXQuICBHZXR0aW5nIHBlb3BsZSBpbnRlcmVzdGVk IGFuZCBlbmdhZ2VkIGlzIGEgZ29vZCB0aGluZy4NCg0KDQotbG4NCg0KT24gQXVnIDI5LCAyMDEy LCBhdCA5OjMxIEFNLCBNaWNoYWVsIEhhbW1lciB3cm90ZToNCg0KDQpPciBqdXN0IHJlZmVyIHRv IGl0IGFzIGNvbXBsaWFuY2UgbWFuYWdlbWVudC4NClByb2JhYmx5IGJlc3Qgbm90IHRvIGdldCB0 b28gc3BlY2lmaWMgdG8gZnV0dXJlLXByb29mIGl0Lg0KDQpJIGFsd2F5cyBnZXQgYW11c2VkIGhv dyB0aGVzZSBuYW1pbmcgc3Rvcm1zIHRha2UgcGxhY2UuDQpBbmQgaW4gdGhlIGVuZCBzb21lb25l IGluIElFU0cgZ2V0cyB0aGUgZmluYWwgc2F5Lg0KWW91IG1pZ2h0IHdhbnQgdG8gcGluZyB0aGVt IG9uIG1hZ2ljIHdvcmRzIHRvIGF2b2lkLg0KVGhhdCBtaWdodCBjdXQgZG93biBvbiB0aGUgY2h1 cm4uDQoNCk1pa2UNCg0KDQpGcm9tOiBzYWNtLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNhY20t Ym91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmddPG1haWx0bzpb bWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZ10+IE9uIEJlaGFsZiBPZiBEYXZpZCBTb2xpbg0K U2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjksIDIwMTIgODo1NiBBTQ0KVG86IHNhY21AaWV0Zi5v cmc8bWFpbHRvOnNhY21AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NhY21dIFBlcmNlcHRpb24g b2YgdGhlIHRlcm0gIk1vbml0b3JpbmciDQoNCldoZW4geW91IGludmVudCBuZXcgdGVybXMgZm9y IGFueXRoaW5nIHlvdSdyZSB0cnlpbmcgdG8gaW50cm9kdWNlIGludG8gdGhlIG1hcmtldHBsYWNl LCB5b3UncmUgc3dpbW1pbmcgYWdhaW5zdCB0aGUgY3VycmVudC4gIEFsc28sIHdlIHJlYWxseSBh cmVuJ3QgYWRkcmVzc2luZyBtaXRpZ2F0aW9uIGF0IHRoaXMgcG9pbnQuICBJJ20gYWxzbyBzdXJl IHRoZSBpZGVhIG9mIGNvbnRpbnVvdXMgbWl0aWdhdGlvbiB3b3VsZCByYWlzZSBleWVicm93cyBm b3IgYW55b25lIHdobyB3b3JrcyBpbiBhIGNoYW5nZS1jb250cm9sbGVkIGVudmlyb25tZW50Lg0K DQpBbmQsIHNpbmNlIHRoZSBkb29yIGhhcyBiZWVuIG9wZW5lZCAuLi4gSSdtIG5vdCBhIGZhbiBv ZiBTQUNNLiAgSXQncyB0b28gY2xvc2UgdG8gU0NBTS4gIEknZCBoYXRlIGZvciB1cyB0byBpbnRy b2R1Y2UgYW5vdGhlciBjb250ZW50aW91cyBvciB1bmZhbWlsaWFyIHRlcm0gdG8ga2VlcCBhIG1h cmdpbmFsIGFjcm9ueW0uDQoNClJlZ2FyZHMsDQotLURhdmlkIFNvbGluDQoNCg0KT24gOC8yOS8y MDEyIDc6NDIgQU0sIE1vcmlhcnR5LCBLYXRobGVlbiB3cm90ZToNCg0KDQoNCkludGVyZXN0aW5n IHN1Z2dlc3Rpb24sIHRoYXQgY291bGQgYWxzbyBsZXQgdXMga2VlcCB0aGUgYWNyb255bSBhbmQg bGlzdCBpbiB0YWN0IHdpdGggdGhlIHVzZSBvZiBhIGxvd2VyIGNhc2UgZC4uLg0KDQoNCg0KVGhh bmtzLA0KDQpLYXRobGVlbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCkZyb206IHNhY20tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2FjbS1ib3VuY2VzQGll dGYub3JnPiBbc2FjbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5v cmc+XSBPbiBCZWhhbGYgT2YgQmFrZXIsIEpvbiBbYmFrZXJqQG1pdHJlLm9yZzxtYWlsdG86YmFr ZXJqQG1pdHJlLm9yZz5dDQoNClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDI5LCAyMDEyIDg6Mjgg QU0NCg0KVG86ICdzYWNtJw0KDQpTdWJqZWN0OiBSZTogW3NhY21dIFBlcmNlcHRpb24gb2YgdGhl IHRlcm0gIk1vbml0b3JpbmciDQoNCg0KDQpJIGJlbGlldmUgdGhlcmUgYXJlIHNvbWUgVVMgR292 IGxlYWRzIHRoYXQgYXJlIGNvbnNpZGVyaW5nIHVzaW5nICJjb250aW51b3VzIGRpYWdub3N0aWNz IGFuZCBNaXRpZ2F0aW9ucyIgYXMgYSByZXBsYWNlbWVudCBmb3IgY29udGludW91cyBtb25pdG9y aW5nLiBJdCBtaWdodCBiZSBuaWNlIHRvIGFsaWduIHNhY20gdGVybXMuDQoNCg0KDQoNCg0KDQoN ClNlbnQgd2l0aCBHb29kICh3d3cuZ29vZC5jb208aHR0cDovL3d3dy5nb29kLmNvbT4pDQoNCg0K DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogU3RlcGhlbiBIYW5uYSBb c2hhbm5hQGp1bmlwZXIubmV0PG1haWx0bzpzaGFubmFAanVuaXBlci5uZXQ+PG1haWx0bzpzaGFu bmFAanVuaXBlci5uZXQ+PG1haWx0bzpzaGFubmFAanVuaXBlci5uZXQ+XQ0KDQpTZW50OiBXZWRu ZXNkYXksIEF1Z3VzdCAyOSwgMjAxMiAwODoxOSBBTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNCg0K VG86IEFkYW0gTW9udHZpbGxlOyBkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldDxtYWlsdG86ZGF2aWQu b2xpdmFAdmVyaXpvbi5uZXQ+OyBzYWNtQGlldGYub3JnPG1haWx0bzpzYWNtQGlldGYub3JnPg0K DQpDYzogQWRhbSBXLiBNb250dmlsbGUNCg0KU3ViamVjdDogUmU6IFtzYWNtXSBQZXJjZXB0aW9u IG9mIHRoZSB0ZXJtICJNb25pdG9yaW5nIg0KDQoNCg0KDQoNCkkgYWdyZWUuIE1hbnkgdXNlcnMg YXJlIHVuY29tZm9ydGFibGUgd2l0aCB0aGUgaWRlYSBvZiBoYXZpbmcNCg0Kc29tZW9uZSBvciBz b21ldGhpbmcgbW9uaXRvcmluZyB0aGVpciAqYWN0aXZpdGllcyosIHdoaWNoIGlzDQoNCndoYXQg cGVvcGxlIG9mdGVuIHRoaW5rIHdoZW4gdGhleSB0aGluayBvZiBtb25pdG9yaW5nLg0KDQoNCg0K SG93ZXZlciwgdGhlcmUncyBub3QgbXVjaCBwcm9ibGVtIHdpdGggdGFraW5nIGV4aXN0aW5nIHN5 c3RlbXMNCg0KZm9yIGNoZWNraW5nIHNlY3VyaXR5IGNvbXBsaWFuY2Ugb2YgY29ycG9yYXRlLW93 bmVkIGRldmljZXMgYW5kDQoNCm1vdmluZyB0aGF0IGZyb20gcGVyaW9kaWMgYW5kIG9jY2FzaW9u YWwgY29tcGxpYW5jZSBhc3Nlc3NtZW50cw0KDQp0byBjb250aW51b3VzIG9uZXMuIEkgdGhpbmsg dGhhdCdzIHdoYXQgd2UncmUgdGFsa2luZyBhYm91dCBoZXJlLg0KDQoNCg0KU28gSSB0aGluayB0 aGF0ICJjb250aW51b3VzIGNvbXBsaWFuY2UiIG9yICJjb250aW51b3VzIGFzc2Vzc21lbnQiDQoN CndvdWxkIGJlIGEgZ29vZCB0ZXJtcy4gTGV0J3MgZHJvcCB0aGUgd29yZCAibW9uaXRvcmluZyIg YWx0b2dldGhlcg0KDQpzaW5jZSBpdCBpcyBvZnRlbiBtaXN1bmRlcnN0b29kLg0KDQoNCg0KVGhh bmtzLA0KDQoNCg0KU3RldmUNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZy b206IHNhY20tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnPiBb bWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQoNCkFkYW0gTW9udHZp bGxlDQoNClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDI5LCAyMDEyIDg6MDggQU0NCg0KVG86IGRh dmlkLm9saXZhQHZlcml6b24ubmV0PG1haWx0bzpkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldD47IHNh Y21AaWV0Zi5vcmc8bWFpbHRvOnNhY21AaWV0Zi5vcmc+DQoNCkNjOiBBZGFtIFcuIE1vbnR2aWxs ZQ0KDQpTdWJqZWN0OiBSZTogW3NhY21dIFBlcmNlcHRpb24gb2YgdGhlIHRlcm0gIk1vbml0b3Jp bmciDQoNCg0KDQpSZXNwb25kaW5nIG9uIHZhY2F0aW9uIC0gY29weWluZyBhIHBlcnNvbmFsIGFk ZHJlc3MgZm9yIG9mZi10aHJlYWQNCg0KY29udGFjdCwgaWYgbmVlZGVkLg0KDQoNCg0KUmVtYWlu aW5nIGNvbW1lbnRzIGlubGluZS4NCg0KDQoNCg0KDQpPbiA4LzI5LzEyIDU6MDEgQU0sICJkYXZp ZC5vbGl2YUB2ZXJpem9uLm5ldCI8bWFpbHRvOmRhdmlkLm9saXZhQHZlcml6b24ubmV0PiA8ZGF2 aWQub2xpdmFAdmVyaXpvbi5uZXQ+PG1haWx0bzpkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldD4NCg0K d3JvdGU6DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KQSBsYXJnZSBudW1iZXIgb2YgaGl0cyBhc3Nv Y2lhdGUgbW9uaXRvcmluZyB3aXRoIGVtcGxveWVlIG1vbml0b3JpbmcsDQoNCmV0aGljYWwgbW9u aXRvcmluZywgdGVsZXBob25lLXVzZSBlbXBsb3llZSBtb25pdG9yaW5nLCBwZXJmb3JtYW5jZQ0K DQptb25pdG9yaW5nLCBjb21wdXRlciBiZWhhdmlvciBtb25pdG9yaW5nLA0KDQpldGMuDQoNClBl cmhhcHMgaXQgaXMgbm90IGEgYmFkIGlkZWEgdG8gZGlzc29jaWF0ZSB0aGUgU0FDTSBlZmZvcnQg ZnJvbSB0aGUNCg0KcGVyY2VpdmVkIGltcHJlc3Npb24gdGhhdCB3ZSBhcmUgYnVpbGRpbmcgdG9v bHMgZm9yIGEgwrNCaWcgQnJvdGhlcsKyDQoNCmtpbmQNCg0Kb2Ygc29jaWV0eS4NCg0KDQoNCg0K DQoNCg0KVGhhbmtzIGZvciB0aGUgYWRkaXRpb25hbCBpbnNpZ2h0LCBEYXZpZCAtIEkgdGhpbmsg aXQgYm9sc3RlcnMgdGhlIGNhc2UNCg0KbmljZWx5Lg0KDQoNCg0KDQoNCg0KDQoNCg0KRGF2aWQg T2xpdmENCg0KDQoNCg0KDQoNCg0KT24gMDgvMjcvMTIsDQoNCkRhdmlkIFNvbGluPGRhdmlkQGpv dmFsLm9yZz48bWFpbHRvOmRhdmlkQGpvdmFsLm9yZz4gd3JvdGU6DQoNCg0KDQoNCg0KR29vZ2xl ICJjb250aW51b3VzIG1vbml0b3JpbmciICh+NyBtaWxsaW9uIHJlc3VsdHMpLCBhbmQgeW91J2xs IHNlZQ0KDQp3aHkNCg0KcGVvcGxlIHdobyBoYXZlIHNwZW50IGEgbG9uZyB0aW1lIHdvcmtpbmcg d2l0aCB0aGUgVVMgZ292ZXJubWVudCB0aGluaw0KDQppdCdzIGEgZ29vZCBmaXQgZm9yIHdoYXQg d2UncmUgdGFsa2luZyBhYm91dC4NCg0KDQoNCkdvb2dsZSAiY29udGludW91cyBjb21wbGlhbmNl IiAofjQ4IG1pbGxpb24gcmVzdWx0cyksIGFuZCB5b3UnbGwgc2VlDQoNCndoeQ0KDQpwZW9wbGUg d2hvIGhhdmUgc3BlbnQgYSBsb25nIHRpbWUgd29ya2luZyB3aXRoIGNvbW1lcmNpYWwgZW50ZXJw cmlzZQ0KDQpzb2Z0d2FyZSB0aGluayBpdCdzIGEgZ29vZCBmaXQgZm9yIHdoYXQgd2UncmUgdGFs a2luZyBhYm91dC4gIFlvdSdsbA0KDQphbHNvDQoNCm5vdGljZSBhIGxvdCBvZiB0aGUgc2FtZSBs aW5rcyBmcm9tIHRoZSBmaXJzdA0KDQpsaXN0Lg0KDQoNCg0KQW5kIHRoYXQncyB3aHkgSSB0aGlu ayAiY29udGludW91cyBjb21wbGlhbmNlIiBpcyBhIGJldHRlciBmaXQuICBJdA0KDQphbHNvDQoN CmhhcyB0aGUgYmVuZWZpdCBvZiBiZWluZyBpbiBjdXJyZW50IHVzZSBieSB2ZW5kb3JzIGFuZCBh bmFseXN0cywgYW5kDQoNCnNvDQoNCnRoZSBtYXJrZXRwbGFjZSB3b3VsZG4ndCBuZWVkIHRvIGJl IHRyYWluZWQgdG8gdW5kZXJzdGFuZCBpdC4NCg0KDQoNCg0KDQoNCg0KSXQncyB0aGUgImNvbnRp bnVvdXMiIHBhcnQgdGhhdCBtYXR0ZXJzIHRvIHRoZSBlZmZvcnQsIG5vdCB0aGUNCg0KIm1vbml0 b3JpbmciIHBhcnQuDQoNCg0KDQpUbyBtZSwgaXQncyAxMDAlIGFjY2VwdGFibGUgdG8gZHJvcCB0 aGUgdGVybSAibW9uaXRvcmluZyIgaW4gZmF2b3Igb2YgYQ0KDQpyZXBsYWNlbWVudCwgYW5kIEkg d291bGQsIGluIGZhY3QsIHByZWZlciB0byBkbyBzby4NCg0KDQoNCk90aGVycz8NCg0KDQoNCg0K DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K c2FjbSBtYWlsaW5nIGxpc3QNCg0Kc2FjbUBpZXRmLm9yZzxtYWlsdG86c2FjbUBpZXRmLm9yZz4N Cg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCnNhY20gbWFpbGluZyBs aXN0DQoNCnNhY21AaWV0Zi5vcmc8bWFpbHRvOnNhY21AaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbQ0KDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0Kc2FjbSBtYWlsaW5nIGxpc3QNCg0Kc2Fj bUBpZXRmLm9yZzxtYWlsdG86c2FjbUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zYWNtDQoNCi0tDQoNCmpPVkFMLm9yZzxodHRwOi8vak9WQUwub3Jn PjogT1ZBTCBpbXBsZW1lbnRlZCBpbiBKYXZhLg0KU2NhbiBhbnkgbWFjaGluZSBmcm9tIGFueSBt YWNoaW5lLiBGb3IgZnJlZSENCkxlYXJuIE1vcmU8aHR0cDovL3d3dy5qb3ZhbC5vcmc+IHwgRmVh dHVyZXM8aHR0cDovL3d3dy5qb3ZhbC5vcmcvZmVhdHVyZXMvPiB8IERvd25sb2FkPGh0dHA6Ly93 d3cuam92YWwub3JnL2Rvd25sb2FkLz4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpzYWNtIG1haWxpbmcgbGlzdA0Kc2FjbUBpZXRmLm9yZzxtYWlsdG86 c2FjbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Fj bQ0KDQo= From osantos@cisco.com Thu Aug 30 21:16: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 951F921F84C2 for ; Thu, 30 Aug 2012 21:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.67 X-Spam-Level: X-Spam-Status: No, score=-8.67 tagged_above=-999 required=5 tests=[AWL=-1.929, BAYES_00=-2.599, FRT_PROFIT1=3.858, 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 wA-irSZnoDdB for ; Thu, 30 Aug 2012 21:16:10 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C1A7221F847F for ; Thu, 30 Aug 2012 21:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12268; q=dns/txt; s=iport; t=1346386569; x=1347596169; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3/UFxFjy7Od9+0E8P5s/vQSXoTytBNlgs+7953dj7lA=; b=IupNhikZ6aok8xteGUshlUwXQj6WCEFTeUbqCEgkflML7UlW2PDrYMJi FlPNZcaVRDZAgZ7vwefxMu9hHlavDr3EtNDBZ2Np8Gd5xlGD2avlEi58M FSEa1P7+PgLPURLnoo9NBPW9hrYvo7r4UMLtUhQZ2zlBK5P4QOIMnaVQX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFADQ5QFCtJV2c/2dsb2JhbABFhgS0Im+BB4IgAQEBBAEBAQ8BEBE6CwwEAgEIEQQBAQMCBh0DAgICJQsUAQgIAgQBDQUIAQsOh1wDDAucH40YkmqBIYkBY4VvMmADlmuKAIMegWeCYw X-IronPort-AV: E=Sophos;i="4.80,345,1344211200"; d="scan'208";a="114044196" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 31 Aug 2012 04:16:08 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q7V4G8Ij002491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Aug 2012 04:16:08 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Thu, 30 Aug 2012 23:16:08 -0500 From: "Omar Santos (osantos)" To: "Moriarty, Kathleen" , Michael Hammer , "lnunez@c3isecurity.com" Thread-Topic: [sacm] Perception of the term "Monitoring" Thread-Index: AQHNhd4SruONwaqjMke8s4l5f9JybZdw9TsAgAADBQD//7+m+oAAV6iAgAAD0ACAAAnxgIAAB2iAgAADeYCAAABcAIACJY1A Date: Fri, 31 Aug 2012 04:16:08 +0000 Message-ID: <93ED586BE669044CA2F91C5F3BE4FD9017B827C5@xmb-rcd-x09.cisco.com> References: <6C1C15D8B5510B4B8FF132B10D386513020ED179@IMCMBX03.MITRE.ORG> <503E1162.4080703@joval.org> <00C069FD01E0324C9FFCADF539701DB31336F74E@ex2k10mb2.corp.yaanatech.com> <2FB0493A-7FFE-4B76-B394-4C8D107AA160@c3isecurity.com>, <00C069FD01E0324C9FFCADF539701DB31336F81E@ex2k10mb2.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.110.37] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19150.001 x-tm-as-result: No--43.431000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "david@joval.org" , "sacm@ietf.org" Subject: Re: [sacm] Perception 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: Fri, 31 Aug 2012 04:16:11 -0000 WW91IGhhdmUgYW4gZXhjZWxsZW50IHBvaW50IEthdGhsZWVuISEhIA0KDQpJIHRoaW5rIHRoYXQg d2UgYXJlIGVhc2lseSBtYWtpbmcgdGhlIHNlbGVjdGlvbiBvZiBhIFdHIG5hbWUgZmFyIG1vcmUg Y29tcGxpY2F0ZWQgdGhhbiB0aGUgYWN0dWFsIHN0YW5kYXJkcyB0aGF0IGFyZSBzdXBwb3NlZCB0 byBiZSBvdXIgZGVsaXZlcmFibGVzLg0KDQpEYXZpZCBTb2xpbiBoYWQgYSAqZ3JlYXQqIHBvaW50 OiAiV2hlbiB5b3UgaW52ZW50IG5ldyB0ZXJtcyBmb3IgYW55dGhpbmcgeW91J3JlIHRyeWluZyB0 byBpbnRyb2R1Y2UgaW50byB0aGUgbWFya2V0cGxhY2UsIHlvdSdyZSBzd2ltbWluZyBhZ2FpbnN0 IHRoZSBjdXJyZW50LiINCg0KSWYgdGhlIElFVEYgY29tbXVuaXR5IGlzIGFscmVhZHkgZmFtaWxp YXIgd2l0aCBTQUNNLCB0aGlzIGFsaWFzIGlzIHNhY20sIHdlIGhhdmUgYmVlbiB0YWxraW5nIGV2 ZXJ5dGhpbmcgU0FDTSwgSSBzdWdnZXN0IHdlIHN0YXkgd2l0aCBpdCBmb3Igbm93Lg0KDQpNaWtl IEhhbW1lciBhbHNvIGhhZCBhIGdvb2Qgc3VnZ2VzdGlvbiBvZiAiY29tcGxpYW5jZSBtYW5hZ2Vt ZW50IjsgdGhlcmVmb3JlICJTZWN1cml0eSBBdXRvbWF0aW9uIGFuZCBDb21wbGlhbmNlIE1hbmFn ZW1lbnQiLCBzdGlsbCBTQ0FNLi4NCg0KVG8gYmUgaG9uZXN0LCBJIGFtIG1vcmUgaW50ZXJlc3Rl ZCB0byBrbm93IHRoZSBhZ3JlZW1lbnRzL2FyZ3VtZW50cyBvZiBVQzEgKyBVQzMgIHZzLiBVQzEg KyBVQzIuLi4NCg0KUmVnYXJkcywNCg0KT21hciANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogc2FjbS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2FjbS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgTW9yaWFydHksIEthdGhsZWVuDQpTZW50OiBXZWRuZXNkYXks IEF1Z3VzdCAyOSwgMjAxMiAxMDoxMiBBTQ0KVG86IE1pY2hhZWwgSGFtbWVyOyBsbnVuZXpAYzNp c2VjdXJpdHkuY29tDQpDYzogZGF2aWRAam92YWwub3JnOyBzYWNtQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3NhY21dIFBlcmNlcHRpb24gb2YgdGhlIHRlcm0gIk1vbml0b3JpbmciDQoNCk9uZSBt b3JlIHBvaW50IHRvIGNvbnNpZGVyIGlzIHRoYXQgdGhlIFdHIG5hbWUgd2lsbCBldmVudHVhbGx5 IGdvIGF3YXkgKGFmdGVyIHdlIGFyZSBkb25lIHdpdGggdGhlIHdvcmsgaXRlbXMgYW5kIGEgZ3Jv dXAgaXMgY2xvc2VkIG91dCkgYW5kIHdoYXQgd2lsbCBsaXZlIG9uIGFyZSB0aGUgbmFtZXMgb2Yg c3RhbmRhcmRzIHByb2R1Y2VkIGJ5IGEgd29ya2luZyBncm91cC4NCg0KQmVzdCByZWdhcmRzLA0K S2F0aGxlZW4gDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9t OiBzYWNtLWJvdW5jZXNAaWV0Zi5vcmcgW3NhY20tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIE1pY2hhZWwgSGFtbWVyIFttaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tXQ0KU2VudDog V2VkbmVzZGF5LCBBdWd1c3QgMjksIDIwMTIgMTA6MTAgQU0NClRvOiBsbnVuZXpAYzNpc2VjdXJp dHkuY29tDQpDYzogZGF2aWRAam92YWwub3JnOyBzYWNtQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W3NhY21dIFBlcmNlcHRpb24gb2YgdGhlIHRlcm0gIk1vbml0b3JpbmciDQoNCkJUVywgdGhlIHJl YXNvbiBJIHVzZWQgdGhvc2UgdHdvIHdvcmRzIHdhcyB0byBiZSBsZXNzIHByZWNpc2UuDQpPbmUg Y2FuIHJlYWQgYSBudW1iZXIgb2YgdGhpbmdzIGludG8gYm90aCBjb21wbGlhbmNlIGFuZCBtYW5h Z2VtZW50Lg0KDQpZb3UgaGF2ZSB0aGUgb3B0aW9uIG9mIHRyeWluZyB0byBiZSBtb3JlIGdyYW51 bGFyIG9yIG1vcmUgc3BlY2lmaWMuDQpUaGUgZGFuZ2VyIEkgc2VlIGluIHRvbyBtdWNoIHNwZWNp ZmljaXR5IGlzIHRoYXQgeW91IGxlYXZlIG91dCBzb21lb25l4oCZcyBmYXZvcml0ZSBlbGVtZW50 Lg0KQW5kIGhlbmNlIGEgYmF0dGxlIGJldHdlZW4gd2hvc2UgZmF2b3JpdGVzIGdldCBpbiBvciBk b27igJl0Lg0KDQpNeSAyIGNlbnRzLiAgTm93LCBJIHdpbGwgYXZvaWQgY29tbWVudGluZyBhZ2Fp biBsaWtlIHRoZSBwbGFndWUuICDimLoNCg0KRW5qb3ksDQpNaWtlDQoNCkZyb206IEx1aXMgTnVu ZXogW21haWx0bzpsbnVuZXpAYzNpc2VjdXJpdHkuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1 c3QgMjksIDIwMTIgOTo1OCBBTQ0KVG86IE1pY2hhZWwgSGFtbWVyDQpDYzogZGF2aWRAam92YWwu b3JnOyBzYWNtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NhY21dIFBlcmNlcHRpb24gb2YgdGhl IHRlcm0gIk1vbml0b3JpbmciDQoNCmVhcmx5IG9uIHdlIHJhbiBpbnRvIGlzc3VlcyB3aXRoIHRo ZSB0ZXJtICJjb250aW51b3VzIG1hbmFnZW1lbnQiLiAgTm90IHN1cmUgaWYgdGhlIHdvcmQgIm1h bmFnZW1lbnQiIHdpbGwgaWduaXRlIGFub3RoZXIgc3Rvcm0uDQoNClRvIG1lIEkgZG9uJ3Qgc2Vl IHdoYXQgdGhlIGJpZyBkZWFsIGlzLiAgU0FDTSBzb3VuZHMgZmluZSB3aXRoIG1lLiAgSWYgaXQg Y2F1c2VzIGNvbnRyb3ZlcnN5IGdyZWF0LiAgR2V0dGluZyBwZW9wbGUgaW50ZXJlc3RlZCBhbmQg ZW5nYWdlZCBpcyBhIGdvb2QgdGhpbmcuDQoNCg0KLWxuDQoNCk9uIEF1ZyAyOSwgMjAxMiwgYXQg OTozMSBBTSwgTWljaGFlbCBIYW1tZXIgd3JvdGU6DQoNCg0KT3IganVzdCByZWZlciB0byBpdCBh cyBjb21wbGlhbmNlIG1hbmFnZW1lbnQuDQpQcm9iYWJseSBiZXN0IG5vdCB0byBnZXQgdG9vIHNw ZWNpZmljIHRvIGZ1dHVyZS1wcm9vZiBpdC4NCg0KSSBhbHdheXMgZ2V0IGFtdXNlZCBob3cgdGhl c2UgbmFtaW5nIHN0b3JtcyB0YWtlIHBsYWNlLg0KQW5kIGluIHRoZSBlbmQgc29tZW9uZSBpbiBJ RVNHIGdldHMgdGhlIGZpbmFsIHNheS4NCllvdSBtaWdodCB3YW50IHRvIHBpbmcgdGhlbSBvbiBt YWdpYyB3b3JkcyB0byBhdm9pZC4NClRoYXQgbWlnaHQgY3V0IGRvd24gb24gdGhlIGNodXJuLg0K DQpNaWtlDQoNCg0KRnJvbTogc2FjbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzYWNtLWJvdW5j ZXNAaWV0Zi5vcmc+IFttYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnXTxtYWlsdG86W21haWx0 bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YgRGF2aWQgU29saW4NClNlbnQ6 IFdlZG5lc2RheSwgQXVndXN0IDI5LCAyMDEyIDg6NTYgQU0NClRvOiBzYWNtQGlldGYub3JnPG1h aWx0bzpzYWNtQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzYWNtXSBQZXJjZXB0aW9uIG9mIHRo ZSB0ZXJtICJNb25pdG9yaW5nIg0KDQpXaGVuIHlvdSBpbnZlbnQgbmV3IHRlcm1zIGZvciBhbnl0 aGluZyB5b3UncmUgdHJ5aW5nIHRvIGludHJvZHVjZSBpbnRvIHRoZSBtYXJrZXRwbGFjZSwgeW91 J3JlIHN3aW1taW5nIGFnYWluc3QgdGhlIGN1cnJlbnQuICBBbHNvLCB3ZSByZWFsbHkgYXJlbid0 IGFkZHJlc3NpbmcgbWl0aWdhdGlvbiBhdCB0aGlzIHBvaW50LiAgSSdtIGFsc28gc3VyZSB0aGUg aWRlYSBvZiBjb250aW51b3VzIG1pdGlnYXRpb24gd291bGQgcmFpc2UgZXllYnJvd3MgZm9yIGFu eW9uZSB3aG8gd29ya3MgaW4gYSBjaGFuZ2UtY29udHJvbGxlZCBlbnZpcm9ubWVudC4NCg0KQW5k LCBzaW5jZSB0aGUgZG9vciBoYXMgYmVlbiBvcGVuZWQgLi4uIEknbSBub3QgYSBmYW4gb2YgU0FD TS4gIEl0J3MgdG9vIGNsb3NlIHRvIFNDQU0uICBJJ2QgaGF0ZSBmb3IgdXMgdG8gaW50cm9kdWNl IGFub3RoZXIgY29udGVudGlvdXMgb3IgdW5mYW1pbGlhciB0ZXJtIHRvIGtlZXAgYSBtYXJnaW5h bCBhY3JvbnltLg0KDQpSZWdhcmRzLA0KLS1EYXZpZCBTb2xpbg0KDQoNCk9uIDgvMjkvMjAxMiA3 OjQyIEFNLCBNb3JpYXJ0eSwgS2F0aGxlZW4gd3JvdGU6DQoNCg0KDQpJbnRlcmVzdGluZyBzdWdn ZXN0aW9uLCB0aGF0IGNvdWxkIGFsc28gbGV0IHVzIGtlZXAgdGhlIGFjcm9ueW0gYW5kIGxpc3Qg aW4gdGFjdCB3aXRoIHRoZSB1c2Ugb2YgYSBsb3dlciBjYXNlIGQuLi4NCg0KDQoNClRoYW5rcywN Cg0KS2F0aGxlZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpGcm9tOiBzYWNtLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9y Zz4gW3NhY20tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnPl0g T24gQmVoYWxmIE9mIEJha2VyLCBKb24gW2Jha2VyakBtaXRyZS5vcmc8bWFpbHRvOmJha2VyakBt aXRyZS5vcmc+XQ0KDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyOSwgMjAxMiA4OjI4IEFNDQoN ClRvOiAnc2FjbScNCg0KU3ViamVjdDogUmU6IFtzYWNtXSBQZXJjZXB0aW9uIG9mIHRoZSB0ZXJt ICJNb25pdG9yaW5nIg0KDQoNCg0KSSBiZWxpZXZlIHRoZXJlIGFyZSBzb21lIFVTIEdvdiBsZWFk cyB0aGF0IGFyZSBjb25zaWRlcmluZyB1c2luZyAiY29udGludW91cyBkaWFnbm9zdGljcyBhbmQg TWl0aWdhdGlvbnMiIGFzIGEgcmVwbGFjZW1lbnQgZm9yIGNvbnRpbnVvdXMgbW9uaXRvcmluZy4g SXQgbWlnaHQgYmUgbmljZSB0byBhbGlnbiBzYWNtIHRlcm1zLg0KDQoNCg0KDQoNCg0KDQpTZW50 IHdpdGggR29vZCAod3d3Lmdvb2QuY29tPGh0dHA6Ly93d3cuZ29vZC5jb20+KQ0KDQoNCg0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IFN0ZXBoZW4gSGFubmEgW3NoYW5u YUBqdW5pcGVyLm5ldDxtYWlsdG86c2hhbm5hQGp1bmlwZXIubmV0PjxtYWlsdG86c2hhbm5hQGp1 bmlwZXIubmV0PjxtYWlsdG86c2hhbm5hQGp1bmlwZXIubmV0Pl0NCg0KU2VudDogV2VkbmVzZGF5 LCBBdWd1c3QgMjksIDIwMTIgMDg6MTkgQU0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQoNClRvOiBB ZGFtIE1vbnR2aWxsZTsgZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ8bWFpbHRvOmRhdmlkLm9saXZh QHZlcml6b24ubmV0Pjsgc2FjbUBpZXRmLm9yZzxtYWlsdG86c2FjbUBpZXRmLm9yZz4NCg0KQ2M6 IEFkYW0gVy4gTW9udHZpbGxlDQoNClN1YmplY3Q6IFJlOiBbc2FjbV0gUGVyY2VwdGlvbiBvZiB0 aGUgdGVybSAiTW9uaXRvcmluZyINCg0KDQoNCg0KDQpJIGFncmVlLiBNYW55IHVzZXJzIGFyZSB1 bmNvbWZvcnRhYmxlIHdpdGggdGhlIGlkZWEgb2YgaGF2aW5nDQoNCnNvbWVvbmUgb3Igc29tZXRo aW5nIG1vbml0b3JpbmcgdGhlaXIgKmFjdGl2aXRpZXMqLCB3aGljaCBpcw0KDQp3aGF0IHBlb3Bs ZSBvZnRlbiB0aGluayB3aGVuIHRoZXkgdGhpbmsgb2YgbW9uaXRvcmluZy4NCg0KDQoNCkhvd2V2 ZXIsIHRoZXJlJ3Mgbm90IG11Y2ggcHJvYmxlbSB3aXRoIHRha2luZyBleGlzdGluZyBzeXN0ZW1z DQoNCmZvciBjaGVja2luZyBzZWN1cml0eSBjb21wbGlhbmNlIG9mIGNvcnBvcmF0ZS1vd25lZCBk ZXZpY2VzIGFuZA0KDQptb3ZpbmcgdGhhdCBmcm9tIHBlcmlvZGljIGFuZCBvY2Nhc2lvbmFsIGNv bXBsaWFuY2UgYXNzZXNzbWVudHMNCg0KdG8gY29udGludW91cyBvbmVzLiBJIHRoaW5rIHRoYXQn cyB3aGF0IHdlJ3JlIHRhbGtpbmcgYWJvdXQgaGVyZS4NCg0KDQoNClNvIEkgdGhpbmsgdGhhdCAi Y29udGludW91cyBjb21wbGlhbmNlIiBvciAiY29udGludW91cyBhc3Nlc3NtZW50Ig0KDQp3b3Vs ZCBiZSBhIGdvb2QgdGVybXMuIExldCdzIGRyb3AgdGhlIHdvcmQgIm1vbml0b3JpbmciIGFsdG9n ZXRoZXINCg0Kc2luY2UgaXQgaXMgb2Z0ZW4gbWlzdW5kZXJzdG9vZC4NCg0KDQoNClRoYW5rcywN Cg0KDQoNClN0ZXZlDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBz YWNtLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZz4gW21haWx0 bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KDQpBZGFtIE1vbnR2aWxsZQ0K DQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyOSwgMjAxMiA4OjA4IEFNDQoNClRvOiBkYXZpZC5v bGl2YUB2ZXJpem9uLm5ldDxtYWlsdG86ZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ+OyBzYWNtQGll dGYub3JnPG1haWx0bzpzYWNtQGlldGYub3JnPg0KDQpDYzogQWRhbSBXLiBNb250dmlsbGUNCg0K U3ViamVjdDogUmU6IFtzYWNtXSBQZXJjZXB0aW9uIG9mIHRoZSB0ZXJtICJNb25pdG9yaW5nIg0K DQoNCg0KUmVzcG9uZGluZyBvbiB2YWNhdGlvbiAtIGNvcHlpbmcgYSBwZXJzb25hbCBhZGRyZXNz IGZvciBvZmYtdGhyZWFkDQoNCmNvbnRhY3QsIGlmIG5lZWRlZC4NCg0KDQoNClJlbWFpbmluZyBj b21tZW50cyBpbmxpbmUuDQoNCg0KDQoNCg0KT24gOC8yOS8xMiA1OjAxIEFNLCAiZGF2aWQub2xp dmFAdmVyaXpvbi5uZXQiPG1haWx0bzpkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldD4gPGRhdmlkLm9s aXZhQHZlcml6b24ubmV0PjxtYWlsdG86ZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ+DQoNCndyb3Rl Og0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkEgbGFyZ2UgbnVtYmVyIG9mIGhpdHMgYXNzb2NpYXRl IG1vbml0b3Jpbmcgd2l0aCBlbXBsb3llZSBtb25pdG9yaW5nLA0KDQpldGhpY2FsIG1vbml0b3Jp bmcsIHRlbGVwaG9uZS11c2UgZW1wbG95ZWUgbW9uaXRvcmluZywgcGVyZm9ybWFuY2UNCg0KbW9u aXRvcmluZywgY29tcHV0ZXIgYmVoYXZpb3IgbW9uaXRvcmluZywNCg0KZXRjLg0KDQpQZXJoYXBz IGl0IGlzIG5vdCBhIGJhZCBpZGVhIHRvIGRpc3NvY2lhdGUgdGhlIFNBQ00gZWZmb3J0IGZyb20g dGhlDQoNCnBlcmNlaXZlZCBpbXByZXNzaW9uIHRoYXQgd2UgYXJlIGJ1aWxkaW5nIHRvb2xzIGZv ciBhIMKzQmlnIEJyb3RoZXLCsg0KDQpraW5kDQoNCm9mIHNvY2lldHkuDQoNCg0KDQoNCg0KDQoN ClRoYW5rcyBmb3IgdGhlIGFkZGl0aW9uYWwgaW5zaWdodCwgRGF2aWQgLSBJIHRoaW5rIGl0IGJv bHN0ZXJzIHRoZSBjYXNlDQoNCm5pY2VseS4NCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmlkIE9saXZh DQoNCg0KDQoNCg0KDQoNCk9uIDA4LzI3LzEyLA0KDQpEYXZpZCBTb2xpbjxkYXZpZEBqb3ZhbC5v cmc+PG1haWx0bzpkYXZpZEBqb3ZhbC5vcmc+IHdyb3RlOg0KDQoNCg0KDQoNCkdvb2dsZSAiY29u dGludW91cyBtb25pdG9yaW5nIiAofjcgbWlsbGlvbiByZXN1bHRzKSwgYW5kIHlvdSdsbCBzZWUN Cg0Kd2h5DQoNCnBlb3BsZSB3aG8gaGF2ZSBzcGVudCBhIGxvbmcgdGltZSB3b3JraW5nIHdpdGgg dGhlIFVTIGdvdmVybm1lbnQgdGhpbmsNCg0KaXQncyBhIGdvb2QgZml0IGZvciB3aGF0IHdlJ3Jl IHRhbGtpbmcgYWJvdXQuDQoNCg0KDQpHb29nbGUgImNvbnRpbnVvdXMgY29tcGxpYW5jZSIgKH40 OCBtaWxsaW9uIHJlc3VsdHMpLCBhbmQgeW91J2xsIHNlZQ0KDQp3aHkNCg0KcGVvcGxlIHdobyBo YXZlIHNwZW50IGEgbG9uZyB0aW1lIHdvcmtpbmcgd2l0aCBjb21tZXJjaWFsIGVudGVycHJpc2UN Cg0Kc29mdHdhcmUgdGhpbmsgaXQncyBhIGdvb2QgZml0IGZvciB3aGF0IHdlJ3JlIHRhbGtpbmcg YWJvdXQuICBZb3UnbGwNCg0KYWxzbw0KDQpub3RpY2UgYSBsb3Qgb2YgdGhlIHNhbWUgbGlua3Mg ZnJvbSB0aGUgZmlyc3QNCg0KbGlzdC4NCg0KDQoNCkFuZCB0aGF0J3Mgd2h5IEkgdGhpbmsgImNv bnRpbnVvdXMgY29tcGxpYW5jZSIgaXMgYSBiZXR0ZXIgZml0LiAgSXQNCg0KYWxzbw0KDQpoYXMg dGhlIGJlbmVmaXQgb2YgYmVpbmcgaW4gY3VycmVudCB1c2UgYnkgdmVuZG9ycyBhbmQgYW5hbHlz dHMsIGFuZA0KDQpzbw0KDQp0aGUgbWFya2V0cGxhY2Ugd291bGRuJ3QgbmVlZCB0byBiZSB0cmFp bmVkIHRvIHVuZGVyc3RhbmQgaXQuDQoNCg0KDQoNCg0KDQoNCkl0J3MgdGhlICJjb250aW51b3Vz IiBwYXJ0IHRoYXQgbWF0dGVycyB0byB0aGUgZWZmb3J0LCBub3QgdGhlDQoNCiJtb25pdG9yaW5n IiBwYXJ0Lg0KDQoNCg0KVG8gbWUsIGl0J3MgMTAwJSBhY2NlcHRhYmxlIHRvIGRyb3AgdGhlIHRl cm0gIm1vbml0b3JpbmciIGluIGZhdm9yIG9mIGENCg0KcmVwbGFjZW1lbnQsIGFuZCBJIHdvdWxk LCBpbiBmYWN0LCBwcmVmZXIgdG8gZG8gc28uDQoNCg0KDQpPdGhlcnM/DQoNCg0KDQoNCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCnNhY20g bWFpbGluZyBsaXN0DQoNCnNhY21AaWV0Zi5vcmc8bWFpbHRvOnNhY21AaWV0Zi5vcmc+DQoNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbQ0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpzYWNtIG1haWxpbmcgbGlzdA0K DQpzYWNtQGlldGYub3JnPG1haWx0bzpzYWNtQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCnNhY20gbWFpbGluZyBsaXN0DQoNCnNhY21AaWV0 Zi5vcmc8bWFpbHRvOnNhY21AaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2FjbQ0KDQotLQ0KDQpqT1ZBTC5vcmc8aHR0cDovL2pPVkFMLm9yZz46IE9W QUwgaW1wbGVtZW50ZWQgaW4gSmF2YS4NClNjYW4gYW55IG1hY2hpbmUgZnJvbSBhbnkgbWFjaGlu ZS4gRm9yIGZyZWUhDQpMZWFybiBNb3JlPGh0dHA6Ly93d3cuam92YWwub3JnPiB8IEZlYXR1cmVz PGh0dHA6Ly93d3cuam92YWwub3JnL2ZlYXR1cmVzLz4gfCBEb3dubG9hZDxodHRwOi8vd3d3Lmpv dmFsLm9yZy9kb3dubG9hZC8+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kc2FjbSBtYWlsaW5nIGxpc3QNCnNhY21AaWV0Zi5vcmc8bWFpbHRvOnNhY21A aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNhY20gbWFp bGluZyBsaXN0DQpzYWNtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NhY20NCg== From adam@stoicsecurity.com Fri Aug 31 05:18:26 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 2EE1221F85F9 for ; Fri, 31 Aug 2012 05:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.072, 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 lWWcNJCmeO2N for ; Fri, 31 Aug 2012 05:18:25 -0700 (PDT) Received: from p3plsmtpa07-04.prod.phx3.secureserver.net (p3plsmtpa07-04.prod.phx3.secureserver.net [173.201.192.233]) by ietfa.amsl.com (Postfix) with SMTP id 7896421F858E for ; Fri, 31 Aug 2012 05:18:25 -0700 (PDT) Received: (qmail 25110 invoked from network); 31 Aug 2012 12:18:24 -0000 Received: from unknown (50.137.24.91) by p3plsmtpa07-04.prod.phx3.secureserver.net (173.201.192.233) with ESMTP; 31 Aug 2012 12:18:24 -0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_8B682B77-474C-4450-9518-C8A184C9362B" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Adam Montville In-Reply-To: <93ED586BE669044CA2F91C5F3BE4FD9017B827C5@xmb-rcd-x09.cisco.com> Date: Fri, 31 Aug 2012 05:18:21 -0700 Message-Id: References: <6C1C15D8B5510B4B8FF132B10D386513020ED179@IMCMBX03.MITRE.ORG> <503E1162.4080703@joval.org> <00C069FD01E0324C9FFCADF539701DB31336F74E@ex2k10mb2.corp.yaanatech.com> <2FB0493A-7FFE-4B76-B394-4C8D107AA160@c3isecurity.com>, <00C069FD01E0324C9FFCADF539701DB31336F81E@ex2k10mb2.corp.yaanatech.com> <93ED586BE669044CA2F91C5F3BE4FD9017B827C5@xmb-rcd-x09.cisco.com> To: "Omar Santos (osantos)" X-Mailer: Apple Mail (2.1486) Cc: "lnunez@c3isecurity.com" , Michael Hammer , "david@joval.org" , "Moriarty, Kathleen" , "sacm@ietf.org" Subject: Re: [sacm] Perception 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: Fri, 31 Aug 2012 12:18:26 -0000 --Apple-Mail=_8B682B77-474C-4450-9518-C8A184C9362B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 30, 2012, at 9:16 PM, "Omar Santos (osantos)" = wrote: > To be honest, I am more interested to know the agreements/arguments of = UC1 + UC3 vs. UC1 + UC2... At this point there is consensus to go with UC1 and UC3 (the use case = document will likely be reformatted with just these two use cases = included). The list archive should have all the relevant arguments and = such.= --Apple-Mail=_8B682B77-474C-4450-9518-C8A184C9362B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii osantos@cisco.com> = wrote:

X-Mailer: Apple Mail (2.1486) Cc: "lnunez@c3isecurity.com" , Michael Hammer , "david@joval.org" , "Moriarty, Kathleen" , "sacm@ietf.org" Subject: Re: [sacm] Perception 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: Fri, 31 Aug 2012 12:21:56 -0000 On Aug 30, 2012, at 9:16 PM, "Omar Santos (osantos)" = wrote: > You have an excellent point Kathleen!!!=20 >=20 > I think that we are easily making the selection of a WG name far more = complicated than the actual standards that are supposed to be our = deliverables. >=20 Agreed. I would much rather be focusing our energy on getting the = content of the charter discussed more completely. That said, I'd like = to propose that we table the discussion of the working group name until = Atlanta - unless there's a compelling reason to settle the issue now - = and move on to completing the discussion of the draft charter. > David Solin had a *great* point: "When you invent new terms for = anything you're trying to introduce into the marketplace, you're = swimming against the current." >=20 > If the IETF community is already familiar with SACM, this alias is = sacm, we have been talking everything SACM, I suggest we stay with it = for now. >=20 > Mike Hammer also had a good suggestion of "compliance management"; = therefore "Security Automation and Compliance Management", still SCAM.. >=20 > To be honest, I am more interested to know the agreements/arguments of = UC1 + UC3 vs. UC1 + UC2... >=20 > Regards, >=20 > Omar=20 >=20 >=20 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of Moriarty, Kathleen > Sent: Wednesday, August 29, 2012 10:12 AM > To: Michael Hammer; lnunez@c3isecurity.com > Cc: david@joval.org; sacm@ietf.org > Subject: Re: [sacm] Perception of the term "Monitoring" >=20 > One more point to consider is that the WG name will eventually go away = (after we are done with the work items and a group is closed out) and = what will live on are the names of standards produced by a working = group. >=20 > Best regards, > Kathleen=20 > ________________________________________ > From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of = Michael Hammer [michael.hammer@yaanatech.com] > Sent: Wednesday, August 29, 2012 10:10 AM > To: lnunez@c3isecurity.com > Cc: david@joval.org; sacm@ietf.org > Subject: Re: [sacm] Perception of the term "Monitoring" >=20 > BTW, the reason I used those two words was to be less precise. > One can read a number of things into both compliance and management. >=20 > You have the option of trying to be more granular or more specific. > The danger I see in too much specificity is that you leave out = someone=E2=80=99s favorite element. > And hence a battle between whose favorites get in or don=E2=80=99t. >=20 > My 2 cents. Now, I will avoid commenting again like the plague. =E2=98= =BA >=20 > Enjoy, > Mike >=20 > From: Luis Nunez [mailto:lnunez@c3isecurity.com] > Sent: Wednesday, August 29, 2012 9:58 AM > To: Michael Hammer > Cc: david@joval.org; sacm@ietf.org > Subject: Re: [sacm] Perception of the term "Monitoring" >=20 > early on we ran into issues with the term "continuous management". = Not sure if the word "management" will ignite another storm. >=20 > To me I don't see what the big deal is. SACM sounds fine with me. If = it causes controversy great. Getting people interested and engaged is a = good thing. >=20 >=20 > -ln >=20 > On Aug 29, 2012, at 9:31 AM, Michael Hammer wrote: >=20 >=20 > Or just refer to it as compliance management. > Probably best not to get too specific to future-proof it. >=20 > I always get amused how these naming storms take place. > And in the end someone in IESG gets the final say. > You might want to ping them on magic words to avoid. > That might cut down on the churn. >=20 > Mike >=20 >=20 > From: sacm-bounces@ietf.org = [mailto:sacm-bounces@ietf.org] On = Behalf Of David Solin > Sent: Wednesday, August 29, 2012 8:56 AM > To: sacm@ietf.org > Subject: Re: [sacm] Perception of the term "Monitoring" >=20 > When you invent new terms for anything you're trying to introduce into = the marketplace, you're swimming against the current. Also, we really = aren't addressing mitigation at this point. I'm also sure the idea of = continuous mitigation would raise eyebrows for anyone who works in a = change-controlled environment. >=20 > And, since the door has been opened ... I'm not a fan of SACM. It's = too close to SCAM. I'd hate for us to introduce another contentious or = unfamiliar term to keep a marginal acronym. >=20 > Regards, > --David Solin >=20 >=20 > On 8/29/2012 7:42 AM, Moriarty, Kathleen wrote: >=20 >=20 >=20 > Interesting suggestion, that could also let us keep the acronym and = list in tact with the use of a lower case d... >=20 >=20 >=20 > Thanks, >=20 > Kathleen >=20 > ________________________________________ >=20 > From: sacm-bounces@ietf.org = [sacm-bounces@ietf.org] On Behalf Of = Baker, Jon [bakerj@mitre.org] >=20 > Sent: Wednesday, August 29, 2012 8:28 AM >=20 > To: 'sacm' >=20 > Subject: Re: [sacm] Perception of the term "Monitoring" >=20 >=20 >=20 > I believe there are some US Gov leads that are considering using = "continuous diagnostics and Mitigations" as a replacement for continuous = monitoring. It might be nice to align sacm terms. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Sent with Good (www.good.com) >=20 >=20 >=20 >=20 >=20 > -----Original Message----- >=20 > From: Stephen Hanna = [shanna@juniper.net<= mailto:shanna@juniper.net>] >=20 > Sent: Wednesday, August 29, 2012 08:19 AM Eastern Standard Time >=20 > To: Adam Montville; = david.oliva@verizon.net; = sacm@ietf.org >=20 > Cc: Adam W. Montville >=20 > Subject: Re: [sacm] Perception of the term "Monitoring" >=20 >=20 >=20 >=20 >=20 > I agree. Many users are uncomfortable with the idea of having >=20 > someone or something monitoring their *activities*, which is >=20 > what people often think when they think of monitoring. >=20 >=20 >=20 > However, there's not much problem with taking existing systems >=20 > for checking security compliance of corporate-owned devices and >=20 > moving that from periodic and occasional compliance assessments >=20 > to continuous ones. I think that's what we're talking about here. >=20 >=20 >=20 > So I think that "continuous compliance" or "continuous assessment" >=20 > would be a good terms. Let's drop the word "monitoring" altogether >=20 > since it is often misunderstood. >=20 >=20 >=20 > Thanks, >=20 >=20 >=20 > Steve >=20 >=20 >=20 > -----Original Message----- >=20 > From: sacm-bounces@ietf.org = [mailto:sacm-bounces@ietf.org] On Behalf Of >=20 > Adam Montville >=20 > Sent: Wednesday, August 29, 2012 8:08 AM >=20 > To: david.oliva@verizon.net; = sacm@ietf.org >=20 > Cc: Adam W. Montville >=20 > Subject: Re: [sacm] Perception of the term "Monitoring" >=20 >=20 >=20 > Responding on vacation - copying a personal address for off-thread >=20 > contact, if needed. >=20 >=20 >=20 > Remaining comments inline. >=20 >=20 >=20 >=20 >=20 > On 8/29/12 5:01 AM, = "david.oliva@verizon.net" = >=20 > wrote: >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > A large number of hits associate monitoring with employee monitoring, >=20 > ethical monitoring, telephone-use employee monitoring, performance >=20 > monitoring, computer behavior monitoring, >=20 > etc. >=20 > Perhaps it is not a bad idea to dissociate the SACM effort from the >=20 > perceived impression that we are building tools for a =C2=B3Big = Brother=C2=B2 >=20 > kind >=20 > of society. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Thanks for the additional insight, David - I think it bolsters the = case >=20 > nicely. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > David Oliva >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 08/27/12, >=20 > David Solin wrote: >=20 >=20 >=20 >=20 >=20 > Google "continuous monitoring" (~7 million results), and you'll see >=20 > why >=20 > people who have spent a long time working with the US government think >=20 > it's a good fit for what we're talking about. >=20 >=20 >=20 > Google "continuous compliance" (~48 million results), and you'll see >=20 > why >=20 > people who have spent a long time working with commercial enterprise >=20 > software think it's a good fit for what we're talking about. You'll >=20 > also >=20 > notice a lot of the same links from the first >=20 > list. >=20 >=20 >=20 > And that's why I think "continuous compliance" is a better fit. It >=20 > also >=20 > has the benefit of being in current use by vendors and analysts, and >=20 > so >=20 > the marketplace wouldn't need to be trained to understand it. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > It's the "continuous" part that matters to the effort, not the >=20 > "monitoring" part. >=20 >=20 >=20 > To me, it's 100% acceptable to drop the term "monitoring" in favor of = a >=20 > replacement, and I would, in fact, prefer to do so. >=20 >=20 >=20 > Others? >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ >=20 > sacm mailing list >=20 > sacm@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/sacm >=20 > _______________________________________________ >=20 > sacm mailing list >=20 > sacm@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/sacm >=20 >=20 >=20 > _______________________________________________ >=20 > sacm mailing list >=20 > sacm@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/sacm >=20 > -- >=20 > jOVAL.org: OVAL implemented in Java. > Scan any machine from any machine. For free! > Learn More | = Features | = Download > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From lnunez@c3isecurity.com Fri Aug 31 08:31: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 B3F3221F866D for ; Fri, 31 Aug 2012 08:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[AWL=-1.865, BAYES_00=-2.599, FRT_PROFIT1=3.858, 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 4iQhRi-NhQlo for ; Fri, 31 Aug 2012 08:31:39 -0700 (PDT) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id F209621F866A for ; Fri, 31 Aug 2012 08:31:38 -0700 (PDT) Received: by yhfs35 with SMTP id s35so767556yhf.27 for ; Fri, 31 Aug 2012 08:31:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=SgvfaOxZL4FReDqrXs5um1CRh4gCSt4thcyIX5hJeZY=; b=JwnsC4KN7VxYIfyToqd2xYMV4gMR3VWlmyy+wDp1JR1TTyzU11SWnh5Z8XAUCIOyHn iP7sVpFlm9mheszWeONgJCNe5iMyuXX8o3VAO5dgcJT3SKOD1WpNw+54ezLLLr4ou5ge 08XilwQ6DPc3Ir1zHAEpLnJ1iE3Zz+ghdxcmBSne8KM1cf/gxI8r5YBQlRwa0517R1Z8 LlS+MqTiLZgTtOga9VN37uwR19yVsFQEWP8Uj6v2sfKyyDYB47RdpZPtMQBDyjm4xx9Y 7WHB+5IqM1/rgftQL1wK9c3HjZiUiMD7ixLjdkzPGc96XZ/ym+uelNhxl4+KmZB9XxVj g/uQ== Received: by 10.236.197.5 with SMTP id s5mr8480415yhn.114.1346427098475; Fri, 31 Aug 2012 08:31:38 -0700 (PDT) Received: from [192.168.1.16] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id t63sm9032416yhd.7.2012.08.31.08.31.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 31 Aug 2012 08:31:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: Luis Nunez In-Reply-To: Date: Fri, 31 Aug 2012 11:31:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6C1C15D8B5510B4B8FF132B10D386513020ED179@IMCMBX03.MITRE.ORG> <503E1162.4080703@joval.org> <00C069FD01E0324C9FFCADF539701DB31336F74E@ex2k10mb2.corp.yaanatech.com> <2FB0493A-7FFE-4B76-B394-4C8D107AA160@c3isecurity.com>, <00C069FD01E0324C9FFCADF539701DB31336F81E@ex2k10mb2.corp.yaanatech.com> <93ED586BE669044CA2F91C5F3BE4FD9017B827C5@xmb-rcd-x09.cisco.com> To: Adam Montville X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQk+kjrtF5XR25W3/Q6WBenzrEx/QPGrO09f8dveCoJisKGo/xmLB6v76VjBzN8bRvWQWlR/ Cc: Michael Hammer , "david@joval.org" , "Moriarty, Kathleen" , "sacm@ietf.org" , "Omar Santos \(osantos\)" Subject: Re: [sacm] Perception 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: Fri, 31 Aug 2012 15:31:40 -0000 +1 -ln On Aug 31, 2012, at 8:21 AM, Adam Montville wrote: >=20 > On Aug 30, 2012, at 9:16 PM, "Omar Santos (osantos)" = wrote: >=20 >> You have an excellent point Kathleen!!!=20 >>=20 >> I think that we are easily making the selection of a WG name far more = complicated than the actual standards that are supposed to be our = deliverables. >>=20 >=20 >=20 > Agreed. I would much rather be focusing our energy on getting the = content of the charter discussed more completely. That said, I'd like = to propose that we table the discussion of the working group name until = Atlanta - unless there's a compelling reason to settle the issue now - = and move on to completing the discussion of the draft charter. >=20 >=20 >> David Solin had a *great* point: "When you invent new terms for = anything you're trying to introduce into the marketplace, you're = swimming against the current." >>=20 >> If the IETF community is already familiar with SACM, this alias is = sacm, we have been talking everything SACM, I suggest we stay with it = for now. >>=20 >> Mike Hammer also had a good suggestion of "compliance management"; = therefore "Security Automation and Compliance Management", still SCAM.. >>=20 >> To be honest, I am more interested to know the agreements/arguments = of UC1 + UC3 vs. UC1 + UC2... >>=20 >> Regards, >>=20 >> Omar=20 >>=20 >>=20 >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of Moriarty, Kathleen >> Sent: Wednesday, August 29, 2012 10:12 AM >> To: Michael Hammer; lnunez@c3isecurity.com >> Cc: david@joval.org; sacm@ietf.org >> Subject: Re: [sacm] Perception of the term "Monitoring" >>=20 >> One more point to consider is that the WG name will eventually go = away (after we are done with the work items and a group is closed out) = and what will live on are the names of standards produced by a working = group. >>=20 >> Best regards, >> Kathleen=20 >> ________________________________________ >> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of = Michael Hammer [michael.hammer@yaanatech.com] >> Sent: Wednesday, August 29, 2012 10:10 AM >> To: lnunez@c3isecurity.com >> Cc: david@joval.org; sacm@ietf.org >> Subject: Re: [sacm] Perception of the term "Monitoring" >>=20 >> BTW, the reason I used those two words was to be less precise. >> One can read a number of things into both compliance and management. >>=20 >> You have the option of trying to be more granular or more specific. >> The danger I see in too much specificity is that you leave out = someone=E2=80=99s favorite element. >> And hence a battle between whose favorites get in or don=E2=80=99t. >>=20 >> My 2 cents. Now, I will avoid commenting again like the plague. =E2=98= =BA >>=20 >> Enjoy, >> Mike >>=20 >> From: Luis Nunez [mailto:lnunez@c3isecurity.com] >> Sent: Wednesday, August 29, 2012 9:58 AM >> To: Michael Hammer >> Cc: david@joval.org; sacm@ietf.org >> Subject: Re: [sacm] Perception of the term "Monitoring" >>=20 >> early on we ran into issues with the term "continuous management". = Not sure if the word "management" will ignite another storm. >>=20 >> To me I don't see what the big deal is. SACM sounds fine with me. = If it causes controversy great. Getting people interested and engaged = is a good thing. >>=20 >>=20 >> -ln >>=20 >> On Aug 29, 2012, at 9:31 AM, Michael Hammer wrote: >>=20 >>=20 >> Or just refer to it as compliance management. >> Probably best not to get too specific to future-proof it. >>=20 >> I always get amused how these naming storms take place. >> And in the end someone in IESG gets the final say. >> You might want to ping them on magic words to avoid. >> That might cut down on the churn. >>=20 >> Mike >>=20 >>=20 >> From: sacm-bounces@ietf.org = [mailto:sacm-bounces@ietf.org] On = Behalf Of David Solin >> Sent: Wednesday, August 29, 2012 8:56 AM >> To: sacm@ietf.org >> Subject: Re: [sacm] Perception of the term "Monitoring" >>=20 >> When you invent new terms for anything you're trying to introduce = into the marketplace, you're swimming against the current. Also, we = really aren't addressing mitigation at this point. I'm also sure the = idea of continuous mitigation would raise eyebrows for anyone who works = in a change-controlled environment. >>=20 >> And, since the door has been opened ... I'm not a fan of SACM. It's = too close to SCAM. I'd hate for us to introduce another contentious or = unfamiliar term to keep a marginal acronym. >>=20 >> Regards, >> --David Solin >>=20 >>=20 >> On 8/29/2012 7:42 AM, Moriarty, Kathleen wrote: >>=20 >>=20 >>=20 >> Interesting suggestion, that could also let us keep the acronym and = list in tact with the use of a lower case d... >>=20 >>=20 >>=20 >> Thanks, >>=20 >> Kathleen >>=20 >> ________________________________________ >>=20 >> From: sacm-bounces@ietf.org = [sacm-bounces@ietf.org] On Behalf Of = Baker, Jon [bakerj@mitre.org] >>=20 >> Sent: Wednesday, August 29, 2012 8:28 AM >>=20 >> To: 'sacm' >>=20 >> Subject: Re: [sacm] Perception of the term "Monitoring" >>=20 >>=20 >>=20 >> I believe there are some US Gov leads that are considering using = "continuous diagnostics and Mitigations" as a replacement for continuous = monitoring. It might be nice to align sacm terms. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Sent with Good (www.good.com) >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >>=20 >> From: Stephen Hanna = [shanna@juniper.net<= mailto:shanna@juniper.net>] >>=20 >> Sent: Wednesday, August 29, 2012 08:19 AM Eastern Standard Time >>=20 >> To: Adam Montville; = david.oliva@verizon.net; = sacm@ietf.org >>=20 >> Cc: Adam W. Montville >>=20 >> Subject: Re: [sacm] Perception of the term "Monitoring" >>=20 >>=20 >>=20 >>=20 >>=20 >> I agree. Many users are uncomfortable with the idea of having >>=20 >> someone or something monitoring their *activities*, which is >>=20 >> what people often think when they think of monitoring. >>=20 >>=20 >>=20 >> However, there's not much problem with taking existing systems >>=20 >> for checking security compliance of corporate-owned devices and >>=20 >> moving that from periodic and occasional compliance assessments >>=20 >> to continuous ones. I think that's what we're talking about here. >>=20 >>=20 >>=20 >> So I think that "continuous compliance" or "continuous assessment" >>=20 >> would be a good terms. Let's drop the word "monitoring" altogether >>=20 >> since it is often misunderstood. >>=20 >>=20 >>=20 >> Thanks, >>=20 >>=20 >>=20 >> Steve >>=20 >>=20 >>=20 >> -----Original Message----- >>=20 >> From: sacm-bounces@ietf.org = [mailto:sacm-bounces@ietf.org] On Behalf Of >>=20 >> Adam Montville >>=20 >> Sent: Wednesday, August 29, 2012 8:08 AM >>=20 >> To: david.oliva@verizon.net; = sacm@ietf.org >>=20 >> Cc: Adam W. Montville >>=20 >> Subject: Re: [sacm] Perception of the term "Monitoring" >>=20 >>=20 >>=20 >> Responding on vacation - copying a personal address for off-thread >>=20 >> contact, if needed. >>=20 >>=20 >>=20 >> Remaining comments inline. >>=20 >>=20 >>=20 >>=20 >>=20 >> On 8/29/12 5:01 AM, = "david.oliva@verizon.net" = >>=20 >> wrote: >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> A large number of hits associate monitoring with employee monitoring, >>=20 >> ethical monitoring, telephone-use employee monitoring, performance >>=20 >> monitoring, computer behavior monitoring, >>=20 >> etc. >>=20 >> Perhaps it is not a bad idea to dissociate the SACM effort from the >>=20 >> perceived impression that we are building tools for a =C2=B3Big = Brother=C2=B2 >>=20 >> kind >>=20 >> of society. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Thanks for the additional insight, David - I think it bolsters the = case >>=20 >> nicely. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> David Oliva >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 08/27/12, >>=20 >> David Solin wrote: >>=20 >>=20 >>=20 >>=20 >>=20 >> Google "continuous monitoring" (~7 million results), and you'll see >>=20 >> why >>=20 >> people who have spent a long time working with the US government = think >>=20 >> it's a good fit for what we're talking about. >>=20 >>=20 >>=20 >> Google "continuous compliance" (~48 million results), and you'll see >>=20 >> why >>=20 >> people who have spent a long time working with commercial enterprise >>=20 >> software think it's a good fit for what we're talking about. You'll >>=20 >> also >>=20 >> notice a lot of the same links from the first >>=20 >> list. >>=20 >>=20 >>=20 >> And that's why I think "continuous compliance" is a better fit. It >>=20 >> also >>=20 >> has the benefit of being in current use by vendors and analysts, and >>=20 >> so >>=20 >> the marketplace wouldn't need to be trained to understand it. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> It's the "continuous" part that matters to the effort, not the >>=20 >> "monitoring" part. >>=20 >>=20 >>=20 >> To me, it's 100% acceptable to drop the term "monitoring" in favor of = a >>=20 >> replacement, and I would, in fact, prefer to do so. >>=20 >>=20 >>=20 >> Others? >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >>=20 >> sacm mailing list >>=20 >> sacm@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/sacm >>=20 >> _______________________________________________ >>=20 >> sacm mailing list >>=20 >> sacm@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/sacm >>=20 >>=20 >>=20 >> _______________________________________________ >>=20 >> sacm mailing list >>=20 >> sacm@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/sacm >>=20 >> -- >>=20 >> jOVAL.org: OVAL implemented in Java. >> Scan any machine from any machine. For free! >> Learn More | = Features | = Download >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >=20 From david.waltermire@nist.gov Fri Aug 31 10:57: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 0404B21F85C0 for ; Fri, 31 Aug 2012 10:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.571 X-Spam-Level: X-Spam-Status: No, score=-4.571 tagged_above=-999 required=5 tests=[AWL=-1.830, BAYES_00=-2.599, FRT_PROFIT1=3.858, 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 vZl3T+NFHvep for ; Fri, 31 Aug 2012 10:57:32 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 64A5D21F84B9 for ; Fri, 31 Aug 2012 10:57:31 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.379.0; Fri, 31 Aug 2012 13:57:11 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 31 Aug 2012 13:56:48 -0400 From: "Waltermire, David A." To: Luis Nunez , Adam Montville Date: Fri, 31 Aug 2012 13:57:29 -0400 Thread-Topic: [sacm] Perception of the term "Monitoring" Thread-Index: Ac2HjaLi5Kf/zeXfSl2I14Iu2rfaxgAFG65Q Message-ID: References: <6C1C15D8B5510B4B8FF132B10D386513020ED179@IMCMBX03.MITRE.ORG> <503E1162.4080703@joval.org> <00C069FD01E0324C9FFCADF539701DB31336F74E@ex2k10mb2.corp.yaanatech.com> <2FB0493A-7FFE-4B76-B394-4C8D107AA160@c3isecurity.com>, <00C069FD01E0324C9FFCADF539701DB31336F81E@ex2k10mb2.corp.yaanatech.com> <93ED586BE669044CA2F91C5F3BE4FD9017B827C5@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Moriarty, Kathleen" , "david@joval.org" , Michael Hammer , "sacm@ietf.org" , "Omar Santos \(osantos\)" Subject: Re: [sacm] Perception 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: Fri, 31 Aug 2012 17:57:34 -0000 KzENCg0KU2luY2VyZWx5LA0KRGF2ZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogc2FjbS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgTHVpcyBOdW5leg0KU2VudDogRnJpZGF5LCBBdWd1c3QgMzEsIDIwMTIgMTE6 MzIgQU0NClRvOiBBZGFtIE1vbnR2aWxsZQ0KQ2M6IE1pY2hhZWwgSGFtbWVyOyBkYXZpZEBqb3Zh bC5vcmc7IE1vcmlhcnR5LCBLYXRobGVlbjsgc2FjbUBpZXRmLm9yZzsgT21hciBTYW50b3MgKG9z YW50b3MpDQpTdWJqZWN0OiBSZTogW3NhY21dIFBlcmNlcHRpb24gb2YgdGhlIHRlcm0gIk1vbml0 b3JpbmciDQoNCisxDQoNCi1sbg0KDQpPbiBBdWcgMzEsIDIwMTIsIGF0IDg6MjEgQU0sIEFkYW0g TW9udHZpbGxlIHdyb3RlOg0KDQo+IA0KPiBPbiBBdWcgMzAsIDIwMTIsIGF0IDk6MTYgUE0sICJP bWFyIFNhbnRvcyAob3NhbnRvcykiIDxvc2FudG9zQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPj4g WW91IGhhdmUgYW4gZXhjZWxsZW50IHBvaW50IEthdGhsZWVuISEhIA0KPj4gDQo+PiBJIHRoaW5r IHRoYXQgd2UgYXJlIGVhc2lseSBtYWtpbmcgdGhlIHNlbGVjdGlvbiBvZiBhIFdHIG5hbWUgZmFy IG1vcmUgY29tcGxpY2F0ZWQgdGhhbiB0aGUgYWN0dWFsIHN0YW5kYXJkcyB0aGF0IGFyZSBzdXBw b3NlZCB0byBiZSBvdXIgZGVsaXZlcmFibGVzLg0KPj4gDQo+IA0KPiANCj4gQWdyZWVkLiAgSSB3 b3VsZCBtdWNoIHJhdGhlciBiZSBmb2N1c2luZyBvdXIgZW5lcmd5IG9uIGdldHRpbmcgdGhlIGNv bnRlbnQgb2YgdGhlIGNoYXJ0ZXIgZGlzY3Vzc2VkIG1vcmUgY29tcGxldGVseS4gIFRoYXQgc2Fp ZCwgSSdkIGxpa2UgdG8gcHJvcG9zZSB0aGF0IHdlIHRhYmxlIHRoZSBkaXNjdXNzaW9uIG9mIHRo ZSB3b3JraW5nIGdyb3VwIG5hbWUgdW50aWwgQXRsYW50YSAtIHVubGVzcyB0aGVyZSdzIGEgY29t cGVsbGluZyByZWFzb24gdG8gc2V0dGxlIHRoZSBpc3N1ZSBub3cgLSBhbmQgbW92ZSBvbiB0byBj b21wbGV0aW5nIHRoZSBkaXNjdXNzaW9uIG9mIHRoZSBkcmFmdCBjaGFydGVyLg0KPiANCj4gDQo+ PiBEYXZpZCBTb2xpbiBoYWQgYSAqZ3JlYXQqIHBvaW50OiAiV2hlbiB5b3UgaW52ZW50IG5ldyB0 ZXJtcyBmb3IgYW55dGhpbmcgeW91J3JlIHRyeWluZyB0byBpbnRyb2R1Y2UgaW50byB0aGUgbWFy a2V0cGxhY2UsIHlvdSdyZSBzd2ltbWluZyBhZ2FpbnN0IHRoZSBjdXJyZW50LiINCj4+IA0KPj4g SWYgdGhlIElFVEYgY29tbXVuaXR5IGlzIGFscmVhZHkgZmFtaWxpYXIgd2l0aCBTQUNNLCB0aGlz IGFsaWFzIGlzIHNhY20sIHdlIGhhdmUgYmVlbiB0YWxraW5nIGV2ZXJ5dGhpbmcgU0FDTSwgSSBz dWdnZXN0IHdlIHN0YXkgd2l0aCBpdCBmb3Igbm93Lg0KPj4gDQo+PiBNaWtlIEhhbW1lciBhbHNv IGhhZCBhIGdvb2Qgc3VnZ2VzdGlvbiBvZiAiY29tcGxpYW5jZSBtYW5hZ2VtZW50IjsgdGhlcmVm b3JlICJTZWN1cml0eSBBdXRvbWF0aW9uIGFuZCBDb21wbGlhbmNlIE1hbmFnZW1lbnQiLCBzdGls bCBTQ0FNLi4NCj4+IA0KPj4gVG8gYmUgaG9uZXN0LCBJIGFtIG1vcmUgaW50ZXJlc3RlZCB0byBr bm93IHRoZSBhZ3JlZW1lbnRzL2FyZ3VtZW50cyBvZiBVQzEgKyBVQzMgIHZzLiBVQzEgKyBVQzIu Li4NCj4+IA0KPj4gUmVnYXJkcywNCj4+IA0KPj4gT21hciANCj4+IA0KPj4gDQo+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogc2FjbS1ib3VuY2VzQGlldGYub3JnIFttYWls dG86c2FjbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTW9yaWFydHksIEthdGhsZWVu DQo+PiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyOSwgMjAxMiAxMDoxMiBBTQ0KPj4gVG86IE1p Y2hhZWwgSGFtbWVyOyBsbnVuZXpAYzNpc2VjdXJpdHkuY29tDQo+PiBDYzogZGF2aWRAam92YWwu b3JnOyBzYWNtQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW3NhY21dIFBlcmNlcHRpb24gb2Yg dGhlIHRlcm0gIk1vbml0b3JpbmciDQo+PiANCj4+IE9uZSBtb3JlIHBvaW50IHRvIGNvbnNpZGVy IGlzIHRoYXQgdGhlIFdHIG5hbWUgd2lsbCBldmVudHVhbGx5IGdvIGF3YXkgKGFmdGVyIHdlIGFy ZSBkb25lIHdpdGggdGhlIHdvcmsgaXRlbXMgYW5kIGEgZ3JvdXAgaXMgY2xvc2VkIG91dCkgYW5k IHdoYXQgd2lsbCBsaXZlIG9uIGFyZSB0aGUgbmFtZXMgb2Ygc3RhbmRhcmRzIHByb2R1Y2VkIGJ5 IGEgd29ya2luZyBncm91cC4NCj4+IA0KPj4gQmVzdCByZWdhcmRzLA0KPj4gS2F0aGxlZW4gDQo+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBGcm9tOiBzYWNt LWJvdW5jZXNAaWV0Zi5vcmcgW3NhY20tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1p Y2hhZWwgSGFtbWVyIFttaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tXQ0KPj4gU2VudDogV2Vk bmVzZGF5LCBBdWd1c3QgMjksIDIwMTIgMTA6MTAgQU0NCj4+IFRvOiBsbnVuZXpAYzNpc2VjdXJp dHkuY29tDQo+PiBDYzogZGF2aWRAam92YWwub3JnOyBzYWNtQGlldGYub3JnDQo+PiBTdWJqZWN0 OiBSZTogW3NhY21dIFBlcmNlcHRpb24gb2YgdGhlIHRlcm0gIk1vbml0b3JpbmciDQo+PiANCj4+ IEJUVywgdGhlIHJlYXNvbiBJIHVzZWQgdGhvc2UgdHdvIHdvcmRzIHdhcyB0byBiZSBsZXNzIHBy ZWNpc2UuDQo+PiBPbmUgY2FuIHJlYWQgYSBudW1iZXIgb2YgdGhpbmdzIGludG8gYm90aCBjb21w bGlhbmNlIGFuZCBtYW5hZ2VtZW50Lg0KPj4gDQo+PiBZb3UgaGF2ZSB0aGUgb3B0aW9uIG9mIHRy eWluZyB0byBiZSBtb3JlIGdyYW51bGFyIG9yIG1vcmUgc3BlY2lmaWMuDQo+PiBUaGUgZGFuZ2Vy IEkgc2VlIGluIHRvbyBtdWNoIHNwZWNpZmljaXR5IGlzIHRoYXQgeW91IGxlYXZlIG91dCBzb21l b25l4oCZcyBmYXZvcml0ZSBlbGVtZW50Lg0KPj4gQW5kIGhlbmNlIGEgYmF0dGxlIGJldHdlZW4g d2hvc2UgZmF2b3JpdGVzIGdldCBpbiBvciBkb27igJl0Lg0KPj4gDQo+PiBNeSAyIGNlbnRzLiAg Tm93LCBJIHdpbGwgYXZvaWQgY29tbWVudGluZyBhZ2FpbiBsaWtlIHRoZSBwbGFndWUuICDimLoN Cj4+IA0KPj4gRW5qb3ksDQo+PiBNaWtlDQo+PiANCj4+IEZyb206IEx1aXMgTnVuZXogW21haWx0 bzpsbnVuZXpAYzNpc2VjdXJpdHkuY29tXQ0KPj4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjks IDIwMTIgOTo1OCBBTQ0KPj4gVG86IE1pY2hhZWwgSGFtbWVyDQo+PiBDYzogZGF2aWRAam92YWwu b3JnOyBzYWNtQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW3NhY21dIFBlcmNlcHRpb24gb2Yg dGhlIHRlcm0gIk1vbml0b3JpbmciDQo+PiANCj4+IGVhcmx5IG9uIHdlIHJhbiBpbnRvIGlzc3Vl cyB3aXRoIHRoZSB0ZXJtICJjb250aW51b3VzIG1hbmFnZW1lbnQiLiAgTm90IHN1cmUgaWYgdGhl IHdvcmQgIm1hbmFnZW1lbnQiIHdpbGwgaWduaXRlIGFub3RoZXIgc3Rvcm0uDQo+PiANCj4+IFRv IG1lIEkgZG9uJ3Qgc2VlIHdoYXQgdGhlIGJpZyBkZWFsIGlzLiAgU0FDTSBzb3VuZHMgZmluZSB3 aXRoIG1lLiAgSWYgaXQgY2F1c2VzIGNvbnRyb3ZlcnN5IGdyZWF0LiAgR2V0dGluZyBwZW9wbGUg aW50ZXJlc3RlZCBhbmQgZW5nYWdlZCBpcyBhIGdvb2QgdGhpbmcuDQo+PiANCj4+IA0KPj4gLWxu DQo+PiANCj4+IE9uIEF1ZyAyOSwgMjAxMiwgYXQgOTozMSBBTSwgTWljaGFlbCBIYW1tZXIgd3Jv dGU6DQo+PiANCj4+IA0KPj4gT3IganVzdCByZWZlciB0byBpdCBhcyBjb21wbGlhbmNlIG1hbmFn ZW1lbnQuDQo+PiBQcm9iYWJseSBiZXN0IG5vdCB0byBnZXQgdG9vIHNwZWNpZmljIHRvIGZ1dHVy ZS1wcm9vZiBpdC4NCj4+IA0KPj4gSSBhbHdheXMgZ2V0IGFtdXNlZCBob3cgdGhlc2UgbmFtaW5n IHN0b3JtcyB0YWtlIHBsYWNlLg0KPj4gQW5kIGluIHRoZSBlbmQgc29tZW9uZSBpbiBJRVNHIGdl dHMgdGhlIGZpbmFsIHNheS4NCj4+IFlvdSBtaWdodCB3YW50IHRvIHBpbmcgdGhlbSBvbiBtYWdp YyB3b3JkcyB0byBhdm9pZC4NCj4+IFRoYXQgbWlnaHQgY3V0IGRvd24gb24gdGhlIGNodXJuLg0K Pj4gDQo+PiBNaWtlDQo+PiANCj4+IA0KPj4gRnJvbTogc2FjbS1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3Jn XTxtYWlsdG86W21haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YgRGF2 aWQgU29saW4NCj4+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDI5LCAyMDEyIDg6NTYgQU0NCj4+ IFRvOiBzYWNtQGlldGYub3JnPG1haWx0bzpzYWNtQGlldGYub3JnPg0KPj4gU3ViamVjdDogUmU6 IFtzYWNtXSBQZXJjZXB0aW9uIG9mIHRoZSB0ZXJtICJNb25pdG9yaW5nIg0KPj4gDQo+PiBXaGVu IHlvdSBpbnZlbnQgbmV3IHRlcm1zIGZvciBhbnl0aGluZyB5b3UncmUgdHJ5aW5nIHRvIGludHJv ZHVjZSBpbnRvIHRoZSBtYXJrZXRwbGFjZSwgeW91J3JlIHN3aW1taW5nIGFnYWluc3QgdGhlIGN1 cnJlbnQuICBBbHNvLCB3ZSByZWFsbHkgYXJlbid0IGFkZHJlc3NpbmcgbWl0aWdhdGlvbiBhdCB0 aGlzIHBvaW50LiAgSSdtIGFsc28gc3VyZSB0aGUgaWRlYSBvZiBjb250aW51b3VzIG1pdGlnYXRp b24gd291bGQgcmFpc2UgZXllYnJvd3MgZm9yIGFueW9uZSB3aG8gd29ya3MgaW4gYSBjaGFuZ2Ut Y29udHJvbGxlZCBlbnZpcm9ubWVudC4NCj4+IA0KPj4gQW5kLCBzaW5jZSB0aGUgZG9vciBoYXMg YmVlbiBvcGVuZWQgLi4uIEknbSBub3QgYSBmYW4gb2YgU0FDTS4gIEl0J3MgdG9vIGNsb3NlIHRv IFNDQU0uICBJJ2QgaGF0ZSBmb3IgdXMgdG8gaW50cm9kdWNlIGFub3RoZXIgY29udGVudGlvdXMg b3IgdW5mYW1pbGlhciB0ZXJtIHRvIGtlZXAgYSBtYXJnaW5hbCBhY3JvbnltLg0KPj4gDQo+PiBS ZWdhcmRzLA0KPj4gLS1EYXZpZCBTb2xpbg0KPj4gDQo+PiANCj4+IE9uIDgvMjkvMjAxMiA3OjQy IEFNLCBNb3JpYXJ0eSwgS2F0aGxlZW4gd3JvdGU6DQo+PiANCj4+IA0KPj4gDQo+PiBJbnRlcmVz dGluZyBzdWdnZXN0aW9uLCB0aGF0IGNvdWxkIGFsc28gbGV0IHVzIGtlZXAgdGhlIGFjcm9ueW0g YW5kIGxpc3QgaW4gdGFjdCB3aXRoIHRoZSB1c2Ugb2YgYSBsb3dlciBjYXNlIGQuLi4NCj4+IA0K Pj4gDQo+PiANCj4+IFRoYW5rcywNCj4+IA0KPj4gS2F0aGxlZW4NCj4+IA0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gDQo+PiBGcm9tOiBzYWNtLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZz4gW3NhY20tYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEJha2Vy LCBKb24gW2Jha2VyakBtaXRyZS5vcmc8bWFpbHRvOmJha2VyakBtaXRyZS5vcmc+XQ0KPj4gDQo+ PiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyOSwgMjAxMiA4OjI4IEFNDQo+PiANCj4+IFRvOiAn c2FjbScNCj4+IA0KPj4gU3ViamVjdDogUmU6IFtzYWNtXSBQZXJjZXB0aW9uIG9mIHRoZSB0ZXJt ICJNb25pdG9yaW5nIg0KPj4gDQo+PiANCj4+IA0KPj4gSSBiZWxpZXZlIHRoZXJlIGFyZSBzb21l IFVTIEdvdiBsZWFkcyB0aGF0IGFyZSBjb25zaWRlcmluZyB1c2luZyAiY29udGludW91cyBkaWFn bm9zdGljcyBhbmQgTWl0aWdhdGlvbnMiIGFzIGEgcmVwbGFjZW1lbnQgZm9yIGNvbnRpbnVvdXMg bW9uaXRvcmluZy4gSXQgbWlnaHQgYmUgbmljZSB0byBhbGlnbiBzYWNtIHRlcm1zLg0KPj4gDQo+ PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBTZW50IHdpdGggR29vZCAod3d3Lmdvb2Qu Y29tPGh0dHA6Ly93d3cuZ29vZC5jb20+KQ0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiANCj4+IEZyb206IFN0ZXBoZW4gSGFubmEgW3No YW5uYUBqdW5pcGVyLm5ldDxtYWlsdG86c2hhbm5hQGp1bmlwZXIubmV0PjxtYWlsdG86c2hhbm5h QGp1bmlwZXIubmV0PjxtYWlsdG86c2hhbm5hQGp1bmlwZXIubmV0Pl0NCj4+IA0KPj4gU2VudDog V2VkbmVzZGF5LCBBdWd1c3QgMjksIDIwMTIgMDg6MTkgQU0gRWFzdGVybiBTdGFuZGFyZCBUaW1l DQo+PiANCj4+IFRvOiBBZGFtIE1vbnR2aWxsZTsgZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ8bWFp bHRvOmRhdmlkLm9saXZhQHZlcml6b24ubmV0Pjsgc2FjbUBpZXRmLm9yZzxtYWlsdG86c2FjbUBp ZXRmLm9yZz4NCj4+IA0KPj4gQ2M6IEFkYW0gVy4gTW9udHZpbGxlDQo+PiANCj4+IFN1YmplY3Q6 IFJlOiBbc2FjbV0gUGVyY2VwdGlvbiBvZiB0aGUgdGVybSAiTW9uaXRvcmluZyINCj4+IA0KPj4g DQo+PiANCj4+IA0KPj4gDQo+PiBJIGFncmVlLiBNYW55IHVzZXJzIGFyZSB1bmNvbWZvcnRhYmxl IHdpdGggdGhlIGlkZWEgb2YgaGF2aW5nDQo+PiANCj4+IHNvbWVvbmUgb3Igc29tZXRoaW5nIG1v bml0b3JpbmcgdGhlaXIgKmFjdGl2aXRpZXMqLCB3aGljaCBpcw0KPj4gDQo+PiB3aGF0IHBlb3Bs ZSBvZnRlbiB0aGluayB3aGVuIHRoZXkgdGhpbmsgb2YgbW9uaXRvcmluZy4NCj4+IA0KPj4gDQo+ PiANCj4+IEhvd2V2ZXIsIHRoZXJlJ3Mgbm90IG11Y2ggcHJvYmxlbSB3aXRoIHRha2luZyBleGlz dGluZyBzeXN0ZW1zDQo+PiANCj4+IGZvciBjaGVja2luZyBzZWN1cml0eSBjb21wbGlhbmNlIG9m IGNvcnBvcmF0ZS1vd25lZCBkZXZpY2VzIGFuZA0KPj4gDQo+PiBtb3ZpbmcgdGhhdCBmcm9tIHBl cmlvZGljIGFuZCBvY2Nhc2lvbmFsIGNvbXBsaWFuY2UgYXNzZXNzbWVudHMNCj4+IA0KPj4gdG8g Y29udGludW91cyBvbmVzLiBJIHRoaW5rIHRoYXQncyB3aGF0IHdlJ3JlIHRhbGtpbmcgYWJvdXQg aGVyZS4NCj4+IA0KPj4gDQo+PiANCj4+IFNvIEkgdGhpbmsgdGhhdCAiY29udGludW91cyBjb21w bGlhbmNlIiBvciAiY29udGludW91cyBhc3Nlc3NtZW50Ig0KPj4gDQo+PiB3b3VsZCBiZSBhIGdv b2QgdGVybXMuIExldCdzIGRyb3AgdGhlIHdvcmQgIm1vbml0b3JpbmciIGFsdG9nZXRoZXINCj4+ IA0KPj4gc2luY2UgaXQgaXMgb2Z0ZW4gbWlzdW5kZXJzdG9vZC4NCj4+IA0KPj4gDQo+PiANCj4+ IFRoYW5rcywNCj4+IA0KPj4gDQo+PiANCj4+IFN0ZXZlDQo+PiANCj4+IA0KPj4gDQo+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gDQo+PiBGcm9tOiBzYWNtLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpzYWNtLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZg0KPj4gDQo+PiBBZGFtIE1vbnR2aWxsZQ0KPj4gDQo+PiBTZW50 OiBXZWRuZXNkYXksIEF1Z3VzdCAyOSwgMjAxMiA4OjA4IEFNDQo+PiANCj4+IFRvOiBkYXZpZC5v bGl2YUB2ZXJpem9uLm5ldDxtYWlsdG86ZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ+OyBzYWNtQGll dGYub3JnPG1haWx0bzpzYWNtQGlldGYub3JnPg0KPj4gDQo+PiBDYzogQWRhbSBXLiBNb250dmls bGUNCj4+IA0KPj4gU3ViamVjdDogUmU6IFtzYWNtXSBQZXJjZXB0aW9uIG9mIHRoZSB0ZXJtICJN b25pdG9yaW5nIg0KPj4gDQo+PiANCj4+IA0KPj4gUmVzcG9uZGluZyBvbiB2YWNhdGlvbiAtIGNv cHlpbmcgYSBwZXJzb25hbCBhZGRyZXNzIGZvciBvZmYtdGhyZWFkDQo+PiANCj4+IGNvbnRhY3Qs IGlmIG5lZWRlZC4NCj4+IA0KPj4gDQo+PiANCj4+IFJlbWFpbmluZyBjb21tZW50cyBpbmxpbmUu DQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gT24gOC8yOS8xMiA1OjAxIEFNLCAiZGF2aWQu b2xpdmFAdmVyaXpvbi5uZXQiPG1haWx0bzpkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldD4gPGRhdmlk Lm9saXZhQHZlcml6b24ubmV0PjxtYWlsdG86ZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ+DQo+PiAN Cj4+IHdyb3RlOg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0K Pj4gDQo+PiANCj4+IEEgbGFyZ2UgbnVtYmVyIG9mIGhpdHMgYXNzb2NpYXRlIG1vbml0b3Jpbmcg d2l0aCBlbXBsb3llZSBtb25pdG9yaW5nLA0KPj4gDQo+PiBldGhpY2FsIG1vbml0b3JpbmcsIHRl bGVwaG9uZS11c2UgZW1wbG95ZWUgbW9uaXRvcmluZywgcGVyZm9ybWFuY2UNCj4+IA0KPj4gbW9u aXRvcmluZywgY29tcHV0ZXIgYmVoYXZpb3IgbW9uaXRvcmluZywNCj4+IA0KPj4gZXRjLg0KPj4g DQo+PiBQZXJoYXBzIGl0IGlzIG5vdCBhIGJhZCBpZGVhIHRvIGRpc3NvY2lhdGUgdGhlIFNBQ00g ZWZmb3J0IGZyb20gdGhlDQo+PiANCj4+IHBlcmNlaXZlZCBpbXByZXNzaW9uIHRoYXQgd2UgYXJl IGJ1aWxkaW5nIHRvb2xzIGZvciBhIMKzQmlnIEJyb3RoZXLCsg0KPj4gDQo+PiBraW5kDQo+PiAN Cj4+IG9mIHNvY2lldHkuDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IFRo YW5rcyBmb3IgdGhlIGFkZGl0aW9uYWwgaW5zaWdodCwgRGF2aWQgLSBJIHRoaW5rIGl0IGJvbHN0 ZXJzIHRoZSBjYXNlDQo+PiANCj4+IG5pY2VseS4NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+ PiANCj4+IA0KPj4gDQo+PiANCj4+IERhdmlkIE9saXZhDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+ IA0KPj4gDQo+PiANCj4+IE9uIDA4LzI3LzEyLA0KPj4gDQo+PiBEYXZpZCBTb2xpbjxkYXZpZEBq b3ZhbC5vcmc+PG1haWx0bzpkYXZpZEBqb3ZhbC5vcmc+IHdyb3RlOg0KPj4gDQo+PiANCj4+IA0K Pj4gDQo+PiANCj4+IEdvb2dsZSAiY29udGludW91cyBtb25pdG9yaW5nIiAofjcgbWlsbGlvbiBy ZXN1bHRzKSwgYW5kIHlvdSdsbCBzZWUNCj4+IA0KPj4gd2h5DQo+PiANCj4+IHBlb3BsZSB3aG8g aGF2ZSBzcGVudCBhIGxvbmcgdGltZSB3b3JraW5nIHdpdGggdGhlIFVTIGdvdmVybm1lbnQgdGhp bmsNCj4+IA0KPj4gaXQncyBhIGdvb2QgZml0IGZvciB3aGF0IHdlJ3JlIHRhbGtpbmcgYWJvdXQu DQo+PiANCj4+IA0KPj4gDQo+PiBHb29nbGUgImNvbnRpbnVvdXMgY29tcGxpYW5jZSIgKH40OCBt aWxsaW9uIHJlc3VsdHMpLCBhbmQgeW91J2xsIHNlZQ0KPj4gDQo+PiB3aHkNCj4+IA0KPj4gcGVv cGxlIHdobyBoYXZlIHNwZW50IGEgbG9uZyB0aW1lIHdvcmtpbmcgd2l0aCBjb21tZXJjaWFsIGVu dGVycHJpc2UNCj4+IA0KPj4gc29mdHdhcmUgdGhpbmsgaXQncyBhIGdvb2QgZml0IGZvciB3aGF0 IHdlJ3JlIHRhbGtpbmcgYWJvdXQuICBZb3UnbGwNCj4+IA0KPj4gYWxzbw0KPj4gDQo+PiBub3Rp Y2UgYSBsb3Qgb2YgdGhlIHNhbWUgbGlua3MgZnJvbSB0aGUgZmlyc3QNCj4+IA0KPj4gbGlzdC4N Cj4+IA0KPj4gDQo+PiANCj4+IEFuZCB0aGF0J3Mgd2h5IEkgdGhpbmsgImNvbnRpbnVvdXMgY29t cGxpYW5jZSIgaXMgYSBiZXR0ZXIgZml0LiAgSXQNCj4+IA0KPj4gYWxzbw0KPj4gDQo+PiBoYXMg dGhlIGJlbmVmaXQgb2YgYmVpbmcgaW4gY3VycmVudCB1c2UgYnkgdmVuZG9ycyBhbmQgYW5hbHlz dHMsIGFuZA0KPj4gDQo+PiBzbw0KPj4gDQo+PiB0aGUgbWFya2V0cGxhY2Ugd291bGRuJ3QgbmVl ZCB0byBiZSB0cmFpbmVkIHRvIHVuZGVyc3RhbmQgaXQuDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+ IA0KPj4gDQo+PiANCj4+IEl0J3MgdGhlICJjb250aW51b3VzIiBwYXJ0IHRoYXQgbWF0dGVycyB0 byB0aGUgZWZmb3J0LCBub3QgdGhlDQo+PiANCj4+ICJtb25pdG9yaW5nIiBwYXJ0Lg0KPj4gDQo+ PiANCj4+IA0KPj4gVG8gbWUsIGl0J3MgMTAwJSBhY2NlcHRhYmxlIHRvIGRyb3AgdGhlIHRlcm0g Im1vbml0b3JpbmciIGluIGZhdm9yIG9mIGENCj4+IA0KPj4gcmVwbGFjZW1lbnQsIGFuZCBJIHdv dWxkLCBpbiBmYWN0LCBwcmVmZXIgdG8gZG8gc28uDQo+PiANCj4+IA0KPj4gDQo+PiBPdGhlcnM/ DQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiANCj4+IHNhY20gbWFpbGluZyBsaXN0 DQo+PiANCj4+IHNhY21AaWV0Zi5vcmc8bWFpbHRvOnNhY21AaWV0Zi5vcmc+DQo+PiANCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbQ0KPj4gDQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gDQo+PiBzYWNtIG1h aWxpbmcgbGlzdA0KPj4gDQo+PiBzYWNtQGlldGYub3JnPG1haWx0bzpzYWNtQGlldGYub3JnPg0K Pj4gDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20NCj4+IA0K Pj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiANCj4+IHNhY20gbWFpbGluZyBsaXN0DQo+PiANCj4+IHNhY21AaWV0Zi5vcmc8bWFp bHRvOnNhY21AaWV0Zi5vcmc+DQo+PiANCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2FjbQ0KPj4gDQo+PiAtLQ0KPj4gDQo+PiBqT1ZBTC5vcmc8aHR0cDovL2pPVkFM Lm9yZz46IE9WQUwgaW1wbGVtZW50ZWQgaW4gSmF2YS4NCj4+IFNjYW4gYW55IG1hY2hpbmUgZnJv bSBhbnkgbWFjaGluZS4gRm9yIGZyZWUhDQo+PiBMZWFybiBNb3JlPGh0dHA6Ly93d3cuam92YWwu b3JnPiB8IEZlYXR1cmVzPGh0dHA6Ly93d3cuam92YWwub3JnL2ZlYXR1cmVzLz4gfCBEb3dubG9h ZDxodHRwOi8vd3d3LmpvdmFsLm9yZy9kb3dubG9hZC8+DQo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2FjbSBtYWlsaW5nIGxpc3QNCj4+IHNh Y21AaWV0Zi5vcmc8bWFpbHRvOnNhY21AaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NhY20NCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNhY20gbWFpbGluZyBsaXN0DQo+PiBzYWNtQGll dGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20NCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzYWNt IG1haWxpbmcgbGlzdA0KPj4gc2FjbUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zYWNtDQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kc2FjbSBtYWlsaW5nIGxpc3QNCnNhY21AaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbQ0K From solin@farnamhallventures.com Fri Aug 31 11:00:12 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2982121F8610 for ; Fri, 31 Aug 2012 11:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-1.929, BAYES_00=-2.599, FRT_PROFIT1=3.858, 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 LWTauedRGqPq for ; Fri, 31 Aug 2012 11:00:10 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5208C21F84B9 for ; Fri, 31 Aug 2012 11:00:09 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so6783560obb.31 for ; Fri, 31 Aug 2012 11:00:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type:x-gm-message-state; bh=3FSdsrmp68GfUamFOv+0NYwXpQtFt1RM6Aoyw9ZiFkE=; b=TqU5vyPBCJug5Cg6JJSj/sHW3ZBUSTOwDm6hI4QMkyEpHAva6IQyxNZysvEN/x2hGq E+tEtQyywNDatfft/O1HpJ2QLT6PRQytONpb3PNyzX0gh9HAKtH5v886uxCamC0EnQTk Sbv0l/xLRYt/4Xoty8YTaXkIa+kM4WqUFfaW+/PyTvKukDOJHMDpj8TbHVoRAAnV4uaK dt7U4XHHAXVho4vaWDBFzVsphF9kTPOR3MIwYHvybJOrGAd9so8g0+0JhBD2BfLdaYgK DTJulTdwIEyKuuRWK5s0gXBQcDqLm+KQSC8uXgaqHOCRxHYOWidj6xVPRf/pgdBfL4mt 5+Cg== Received: by 10.60.170.229 with SMTP id ap5mr8641169oec.101.1346436009412; Fri, 31 Aug 2012 11:00:09 -0700 (PDT) Received: from [192.168.0.113] (cpe-70-123-137-202.austin.res.rr.com. [70.123.137.202]) by mx.google.com with ESMTPS id i2sm4527804obn.19.2012.08.31.11.00.07 (version=SSLv3 cipher=OTHER); Fri, 31 Aug 2012 11:00:08 -0700 (PDT) Sender: David Solin Message-ID: <5040FBA2.6040109@joval.org> Date: Fri, 31 Aug 2012 13:00:02 -0500 From: David Solin Organization: jOVAL User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Waltermire, David A." References: <6C1C15D8B5510B4B8FF132B10D386513020ED179@IMCMBX03.MITRE.ORG> <503E1162.4080703@joval.org> <00C069FD01E0324C9FFCADF539701DB31336F74E@ex2k10mb2.corp.yaanatech.com> <2FB0493A-7FFE-4B76-B394-4C8D107AA160@c3isecurity.com>, <00C069FD01E0324C9FFCADF539701DB31336F81E@ex2k10mb2.corp.yaanatech.com> <93ED586BE669044CA2F91C5F3BE4FD9017B827C5@xmb-rcd-x09.cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030903030406000106080501" X-Gm-Message-State: ALoCoQmBhb+YeRC1VoIh0o0wMAgf3IeDdB44rLKhn/IJ9dxilzdtV96yi0z3iRsCgx+gSH7JoXwe Cc: Adam Montville , "sacm@ietf.org" , "Moriarty, Kathleen" , Luis Nunez , Michael Hammer , "Omar Santos \(osantos\)" Subject: Re: [sacm] Perception 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: Fri, 31 Aug 2012 18:00:12 -0000 This is a multi-part message in MIME format. --------------030903030406000106080501 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I agree it's a fine idea, switching Continuous for Compliance, for the sake of both clarity (or politics) and re-use of a name that is just temporary anyway. On 8/31/2012 12:57 PM, Waltermire, David A. wrote: > +1 > > Sincerely, > Dave > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Luis Nunez > Sent: Friday, August 31, 2012 11:32 AM > To: Adam Montville > Cc: Michael Hammer; david@joval.org; Moriarty, Kathleen; sacm@ietf.org; Omar Santos (osantos) > Subject: Re: [sacm] Perception of the term "Monitoring" > > +1 > > -ln > > On Aug 31, 2012, at 8:21 AM, Adam Montville wrote: > >> On Aug 30, 2012, at 9:16 PM, "Omar Santos (osantos)" wrote: >> >>> You have an excellent point Kathleen!!! >>> >>> I think that we are easily making the selection of a WG name far more complicated than the actual standards that are supposed to be our deliverables. >>> >> >> Agreed. I would much rather be focusing our energy on getting the content of the charter discussed more completely. That said, I'd like to propose that we table the discussion of the working group name until Atlanta - unless there's a compelling reason to settle the issue now - and move on to completing the discussion of the draft charter. >> >> >>> David Solin had a *great* point: "When you invent new terms for anything you're trying to introduce into the marketplace, you're swimming against the current." >>> >>> If the IETF community is already familiar with SACM, this alias is sacm, we have been talking everything SACM, I suggest we stay with it for now. >>> >>> Mike Hammer also had a good suggestion of "compliance management"; therefore "Security Automation and Compliance Management", still SCAM.. >>> >>> To be honest, I am more interested to know the agreements/arguments of UC1 + UC3 vs. UC1 + UC2... >>> >>> Regards, >>> >>> Omar >>> >>> >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Moriarty, Kathleen >>> Sent: Wednesday, August 29, 2012 10:12 AM >>> To: Michael Hammer; lnunez@c3isecurity.com >>> Cc: david@joval.org; sacm@ietf.org >>> Subject: Re: [sacm] Perception of the term "Monitoring" >>> >>> One more point to consider is that the WG name will eventually go away (after we are done with the work items and a group is closed out) and what will live on are the names of standards produced by a working group. >>> >>> Best regards, >>> Kathleen >>> ________________________________________ >>> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Michael Hammer [michael.hammer@yaanatech.com] >>> Sent: Wednesday, August 29, 2012 10:10 AM >>> To: lnunez@c3isecurity.com >>> Cc: david@joval.org; sacm@ietf.org >>> Subject: Re: [sacm] Perception of the term "Monitoring" >>> >>> BTW, the reason I used those two words was to be less precise. >>> One can read a number of things into both compliance and management. >>> >>> You have the option of trying to be more granular or more specific. >>> The danger I see in too much specificity is that you leave out someone’s favorite element. >>> And hence a battle between whose favorites get in or don’t. >>> >>> My 2 cents. Now, I will avoid commenting again like the plague. ☺ >>> >>> Enjoy, >>> Mike >>> >>> From: Luis Nunez [mailto:lnunez@c3isecurity.com] >>> Sent: Wednesday, August 29, 2012 9:58 AM >>> To: Michael Hammer >>> Cc: david@joval.org; sacm@ietf.org >>> Subject: Re: [sacm] Perception of the term "Monitoring" >>> >>> early on we ran into issues with the term "continuous management". Not sure if the word "management" will ignite another storm. >>> >>> To me I don't see what the big deal is. SACM sounds fine with me. If it causes controversy great. Getting people interested and engaged is a good thing. >>> >>> >>> -ln >>> >>> On Aug 29, 2012, at 9:31 AM, Michael Hammer wrote: >>> >>> >>> Or just refer to it as compliance management. >>> Probably best not to get too specific to future-proof it. >>> >>> I always get amused how these naming storms take place. >>> And in the end someone in IESG gets the final say. >>> You might want to ping them on magic words to avoid. >>> That might cut down on the churn. >>> >>> Mike >>> >>> >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of David Solin >>> Sent: Wednesday, August 29, 2012 8:56 AM >>> To: sacm@ietf.org >>> Subject: Re: [sacm] Perception of the term "Monitoring" >>> >>> When you invent new terms for anything you're trying to introduce into the marketplace, you're swimming against the current. Also, we really aren't addressing mitigation at this point. I'm also sure the idea of continuous mitigation would raise eyebrows for anyone who works in a change-controlled environment. >>> >>> And, since the door has been opened ... I'm not a fan of SACM. It's too close to SCAM. I'd hate for us to introduce another contentious or unfamiliar term to keep a marginal acronym. >>> >>> Regards, >>> --David Solin >>> >>> >>> On 8/29/2012 7:42 AM, Moriarty, Kathleen wrote: >>> >>> >>> >>> Interesting suggestion, that could also let us keep the acronym and list in tact with the use of a lower case d... >>> >>> >>> >>> Thanks, >>> >>> Kathleen >>> >>> ________________________________________ >>> >>> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Baker, Jon [bakerj@mitre.org] >>> >>> Sent: Wednesday, August 29, 2012 8:28 AM >>> >>> To: 'sacm' >>> >>> Subject: Re: [sacm] Perception of the term "Monitoring" >>> >>> >>> >>> I believe there are some US Gov leads that are considering using "continuous diagnostics and Mitigations" as a replacement for continuous monitoring. It might be nice to align sacm terms. >>> >>> >>> >>> >>> >>> >>> >>> Sent with Good (www.good.com) >>> >>> >>> >>> >>> >>> -----Original Message----- >>> >>> From: Stephen Hanna [shanna@juniper.net] >>> >>> Sent: Wednesday, August 29, 2012 08:19 AM Eastern Standard Time >>> >>> To: Adam Montville; david.oliva@verizon.net; sacm@ietf.org >>> >>> Cc: Adam W. Montville >>> >>> Subject: Re: [sacm] Perception of the term "Monitoring" >>> >>> >>> >>> >>> >>> I agree. Many users are uncomfortable with the idea of having >>> >>> someone or something monitoring their *activities*, which is >>> >>> what people often think when they think of monitoring. >>> >>> >>> >>> However, there's not much problem with taking existing systems >>> >>> for checking security compliance of corporate-owned devices and >>> >>> moving that from periodic and occasional compliance assessments >>> >>> to continuous ones. I think that's what we're talking about here. >>> >>> >>> >>> So I think that "continuous compliance" or "continuous assessment" >>> >>> would be a good terms. Let's drop the word "monitoring" altogether >>> >>> since it is often misunderstood. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Steve >>> >>> >>> >>> -----Original Message----- >>> >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >>> >>> Adam Montville >>> >>> Sent: Wednesday, August 29, 2012 8:08 AM >>> >>> To: david.oliva@verizon.net; sacm@ietf.org >>> >>> Cc: Adam W. Montville >>> >>> Subject: Re: [sacm] Perception of the term "Monitoring" >>> >>> >>> >>> Responding on vacation - copying a personal address for off-thread >>> >>> contact, if needed. >>> >>> >>> >>> Remaining comments inline. >>> >>> >>> >>> >>> >>> On 8/29/12 5:01 AM, "david.oliva@verizon.net" >>> >>> wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> A large number of hits associate monitoring with employee monitoring, >>> >>> ethical monitoring, telephone-use employee monitoring, performance >>> >>> monitoring, computer behavior monitoring, >>> >>> etc. >>> >>> Perhaps it is not a bad idea to dissociate the SACM effort from the >>> >>> perceived impression that we are building tools for a ³Big Brother² >>> >>> kind >>> >>> of society. >>> >>> >>> >>> >>> >>> >>> >>> Thanks for the additional insight, David - I think it bolsters the case >>> >>> nicely. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> David Oliva >>> >>> >>> >>> >>> >>> >>> >>> On 08/27/12, >>> >>> David Solin wrote: >>> >>> >>> >>> >>> >>> Google "continuous monitoring" (~7 million results), and you'll see >>> >>> why >>> >>> people who have spent a long time working with the US government think >>> >>> it's a good fit for what we're talking about. >>> >>> >>> >>> Google "continuous compliance" (~48 million results), and you'll see >>> >>> why >>> >>> people who have spent a long time working with commercial enterprise >>> >>> software think it's a good fit for what we're talking about. You'll >>> >>> also >>> >>> notice a lot of the same links from the first >>> >>> list. >>> >>> >>> >>> And that's why I think "continuous compliance" is a better fit. It >>> >>> also >>> >>> has the benefit of being in current use by vendors and analysts, and >>> >>> so >>> >>> the marketplace wouldn't need to be trained to understand it. >>> >>> >>> >>> >>> >>> >>> >>> It's the "continuous" part that matters to the effort, not the >>> >>> "monitoring" part. >>> >>> >>> >>> To me, it's 100% acceptable to drop the term "monitoring" in favor of a >>> >>> replacement, and I would, in fact, prefer to do so. >>> >>> >>> >>> Others? >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> sacm mailing 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 >>> >>> -- >>> >>> jOVAL.org: OVAL implemented in Java. >>> Scan any machine from any machine. For free! >>> Learn More | Features | Download >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >>> >>> _______________________________________________ >>> sacm mailing 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 -- jOVAL.org: OVAL implemented in Java. /Scan any machine from any machine. For free!/ Learn More | Features | Download --------------030903030406000106080501 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
I agree it's a fine idea, switching Continuous for Compliance, for the sake of both clarity (or politics) and re-use of a name that is just temporary anyway.

On 8/31/2012 12:57 PM, Waltermire, David A. wrote:
+1

Sincerely,
Dave

-----Original Message-----
From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Luis Nunez
Sent: Friday, August 31, 2012 11:32 AM
To: Adam Montville
Cc: Michael Hammer; david@joval.org; Moriarty, Kathleen; sacm@ietf.org; Omar Santos (osantos)
Subject: Re: [sacm] Perception of the term "Monitoring"

+1

-ln

On Aug 31, 2012, at 8:21 AM, Adam Montville wrote:


On Aug 30, 2012, at 9:16 PM, "Omar Santos (osantos)" <osantos@cisco.com> wrote:


You have an excellent point Kathleen!!! 

I think that we are easily making the selection of a WG name far more complicated than the actual standards that are supposed to be our deliverables.



Agreed.  I would much rather be focusing our energy on getting the content of the charter discussed more completely.  That said, I'd like to propose that we table the discussion of the working group name until Atlanta - unless there's a compelling reason to settle the issue now - and move on to completing the discussion of the draft charter.



David Solin had a *great* point: "When you invent new terms for anything you're trying to introduce into the marketplace, you're swimming against the current."

If the IETF community is already familiar with SACM, this alias is sacm, we have been talking everything SACM, I suggest we stay with it for now.

Mike Hammer also had a good suggestion of "compliance management"; therefore "Security Automation and Compliance Management", still SCAM..

To be honest, I am more interested to know the agreements/arguments of UC1 + UC3  vs. UC1 + UC2...

Regards,

Omar 


-----Original Message-----
From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Moriarty, Kathleen
Sent: Wednesday, August 29, 2012 10:12 AM
To: Michael Hammer; lnunez@c3isecurity.com
Cc: david@joval.org; sacm@ietf.org
Subject: Re: [sacm] Perception of the term "Monitoring"

One more point to consider is that the WG name will eventually go away (after we are done with the work items and a group is closed out) and what will live on are the names of standards produced by a working group.

Best regards,
Kathleen 
________________________________________
From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Michael Hammer [michael.hammer@yaanatech.com]
Sent: Wednesday, August 29, 2012 10:10 AM
To: lnunez@c3isecurity.com
Cc: david@joval.org; sacm@ietf.org
Subject: Re: [sacm] Perception of the term "Monitoring"

BTW, the reason I used those two words was to be less precise.
One can read a number of things into both compliance and management.

You have the option of trying to be more granular or more specific.
The danger I see in too much specificity is that you leave out someone’s favorite element.
And hence a battle between whose favorites get in or don’t.

My 2 cents.  Now, I will avoid commenting again like the plague.  ☺

Enjoy,
Mike

From: Luis Nunez [mailto:lnunez@c3isecurity.com]
Sent: Wednesday, August 29, 2012 9:58 AM
To: Michael Hammer
Cc: david@joval.org; sacm@ietf.org
Subject: Re: [sacm] Perception of the term "Monitoring"

early on we ran into issues with the term "continuous management".  Not sure if the word "management" will ignite another storm.

To me I don't see what the big deal is.  SACM sounds fine with me.  If it causes controversy great.  Getting people interested and engaged is a good thing.


-ln

On Aug 29, 2012, at 9:31 AM, Michael Hammer wrote:


Or just refer to it as compliance management.
Probably best not to get too specific to future-proof it.

I always get amused how these naming storms take place.
And in the end someone in IESG gets the final say.
You might want to ping them on magic words to avoid.
That might cut down on the churn.

Mike


From: sacm-bounces@ietf.org<mailto:sacm-bounces@ietf.org> [mailto:sacm-bounces@ietf.org]<mailto:[mailto:sacm-bounces@ietf.org]> On Behalf Of David Solin
Sent: Wednesday, August 29, 2012 8:56 AM
To: sacm@ietf.org<mailto:sacm@ietf.org>
Subject: Re: [sacm] Perception of the term "Monitoring"

When you invent new terms for anything you're trying to introduce into the marketplace, you're swimming against the current.  Also, we really aren't addressing mitigation at this point.  I'm also sure the idea of continuous mitigation would raise eyebrows for anyone who works in a change-controlled environment.

And, since the door has been opened ... I'm not a fan of SACM.  It's too close to SCAM.  I'd hate for us to introduce another contentious or unfamiliar term to keep a marginal acronym.

Regards,
--David Solin


On 8/29/2012 7:42 AM, Moriarty, Kathleen wrote:



Interesting suggestion, that could also let us keep the acronym and list in tact with the use of a lower case d...



Thanks,

Kathleen

________________________________________

From: sacm-bounces@ietf.org<mailto:sacm-bounces@ietf.org> [sacm-bounces@ietf.org<mailto:sacm-bounces@ietf.org>] On Behalf Of Baker, Jon [bakerj@mitre.org<mailto:bakerj@mitre.org>]

Sent: Wednesday, August 29, 2012 8:28 AM

To: 'sacm'

Subject: Re: [sacm] Perception of the term "Monitoring"



I believe there are some US Gov leads that are considering using "continuous diagnostics and Mitigations" as a replacement for continuous monitoring. It might be nice to align sacm terms.







Sent with Good (www.good.com<http://www.good.com>)





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

From: Stephen Hanna [shanna@juniper.net<mailto:shanna@juniper.net><mailto:shanna@juniper.net><mailto:shanna@juniper.net>]

Sent: Wednesday, August 29, 2012 08:19 AM Eastern Standard Time

To: Adam Montville; david.oliva@verizon.net<mailto:david.oliva@verizon.net>; sacm@ietf.org<mailto:sacm@ietf.org>

Cc: Adam W. Montville

Subject: Re: [sacm] Perception of the term "Monitoring"





I agree. Many users are uncomfortable with the idea of having

someone or something monitoring their *activities*, which is

what people often think when they think of monitoring.



However, there's not much problem with taking existing systems

for checking security compliance of corporate-owned devices and

moving that from periodic and occasional compliance assessments

to continuous ones. I think that's what we're talking about here.



So I think that "continuous compliance" or "continuous assessment"

would be a good terms. Let's drop the word "monitoring" altogether

since it is often misunderstood.



Thanks,



Steve



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

From: sacm-bounces@ietf.org<mailto:sacm-bounces@ietf.org> [mailto:sacm-bounces@ietf.org] On Behalf Of

Adam Montville

Sent: Wednesday, August 29, 2012 8:08 AM

To: david.oliva@verizon.net<mailto:david.oliva@verizon.net>; sacm@ietf.org<mailto:sacm@ietf.org>

Cc: Adam W. Montville

Subject: Re: [sacm] Perception of the term "Monitoring"



Responding on vacation - copying a personal address for off-thread

contact, if needed.



Remaining comments inline.





On 8/29/12 5:01 AM, "david.oliva@verizon.net"<mailto:david.oliva@verizon.net> <david.oliva@verizon.net><mailto:david.oliva@verizon.net>

wrote:











A large number of hits associate monitoring with employee monitoring,

ethical monitoring, telephone-use employee monitoring, performance

monitoring, computer behavior monitoring,

etc.

Perhaps it is not a bad idea to dissociate the SACM effort from the

perceived impression that we are building tools for a ³Big Brother²

kind

of society.







Thanks for the additional insight, David - I think it bolsters the case

nicely.









David Oliva







On 08/27/12,

David Solin<david@joval.org><mailto:david@joval.org> wrote:





Google "continuous monitoring" (~7 million results), and you'll see

why

people who have spent a long time working with the US government think

it's a good fit for what we're talking about.



Google "continuous compliance" (~48 million results), and you'll see

why

people who have spent a long time working with commercial enterprise

software think it's a good fit for what we're talking about.  You'll

also

notice a lot of the same links from the first

list.



And that's why I think "continuous compliance" is a better fit.  It

also

has the benefit of being in current use by vendors and analysts, and

so

the marketplace wouldn't need to be trained to understand it.







It's the "continuous" part that matters to the effort, not the

"monitoring" part.



To me, it's 100% acceptable to drop the term "monitoring" in favor of a

replacement, and I would, in fact, prefer to do so.



Others?







_______________________________________________

sacm mailing list

sacm@ietf.org<mailto:sacm@ietf.org>

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

_______________________________________________

sacm mailing list

sacm@ietf.org<mailto:sacm@ietf.org>

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



_______________________________________________

sacm mailing list

sacm@ietf.org<mailto:sacm@ietf.org>

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

--

jOVAL.org<http://jOVAL.org>: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More<http://www.joval.org> | Features<http://www.joval.org/features/> | Download<http://www.joval.org/download/>
_______________________________________________
sacm mailing list
sacm@ietf.org<mailto:sacm@ietf.org>
https://www.ietf.org/mailman/listinfo/sacm

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


      

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


    

    

    

    
-- 

      
 jOVAL.org:
          OVAL implemented in Java.

        Scan any machine from any machine. For
          free!

        Learn More
        | Features
        | Download
      

    

  


--------------030903030406000106080501--

From kgoodier@comcast.net  Fri Aug 31 11:14: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 E572221F8578 for ; Fri, 31 Aug 2012 11:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.182
X-Spam-Level: 
X-Spam-Status: No, score=-95.182 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_PROFIT1=3.858, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 PBTRqj7MqtMF for ; Fri, 31 Aug 2012 11:14:12 -0700 (PDT)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id CB25B21F8577 for ; Fri, 31 Aug 2012 11:14:11 -0700 (PDT)
Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta13.westchester.pa.mail.comcast.net with comcast id tQvY1j0081wpRvQ5DWEFra; Fri, 31 Aug 2012 18:14:15 +0000
Received: from [10.46.213.237] ([198.228.199.166]) by omta18.westchester.pa.mail.comcast.net with comcast id tWKb1j00E3buF1S3eWKeeT; Fri, 31 Aug 2012 18:19:48 +0000
References: 
In-Reply-To: 
Mime-Version: 1.0 (iPhone Mail 8J2)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary=Apple-Mail-4-909635385
Message-Id: <77F942EF-B4E9-4AD9-90F5-A6722FAB2A31@comcast.net>
Cc: "sacm@ietf.org" 
X-Mailer: iPhone Mail (8J2)
From: k Goodier 
Date: Fri, 31 Aug 2012 14:08:52 -0400
To: "sacm@ietf.org" 
Subject: Re: [sacm] sacm Digest, Vol 6, Issue 77
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Aug 2012 18:14:14 -0000

--Apple-Mail-4-909635385
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1

K

On Aug 31, 2012, at 2:00 PM, sacm-request@ietf.org wrote:

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to=20
>=20
> https://www.ietf.org/mailman/listinfo/sacm
>=20
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>=20
>=20
>=20
> Send sacm mailing list submissions to
>    sacm@ietf.org
>=20
> To subscribe or unsubscribe via the World Wide Web, visit
>    https://www.ietf.org/mailman/listinfo/sacm
> or, via email, send a message with subject or body 'help' to
>    sacm-request@ietf.org
>=20
> You can reach the person managing the list at
>    sacm-owner@ietf.org
>=20
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of sacm digest..."
> Today's Topics:
>=20
>   1. Re: Perception of the term "Monitoring" (David Solin)
> I agree it's a fine idea, switching Continuous for Compliance, for the sak=
e of both clarity (or politics) and re-use of a name that is just temporary a=
nyway.
>=20
> On 8/31/2012 12:57 PM, Waltermire, David A. wrote:
>> +1
>>=20
>> Sincerely,
>> Dave
>>=20
>> -----Original Message-----
>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of L=
uis Nunez
>> Sent: Friday, August 31, 2012 11:32 AM
>> To: Adam Montville
>> Cc: Michael Hammer; david@joval.org; Moriarty, Kathleen; sacm@ietf.org; O=
mar Santos (osantos)
>> Subject: Re: [sacm] Perception of the term "Monitoring"
>>=20
>> +1
>>=20
>> -ln
>>=20
>> On Aug 31, 2012, at 8:21 AM, Adam Montville wrote:
>>=20
>>> On Aug 30, 2012, at 9:16 PM, "Omar Santos (osantos)" =
 wrote:
>>>=20
>>>> You have an excellent point Kathleen!!!=20
>>>>=20
>>>> I think that we are easily making the selection of a WG name far more c=
omplicated than the actual standards that are supposed to be our deliverable=
s.
>>>>=20
>>>=20
>>> Agreed.  I would much rather be focusing our energy on getting the conte=
nt of the charter discussed more completely.  That said, I'd like to propose=
 that we table the discussion of the working group name until Atlanta - unle=
ss there's a compelling reason to settle the issue now - and move on to comp=
leting the discussion of the draft charter.
>>>=20
>>>=20
>>>> David Solin had a *great* point: "When you invent new terms for anythin=
g you're trying to introduce into the marketplace, you're swimming against t=
he current."
>>>>=20
>>>> If the IETF community is already familiar with SACM, this alias is sacm=
, we have been talking everything SACM, I suggest we stay with it for now.
>>>>=20
>>>> Mike Hammer also had a good suggestion of "compliance management"; ther=
efore "Security Automation and Compliance Management", still SCAM..
>>>>=20
>>>> To be honest, I am more interested to know the agreements/arguments of U=
C1 + UC3  vs. UC1 + UC2...
>>>>=20
>>>> Regards,
>>>>=20
>>>> Omar=20
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of=
 Moriarty, Kathleen
>>>> Sent: Wednesday, August 29, 2012 10:12 AM
>>>> To: Michael Hammer; lnunez@c3isecurity.com
>>>> Cc: david@joval.org; sacm@ietf.org
>>>> Subject: Re: [sacm] Perception of the term "Monitoring"
>>>>=20
>>>> One more point to consider is that the WG name will eventually go away (=
after we are done with the work items and a group is closed out) and what wi=
ll live on are the names of standards produced by a working group.
>>>>=20
>>>> Best regards,
>>>> Kathleen=20
>>>> ________________________________________
>>>> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Michae=
l Hammer [michael.hammer@yaanatech.com]
>>>> Sent: Wednesday, August 29, 2012 10:10 AM
>>>> To: lnunez@c3isecurity.com
>>>> Cc: david@joval.org; sacm@ietf.org
>>>> Subject: Re: [sacm] Perception of the term "Monitoring"
>>>>=20
>>>> BTW, the reason I used those two words was to be less precise.
>>>> One can read a number of things into both compliance and management.
>>>>=20
>>>> You have the option of trying to be more granular or more specific.
>>>> The danger I see in too much specificity is that you leave out someone=E2=
=80=99s favorite element.
>>>> And hence a battle between whose favorites get in or don=E2=80=99t.
>>>>=20
>>>> My 2 cents.  Now, I will avoid commenting again like the plague.  =E2=98=
=BA
>>>>=20
>>>> Enjoy,
>>>> Mike
>>>>=20
>>>> From: Luis Nunez [mailto:lnunez@c3isecurity.com]
>>>> Sent: Wednesday, August 29, 2012 9:58 AM
>>>> To: Michael Hammer
>>>> Cc: david@joval.org; sacm@ietf.org
>>>> Subject: Re: [sacm] Perception of the term "Monitoring"
>>>>=20
>>>> early on we ran into issues with the term "continuous management".  Not=
 sure if the word "management" will ignite another storm.
>>>>=20
>>>> To me I don't see what the big deal is.  SACM sounds fine with me.  If i=
t causes controversy great.  Getting people interested and engaged is a good=
 thing.
>>>>=20
>>>>=20
>>>> -ln
>>>>=20
>>>> On Aug 29, 2012, at 9:31 AM, Michael Hammer wrote:
>>>>=20
>>>>=20
>>>> Or just refer to it as compliance management.
>>>> Probably best not to get too specific to future-proof it.
>>>>=20
>>>> I always get amused how these naming storms take place.
>>>> And in the end someone in IESG gets the final say.
>>>> You might want to ping them on magic words to avoid.
>>>> That might cut down on the churn.
>>>>=20
>>>> Mike
>>>>=20
>>>>=20
>>>> From: sacm-bounces@ietf.org [mailto:sacm-=
bounces@ietf.org] On Behalf Of David S=
olin
>>>> Sent: Wednesday, August 29, 2012 8:56 AM
>>>> To: sacm@ietf.org
>>>> Subject: Re: [sacm] Perception of the term "Monitoring"
>>>>=20
>>>> When you invent new terms for anything you're trying to introduce into t=
he marketplace, you're swimming against the current.  Also, we really aren't=
 addressing mitigation at this point.  I'm also sure the idea of continuous m=
itigation would raise eyebrows for anyone who works in a change-controlled e=
nvironment.
>>>>=20
>>>> And, since the door has been opened ... I'm not a fan of SACM.  It's to=
o close to SCAM.  I'd hate for us to introduce another contentious or unfami=
liar term to keep a marginal acronym.
>>>>=20
>>>> Regards,
>>>> --David Solin
>>>>=20
>>>>=20
>>>> On 8/29/2012 7:42 AM, Moriarty, Kathleen wrote:
>>>>=20
>>>>=20
>>>>=20
>>>> Interesting suggestion, that could also let us keep the acronym and lis=
t in tact with the use of a lower case d...
>>>>=20
>>>>=20
>>>>=20
>>>> Thanks,
>>>>=20
>>>> Kathleen
>>>>=20
>>>> ________________________________________
>>>>=20
>>>> From: sacm-bounces@ietf.org [sacm-bounces=
@ietf.org] On Behalf Of Baker, Jon [bakerj@mit=
re.org]
>>>>=20
>>>> Sent: Wednesday, August 29, 2012 8:28 AM
>>>>=20
>>>> To: 'sacm'
>>>>=20
>>>> Subject: Re: [sacm] Perception of the term "Monitoring"
>>>>=20
>>>>=20
>>>>=20
>>>> I believe there are some US Gov leads that are considering using "conti=
nuous diagnostics and Mitigations" as a replacement for continuous monitorin=
g. It might be nice to align sacm terms.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> Sent with Good (www.good.com)
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>>=20
>>>> From: Stephen Hanna [shanna@juniper.net]
>>>>=20
>>>> Sent: Wednesday, August 29, 2012 08:19 AM Eastern Standard Time
>>>>=20
>>>> To: Adam Montville; david.oliva@verizon.net; sacm@ietf.org
>>>>=20
>>>> Cc: Adam W. Montville
>>>>=20
>>>> Subject: Re: [sacm] Perception of the term "Monitoring"
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> I agree. Many users are uncomfortable with the idea of having
>>>>=20
>>>> someone or something monitoring their *activities*, which is
>>>>=20
>>>> what people often think when they think of monitoring.
>>>>=20
>>>>=20
>>>>=20
>>>> However, there's not much problem with taking existing systems
>>>>=20
>>>> for checking security compliance of corporate-owned devices and
>>>>=20
>>>> moving that from periodic and occasional compliance assessments
>>>>=20
>>>> to continuous ones. I think that's what we're talking about here.
>>>>=20
>>>>=20
>>>>=20
>>>> So I think that "continuous compliance" or "continuous assessment"
>>>>=20
>>>> would be a good terms. Let's drop the word "monitoring" altogether
>>>>=20
>>>> since it is often misunderstood.
>>>>=20
>>>>=20
>>>>=20
>>>> Thanks,
>>>>=20
>>>>=20
>>>>=20
>>>> Steve
>>>>=20
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>>=20
>>>> From: sacm-bounces@ietf.org [mailto:sacm-=
bounces@ietf.org] On Behalf Of
>>>>=20
>>>> Adam Montville
>>>>=20
>>>> Sent: Wednesday, August 29, 2012 8:08 AM
>>>>=20
>>>> To: david.oliva@verizon.net; sacm@ietf.=
org
>>>>=20
>>>> Cc: Adam W. Montville
>>>>=20
>>>> Subject: Re: [sacm] Perception of the term "Monitoring"
>>>>=20
>>>>=20
>>>>=20
>>>> Responding on vacation - copying a personal address for off-thread
>>>>=20
>>>> contact, if needed.
>>>>=20
>>>>=20
>>>>=20
>>>> Remaining comments inline.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On 8/29/12 5:01 AM, "david.oliva@verizon.net" 
>>>>=20
>>>> wrote:
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> A large number of hits associate monitoring with employee monitoring,
>>>>=20
>>>> ethical monitoring, telephone-use employee monitoring, performance
>>>>=20
>>>> monitoring, computer behavior monitoring,
>>>>=20
>>>> etc.
>>>>=20
>>>> Perhaps it is not a bad idea to dissociate the SACM effort from the
>>>>=20
>>>> perceived impression that we are building tools for a =C2=B3Big Brother=
=C2=B2
>>>>=20
>>>> kind
>>>>=20
>>>> of society.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> Thanks for the additional insight, David - I think it bolsters the case=

>>>>=20
>>>> nicely.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> David Oliva
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On 08/27/12,
>>>>=20
>>>> David Solin wrote:
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> Google "continuous monitoring" (~7 million results), and you'll see
>>>>=20
>>>> why
>>>>=20
>>>> people who have spent a long time working with the US government think
>>>>=20
>>>> it's a good fit for what we're talking about.
>>>>=20
>>>>=20
>>>>=20
>>>> Google "continuous compliance" (~48 million results), and you'll see
>>>>=20
>>>> why
>>>>=20
>>>> people who have spent a long time working with commercial enterprise
>>>>=20
>>>> software think it's a good fit for what we're talking about.  You'll
>>>>=20
>>>> also
>>>>=20
>>>> notice a lot of the same links from the first
>>>>=20
>>>> list.
>>>>=20
>>>>=20
>>>>=20
>>>> And that's why I think "continuous compliance" is a better fit.  It
>>>>=20
>>>> also
>>>>=20
>>>> has the benefit of being in current use by vendors and analysts, and
>>>>=20
>>>> so
>>>>=20
>>>> the marketplace wouldn't need to be trained to understand it.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> It's the "continuous" part that matters to the effort, not the
>>>>=20
>>>> "monitoring" part.
>>>>=20
>>>>=20
>>>>=20
>>>> To me, it's 100% acceptable to drop the term "monitoring" in favor of a=

>>>>=20
>>>> replacement, and I would, in fact, prefer to do so.
>>>>=20
>>>>=20
>>>>=20
>>>> Others?
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>>=20
>>>> sacm mailing list
>>>>=20
>>>> sacm@ietf.org
>>>>=20
>>>> https://www.ietf.org/mailman/listinfo/sacm
>>>>=20
>>>> _______________________________________________
>>>>=20
>>>> sacm mailing list
>>>>=20
>>>> sacm@ietf.org
>>>>=20
>>>> https://www.ietf.org/mailman/listinfo/sacm
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>>=20
>>>> sacm mailing list
>>>>=20
>>>> sacm@ietf.org
>>>>=20
>>>> https://www.ietf.org/mailman/listinfo/sacm
>>>>=20
>>>> --
>>>>=20
>>>> jOVAL.org: OVAL implemented in Java.
>>>> Scan any machine from any machine. For free!
>>>> Learn More | Features | Download
>>>> _______________________________________________
>>>> sacm mailing list
>>>> sacm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sacm
>>>>=20
>>>> _______________________________________________
>>>> sacm mailing list
>>>> sacm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sacm
>>>> _______________________________________________
>>>> sacm mailing list
>>>> sacm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sacm
>>>=20
>> _______________________________________________
>> sacm mailing list
>> sacm@ietf.org
>> https://www.ietf.org/mailman/listinfo/sacm
>=20
>=20
> --=20
> jOVAL.org: OVAL implemented in Java.
> Scan any machine from any machine. For free!
> Learn More | Features | Download      =20
>=20
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm

--Apple-Mail-4-909635385
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


+1

K

On Aug 31, 20=
12, at 2:00 PM, sacm-request@ietf.o=
rg wrote:

I=
f you have received this digest without all the individual messageattachments you will need to update your digest options in your list<=
/span>
subscription.  To do so, go to 
=

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

Click t=
he 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option=

globally for all the list digests you receive at this point.



Send sacm mail=
ing list submissions to
    sacm@ietf.org
=

To subscribe or unsubscribe via the World Wide Web, v=
isit
    https:/=
/www.ietf.org/mailman/listinfo/sacm
or, via email, s=
end a message with subject or body 'help' to
    <=
a href=3D"mailto:sacm-request@ietf.org">sacm-request@ietf.org

You can r=
each the person managing the list at
    sacm-own=
er@ietf.org

When replying, please e=
dit your Subject line so it is more specific
than "Re: Conte=
nts of sacm digest..."
Today's Topics:

   1=
. Re: Perception of the term "Monitoring" (David Solin)

    
I agree it's a fine idea, switching
      Continuous for Compliance, for the sake of both clarity (or
      politics) and re-use of a name that is just temporary anyway.

      

      On 8/31/2012 12:57 PM, Waltermire, David A. wrote:

    

    

      
+1

Sincerely,
Dave

-----Original Message-----
From: sacm-bounces@ietf.org=
 [<=
a href=3D"mailto:sacm-bounces@ietf.org">mailto:sacm-bounces@ietf.org=
] On Behalf Of Luis Nunez
Sent: Friday, August 31, 2012 11:32 AM
To: Adam Montville
Cc: Michael Hammer; david@joval.org; Mo=
riarty, Kathleen; sacm@ietf.org; Omar Santo=
s (osantos)
Subject: Re: [sacm] Perception of the term "Monitoring"

+1

-ln

On Aug 31, 2012, at 8:21 AM, Adam Montville wrote:



      

        
On Aug 30, 2012, at 9:16 PM, "Omar Santos (osantos)" <=
a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:osantos@cisco.com"><osantos@cisco.com> wrote:



        

          
You have an excellent point Kathleen!!!=20

I think that we are easily making the selection of a WG name far more compli=
cated than the actual standards that are supposed to be our deliverables.



        

        
Agreed.  I would much rather be focusing our energy on getting the content o=
f the charter discussed more completely.  That said, I'd like to propose tha=
t we table the discussion of the working group name until Atlanta - unless t=
here's a compelling reason to settle the issue now - and move on to completi=
ng the discussion of the draft charter.




        

          
David Solin had a *great* point: "When you invent n=
ew terms for anything you're trying to introduce into the marketplace, you'r=
e swimming against the current."

If the IETF community is already familiar with SACM, this alias is sacm, we h=
ave been talking everything SACM, I suggest we stay with it for now.

Mike Hammer also had a good suggestion of "compliance management"; therefore=
 "Security Automation and Compliance Management", still SCAM..

To be honest, I am more interested to know the agreements/arguments of UC1 +=
 UC3  vs. UC1 + UC2...

Regards,

Omar=20


-----Original Message-----
From: sacm-bounces@ietf.org=
 [<=
a href=3D"mailto:sacm-bounces@ietf.org">mailto:sacm-bounces@ietf.org=
] On Behalf Of Moriarty, Kathleen
Sent: Wednesday, August 29, 2012 10:12 AM
To: Michael Hammer; lnunez@c3isec=
urity.com
Cc: david@joval.org; sacm@ietf.org
Subject: Re: [sacm] Perception of the term "Monitoring"

One more point to consider is that the WG name will eventually go away (afte=
r we are done with the work items and a group is closed out) and what will l=
ive on are the names of standards produced by a working group.

Best regards,
Kathleen=20
________________________________________
From: sacm-bounces@ietf.org=
 [sacm-bounces@ietf.org] On=
 Behalf Of Michael Hammer [michael.hammer@yaanatech.com]
Sent: Wednesday, August 29, 2012 10:10 AM
To: lnunez@c3isecurity.com
Cc: david@joval.org; sacm@ietf.org
Subject: Re: [sacm] Perception of the term "Monitoring"

BTW, the reason I used those two words was to be less precise.
One can read a number of things into both compliance and management.

You have the option of trying to be more granular or more specific.
The danger I see in too much specificity is that you leave out someone=E2=80=
=99s favorite element.
And hence a battle between whose favorites get in or don=E2=80=99t.

My 2 cents.  Now, I will avoid commenting again like the plague.  =E2=98=BA

Enjoy,
Mike

From: Luis Nunez [mailto:lnunez@c3is=
ecurity.com]
Sent: Wednesday, August 29, 2012 9:58 AM
To: Michael Hammer
Cc: david@joval.org; sacm@ietf.org
Subject: Re: [sacm] Perception of the term "Monitoring"

early on we ran into issues with the term "continuous management".  Not sure=
 if the word "management" will ignite another storm.

To me I don't see what the big deal is.  SACM sounds fine with me.  If it ca=
uses controversy great.  Getting people interested and engaged is a good thi=
ng.


-ln

On Aug 29, 2012, at 9:31 AM, Michael Hammer wrote:


Or just refer to it as compliance management.
Probably best not to get too specific to future-proof it.

I always get amused how these naming storms take place.
And in the end someone in IESG gets the final say.
You might want to ping them on magic words to avoid.
That might cut down on the churn.

Mike


From: sacm-bounces@ietf.org=
<=
;mailto:sacm-bounces@ietf.org&g=
t; [mailto:sacm-bounces@ietf.org]<mailto:[mailto:sacm-bounces@ietf.org]> On Behalf Of D=
avid Solin
Sent: Wednesday, August 29, 2012 8:56 AM
To: sacm@ietf.org<=
mailto:sacm@ietf.org>
Subject: Re: [sacm] Perception of the term "Monitoring"

When you invent new terms for anything you're trying to introduce into the m=
arketplace, you're swimming against the current.  Also, we really aren't add=
ressing mitigation at this point.  I'm also sure the idea of continuous miti=
gation would raise eyebrows for anyone who works in a change-controlled envi=
ronment.

And, since the door has been opened ... I'm not a fan of SACM.  It's too clo=
se to SCAM.  I'd hate for us to introduce another contentious or unfamiliar t=
erm to keep a marginal acronym.

Regards,
--David Solin


On 8/29/2012 7:42 AM, Moriarty, Kathleen wrote:



Interesting suggestion, that could also let us keep the acronym and list in t=
act with the use of a lower case d...



Thanks,

Kathleen

________________________________________

From: sacm-bounces@ietf.org=
<=
;mailto:sacm-bounces@ietf.org&g=
t; [sacm-bounces@ietf.org&=
lt;mailto:sacm-bounces@ietf.org=
>] On Behalf Of Baker, Jon [bakerj@mit=
re.org<mailto:bakerj@mitre.org>=
;]

Sent: Wednesday, August 29, 2012 8:28 AM

To: 'sacm'

Subject: Re: [sacm] Perception of the term "Monitoring"



I believe there are some US Gov leads that are considering using "continuous=
 diagnostics and Mitigations" as a replacement for continuous monitoring. It=
 might be nice to align sacm terms.







Sent with Good (www.good.com<http://www.good.com>)





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

From: Stephen Hanna [shanna@juniper.net=
<mailto:shanna@juniper.net><=
/a><=
;mailto:shanna@juniper.net>=
<mailto:shanna@juniper.net>]

Sent: Wednesday, August 29, 2012 08:19 AM Eastern Standard Time

To: Adam Montville; david.oliva=
@verizon.net<mailto:dav=
id.oliva@verizon.net>; sacm@ietf.org=
<mailto:sacm@ietf.org>

Cc: Adam W. Montville

Subject: Re: [sacm] Perception of the term "Monitoring"





I agree. Many users are uncomfortable with the idea of having

someone or something monitoring their *activities*, which is

what people often think when they think of monitoring.



However, there's not much problem with taking existing systems

for checking security compliance of corporate-owned devices and

moving that from periodic and occasional compliance assessments

to continuous ones. I think that's what we're talking about here.



So I think that "continuous compliance" or "continuous assessment"

would be a good terms. Let's drop the word "monitoring" altogether

since it is often misunderstood.



Thanks,



Steve



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

From: sacm-bounces@ietf.org=
<=
;mailto:sacm-bounces@ietf.org&g=
t; [mailto:sacm-bounces@ietf.org] On Behalf Of

Adam Montville

Sent: Wednesday, August 29, 2012 8:08 AM

To: david.oliva@verizon.net=
<mailto:david.oliva@verizon=
.net>; sacm@ietf.org<mailto:sacm@ietf.org>

Cc: Adam W. Montville

Subject: Re: [sacm] Perception of the term "Monitoring"



Responding on vacation - copying a personal address for off-thread

contact, if needed.



Remaining comments inline.





On 8/29/12 5:01 AM, "david.oliva@v=
erizon.net"<mailto:davi=
d.oliva@verizon.net> <david.oliva@verizon.net><mailto:david.oliva@verizon.net>

wrote:











A large number of hits associate monitoring with employee monitoring,

ethical monitoring, telephone-use employee monitoring, performance

monitoring, computer behavior monitoring,

etc.

Perhaps it is not a bad idea to dissociate the SACM effort from the

perceived impression that we are building tools for a =C2=B3Big Brother=C2=B2=


kind

of society.







Thanks for the additional insight, David - I think it bolsters the case

nicely.









David Oliva







On 08/27/12,

David Solin<david@joval.org><mailto:david@joval.org> wrote:





Google "continuous monitoring" (~7 million results), and you'll see

why

people who have spent a long time working with the US government think

it's a good fit for what we're talking about.



Google "continuous compliance" (~48 million results), and you'll see

why

people who have spent a long time working with commercial enterprise

software think it's a good fit for what we're talking about.  You'll

also

notice a lot of the same links from the first

list.



And that's why I think "continuous compliance" is a better fit.  It

also

has the benefit of being in current use by vendors and analysts, and

so

the marketplace wouldn't need to be trained to understand it.







It's the "continuous" part that matters to the effort, not the

"monitoring" part.



To me, it's 100% acceptable to drop the term "monitoring" in favor of a

replacement, and I would, in fact, prefer to do so.



Others?







_______________________________________________

sacm mailing list

sacm@ietf.org<mailto=
:sacm@ietf.org>

https://ww=
w.ietf.org/mailman/listinfo/sacm

_______________________________________________

sacm mailing list

sacm@ietf.org<mailto=
:sacm@ietf.org>

https://ww=
w.ietf.org/mailman/listinfo/sacm



_______________________________________________

sacm mailing list

sacm@ietf.org<mailto=
:sacm@ietf.org>

https://ww=
w.ietf.org/mailman/listinfo/sacm

--

jOVAL.org<=
a class=3D"moz-txt-link-rfc2396E" href=3D"http://jOVAL.org"><http://jOVAL.org>: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More&=
lt;http://www.joval.org> | Featu=
res<http://www.joval.org/featur=
es/> | Download<http=
://www.joval.org/download/>
_______________________________________________
sacm mailing list
sacm@ietf.org<mailto=
:sacm@ietf.org>
https://ww=
w.ietf.org/mailman/listinfo/sacm

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


        

        

      

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


    

    

    

    
-- 

      
 jOVAL.org:
          OVAL implemented in Java.

        Scan any machine from any machine. For
          free!

        Learn More
        | Fe=
atures
        | D=
ownload
      

    

 =20


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

--Apple-Mail-4-909635385--

From shanna@juniper.net  Fri Aug 31 12:27:45 2012
Return-Path: 
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF2D21F845B for ; Fri, 31 Aug 2012 12:27:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.571
X-Spam-Level: 
X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 AHeugzs0nMRo for ; Fri, 31 Aug 2012 12:27:44 -0700 (PDT)
Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6088321F845A for ; Fri, 31 Aug 2012 12:27:44 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUEEQL2wvzvnbuaa6ROsppy2A5Kzecpeu@postini.com; Fri, 31 Aug 2012 12:27:44 PDT
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 31 Aug 2012 12:26:39 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 31 Aug 2012 15:25:27 -0400
From: Stephen Hanna 
To: 'sacm' 
Date: Fri, 31 Aug 2012 15:25:26 -0400
Thread-Topic: Getting Our BOF Proposal Ready
Thread-Index: Ac2Hrl+XX4j29dxSS9GMck2HIQefyQ==
Message-ID: 
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] Getting Our BOF Proposal Ready
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Aug 2012 19:27:45 -0000

I'm OK with setting aside the question of the WG name for
now. We can come back to it later.

On to the technical work. We have agreed to narrow our scope
to UC1 and UC3. Could we get revised versions of the Use Cases
draft and the proposed charter that reflect this? There were
also a bunch of other charter changes suggested. They seemed
to be unopposed. Let's get those in the updated charter also.

Our BOF proposal is due September 24 and our AD has asked us
to send it to him by September 10. By that time we need to have
a good draft charter with clear scope, achievable deliverables,
and demonstrable value. We also need to have BOF chairs and an
agenda for the meeting. Having Internet-Drafts that show and
explain what we're planning to do will also help.

We have a lot of work to do in the next week (by September 10).
To accomplish it, we really need to focus on the items listed
above. If we can get our act together in time, great. If not,
we're probably better off waiting for the next IETF meeting
in March 2013. Better to wait and have a good BOF than to rush
and have a mess.

Thanks,

Steve