From bakerj@mitre.org Mon Jul 9 03:54: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 E323F21F860F for ; Mon, 9 Jul 2012 03:54: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.001, 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 IUIPkY59mK8x for ; Mon, 9 Jul 2012 03:54:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 051B821F8604 for ; Mon, 9 Jul 2012 03:54:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A285921B0035; Mon, 9 Jul 2012 06:55:05 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8AB3B21B0857; Mon, 9 Jul 2012 06:55:05 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.107]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.02.0283.003; Mon, 9 Jul 2012 06:55:05 -0400 From: "Baker, Jon" To: Jerome Athias , Adam Montville Thread-Topic: [sacm] IETF 84 Thread-Index: AQHNVUeKYUpL4z7vTUubxQ1VahOvyJcQLMyAgAAExgD//8HKoIAARnCAgAGBRwCAAAVdAIABRBGAgA3S29A= Date: Mon, 9 Jul 2012 10:55:04 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D38651301E4C160@IMCMBX03.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.58] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "kathleen.moriarty@emc.com" , "Kent_Landfield@McAfee.com" , "sacm@ietf.org" , "karen@scarfonecybersecurity.com" Subject: Re: [sacm] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 09 Jul 2012 10:54:43 -0000 Jerome, > >sorry I was out of the list due to a move and new email box. >Maybe it is quite off topic, but I would like to know if some of you >were at the latest MITRE's BIG DATA meeting? >and if any of the presentations/papers are available? > There have recently been two big data technical exchange meetings here at M= ITRE. Unfortunately, the material from those meeting is not shareable. If y= ou have specific questions, let me know off the list and I would be happy t= o help. 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 michael.hammer@yaanatech.com Tue Jul 10 09:36: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 6EA6D11E80D2 for ; Tue, 10 Jul 2012 09:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBfCSeaUuemm for ; Tue, 10 Jul 2012 09:36:00 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 6276C11E80CE for ; Tue, 10 Jul 2012 09:36:00 -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, 10 Jul 2012 09:36:28 -0700 From: Michael Hammer To: "david.waltermire@nist.gov" , "kathleen.moriarty@emc.com" , "karen@scarfonecybersecurity.com" , "sacm@ietf.org" Thread-Topic: [sacm] IETF 84 Thread-Index: AQHNVUeKYUpL4z7vTUubxQ1VahOvyJcQXxeAgAAExgCAAAGdgIASXC4w Date: Tue, 10 Jul 2012 16:36:27 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38C1469@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.18] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0053_01CD5E98.9EE28E20" MIME-Version: 1.0 Subject: Re: [sacm] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 10 Jul 2012 16:36:01 -0000 ------=_NextPart_000_0053_01CD5E98.9EE28E20 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0054_01CD5E98.9EE2B530" ------=_NextPart_001_0054_01CD5E98.9EE2B530 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit David, I just read the use cases draft and have a general comment. My impression of the use cases section is that it reads more like a functional section. As a result, there seems to be a bit of overlap between some of the use cases. I normally expect to see something that defines initial state, events occurring, actions taking place and some end state result. For example, observed machine needs to use some configuration file. Checks signature to see that file was/was not modified. Logs result. Proceeds with process. Functions implied for Section 4: process for signing, process for monitoring, process for logging. If I read into what is there thus far: UC1 performs check on static items. UC2 performs checks on dynamic items (and hence should not duplicate UC1). UC3 performs self-checks on the dog guarding the hen-house. UC4 performs anomaly and threat alerts to peer systems. UC5 logs elements of the above, probably to a separate system, so that compromise or melt-down can be analyzed. Also, I understand that the whole point of this is to make the system automated, but should something said about where the system user, system administrator, or security administrator fits into the picture? Or, does the system just not work (fail-safe) and someone has to dive into logs to find out why? Lastly, does the system take any self-healing measures, or is that going out of scope? Thanks, Mike From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Thursday, June 28, 2012 12:45 PM To: kathleen.moriarty@emc.com; karen@scarfonecybersecurity.com; sacm@ietf.org Subject: Re: [sacm] IETF 84 I think it would be valuable to have some discussion around the use cases and some initial concepts for the charter. Sunday would work for me. Sincerely, Dave From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of kathleen.moriarty@emc.com Sent: Thursday, June 28, 2012 12:39 PM To: karen@scarfonecybersecurity.com; sacm@ietf.org Subject: Re: [sacm] IETF 84 Thanks for starting the thread, Adam and offering to help Karen! A few of us have been working to update the use case document that David Waltermire circulated. We may need help here as I am not sure if we have content for each of the use cases yet. I provided content to update use case 5. The hope was to review the use cases in a side meeting and start looking at a charter in support of the defined use cases. From there, we can figure out what work is needed to support the use cases and charter. This would be used to set the milestones. Should we set a meeting for the Sunday again? Thank you, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Karen Scarfone Sent: Thursday, June 28, 2012 12:22 PM To: sacm@ietf.org Subject: Re: [sacm] IETF 84 I've gotten out of the loop on this as well. I'm still available to edit any documents being produced by this effort. Karen On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville wrote: All: I've been out of this loop for a while, unfortunately. Hopefully, there is progress being made on the use cases and other efforts (I.e. content repository) that were proposed a couple of months ago. Can anyone tell me whether there is a scheduled meeting (side or otherwise) for SACM during IETF 84? If so, do we have any idea when it will be held? Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm -- Karen Scarfone, Principal Consultant, Scarfone Cybersecurity karen@scarfonecybersecurity.com (703)401-1018 ------=_NextPart_001_0054_01CD5E98.9EE2B530 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David,

 

I just read the use cases draft and have a general comment.  =

 

My impression of the use cases section is that it reads more like a = functional section. 

As a result, there seems to be a bit of overlap between some of the = use cases.

I normally expect to see something that defines initial state, events = occurring, actions taking place and some end state = result.

For example, observed machine needs to use some configuration = file.  Checks signature to see that file was/was not = modified.  Logs result.  Proceeds with = process.

Functions implied for Section 4:  process for signing, process = for monitoring, process for logging.

 

If I read into what is there thus far:

UC1 performs check on static items.

UC2 performs checks on dynamic items (and hence should not duplicate = UC1).

UC3 performs self-checks on the dog guarding the = hen-house.

UC4 performs anomaly and threat alerts to peer = systems.

UC5 logs elements of the above, probably to a separate system, so = that compromise or melt-down can be analyzed.

 

Also, I understand that the whole point of this is to make the system = automated, but should something said about where the system user, system = administrator, or security administrator fits into the picture?  = Or, does the system just not work (fail-safe) and someone has to dive = into logs to find out why?

 

Lastly, does the system take any self-healing measures, or is that = going out of scope?

 

Thanks,

Mike

 

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Waltermire, David A.
Sent: Thursday, June 28, 2012 12:45 = PM
To: kathleen.moriarty@emc.com; = karen@scarfonecybersecurity.com; sacm@ietf.org
Subject: Re: = [sacm] IETF 84

 

I think it would be valuable to have some discussion around the use = cases and some initial concepts for the charter.  Sunday would work = for me.

 

Sincerely,

Dave

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf Of kathleen.moriarty@emc.comSent: Thursday, June 28, 2012 12:39 PM
To: karen@scarfonecybersecuri= ty.com; sacm@ietf.org
Subject: Re: = [sacm] IETF 84

 

Thanks for starting the thread, Adam and offering to help = Karen!

 

A few of us have been working to update the use case document that = David Waltermire circulated.  We may need help here as I am not = sure if we have content for each of the use cases yet.  I provided = content to update use case 5.

 

The hope was to review the use cases in a side meeting and start = looking at a charter in support of the defined use cases.  From = there, we can figure out what work is needed to support the use cases = and charter.  This would be used to set the = milestones.

 

Should we set a meeting for the Sunday again?

 

Thank you,

Kathleen

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf Of Karen Scarfone
Sent: Thursday, = June 28, 2012 12:22 PM
To: sacm@ietf.org
Subject: Re: = [sacm] IETF 84

 

I've gotten = out of the loop on this as well. I'm still available to edit any = documents being produced by this effort.

 

 

Karen

On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville = <amontville@tripwire.com> = wrote:

All:

I've been out of = this loop for a while, unfortunately.  Hopefully, there
is = progress being made on the use cases and other efforts (I.e. = content
repository) that were proposed a couple of months = ago.

Can anyone tell me whether there is a scheduled meeting = (side or
otherwise) for SACM during IETF 84?  If so, do we have = any idea when it
will be = held?

Regards,

Adam


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



 

--
Karen Scarfone, Principal = Consultant, Scarfone Cybersecurity
karen@scarfonecybersecurity.com   = (703)401-1018

------=_NextPart_001_0054_01CD5E98.9EE2B530-- ------=_NextPart_000_0053_01CD5E98.9EE28E20 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 AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcx MDE2MzYyNVowIwYJKoZIhvcNAQkEMRYEFIG5XJVlyFTORdudzr7YMQPFu6O5MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAyFjsjCEM2Evp+0SsJtuJBOUUqrriqs3ZyOyBBPABDTsH teWcN4L4EJWXdPzOA6c+y2F9IJkujke5pHJ1sPM6us4vxg8P88ZaMiItSvd9hIwro/jNW8JhcRX9 KDcaVKZCiL1rFuUJXEdvFrS37/tFMzssAlPo7VUHtj3XVbgTdgsAAAAAAAA= ------=_NextPart_000_0053_01CD5E98.9EE28E20-- From amontville@tripwire.com Thu Jul 12 10:28: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 8BDA311E80D3 for ; Thu, 12 Jul 2012 10:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 nQAcqy5yjpOe for ; Thu, 12 Jul 2012 10:28:00 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 9219821F8644 for ; Thu, 12 Jul 2012 10:27:59 -0700 (PDT) Received: from mail103-ch1-R.bigfish.com (10.43.68.244) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Jul 2012 17:28:31 +0000 Received: from mail103-ch1 (localhost [127.0.0.1]) by mail103-ch1-R.bigfish.com (Postfix) with ESMTP id 201404E0554; Thu, 12 Jul 2012 17:28: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: -24 X-BigFish: VPS-24(zz98dI9371I148cI4015Izz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail103-ch1 (localhost.localdomain [127.0.0.1]) by mail103-ch1 (MessageSwitch) id 1342114108858621_19255; Thu, 12 Jul 2012 17:28:28 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail103-ch1.bigfish.com (Postfix) with ESMTP id CC9224A0064; Thu, 12 Jul 2012 17:28:28 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Jul 2012 17:28:27 +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, 12 Jul 2012 10:29: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; Thu, 12 Jul 2012 10:28:28 -0700 From: Adam Montville To: Michael Hammer , "david.waltermire@nist.gov" , "kathleen.moriarty@emc.com" , "karen@scarfonecybersecurity.com" , "sacm@ietf.org" Thread-Topic: [sacm] IETF 84 Thread-Index: AQHNVUeKYUpL4z7vTUubxQ1VahOvyJcQXxeAgAAExgCAAAGdgIASXC4wgAM7RgA= Date: Thu, 12 Jul 2012 17:28:26 +0000 Message-ID: In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38C1469@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [172.16.97.124] 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] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 12 Jul 2012 17:28:01 -0000 Have updated use cases been posted? If so, I missed it. From: Michael Hammer > Date: Tuesday, July 10, 2012 9:36 AM To: "david.waltermire@nist.gov" >, "kathleen.moriarty@em= c.com" >, "karen@scarfonecybersecurity.com" >, "sacm@ietf.org" > Subject: Re: [sacm] IETF 84 David, I just read the use cases draft and have a general comment. My impression of the use cases section is that it reads more like a functio= nal section. As a result, there seems to be a bit of overlap between some of the use cas= es. I normally expect to see something that defines initial state, events occur= ring, actions taking place and some end state result. For example, observed machine needs to use some configuration file. Checks= signature to see that file was/was not modified. Logs result. Proceeds w= ith process. Functions implied for Section 4: process for signing, process for monitori= ng, process for logging. If I read into what is there thus far: UC1 performs check on static items. UC2 performs checks on dynamic items (and hence should not duplicate UC1). UC3 performs self-checks on the dog guarding the hen-house. UC4 performs anomaly and threat alerts to peer systems. UC5 logs elements of the above, probably to a separate system, so that comp= romise or melt-down can be analyzed. Also, I understand that the whole point of this is to make the system autom= ated, but should something said about where the system user, system adminis= trator, or security administrator fits into the picture? Or, does the syst= em just not work (fail-safe) and someone has to dive into logs to find out = why? Lastly, does the system take any self-healing measures, or is that going ou= t of scope? Thanks, Mike From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Waltermire, David A. Sent: Thursday, June 28, 2012 12:45 PM To: kathleen.moriarty@emc.com; karen@scar= fonecybersecurity.com; sacm@ietf.or= g Subject: Re: [sacm] IETF 84 I think it would be valuable to have some discussion around the use cases a= nd some initial concepts for the charter. Sunday would work for me. Sincerely, Dave From:sacm-bounces@ietf.org [mailto:sacm-bounc= es@ietf.org] On Behalf Of kathleen.m= oriarty@emc.com Sent: Thursday, June 28, 2012 12:39 PM To: karen@scarfonecybersecurity.com= ; sacm@ietf.org Subject: Re: [sacm] IETF 84 Thanks for starting the thread, Adam and offering to help Karen! A few of us have been working to update the use case document that David Wa= ltermire circulated. We may need help here as I am not sure if we have con= tent for each of the use cases yet. I provided content to update use case = 5. The hope was to review the use cases in a side meeting and start looking at= a charter in support of the defined use cases. From there, we can figure = out what work is needed to support the use cases and charter. This would b= e used to set the milestones. Should we set a meeting for the Sunday again? Thank you, Kathleen From:sacm-bounces@ietf.org [mailto:sacm-bounc= es@ietf.org] On Behalf Of Karen Scar= fone Sent: Thursday, June 28, 2012 12:22 PM To: sacm@ietf.org Subject: Re: [sacm] IETF 84 I've gotten out of the loop on this as well. I'm still available to edit an= y documents being produced by this effort. Karen On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville > wrote: All: I've been out of this loop for a while, unfortunately. Hopefully, there is progress being made on the use cases and other efforts (I.e. content repository) that were proposed a couple of months ago. Can anyone tell me whether there is a scheduled meeting (side or otherwise) for SACM during IETF 84? If so, do we have any idea when it will be held? Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm -- Karen Scarfone, Principal Consultant, Scarfone Cybersecurity karen@scarfonecybersecurity.com (= 703)401-1018 From david.waltermire@nist.gov Thu Jul 12 11:03: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 07C8611E80C7 for ; Thu, 12 Jul 2012 11:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.85 X-Spam-Level: X-Spam-Status: No, score=-5.85 tagged_above=-999 required=5 tests=[AWL=0.749, 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 nLswSuBRbrSX for ; Thu, 12 Jul 2012 11:03:48 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id C56D011E8098 for ; Thu, 12 Jul 2012 11:03:47 -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, 12 Jul 2012 14:04:13 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 12 Jul 2012 14:00:43 -0400 From: "Waltermire, David A." To: "'amontville@tripwire.com'" , "'michael.hammer@yaanatech.com'" , "'kathleen.moriarty@emc.com'" , "'karen@scarfonecybersecurity.com'" , "'sacm@ietf.org'" Date: Thu, 12 Jul 2012 14:00:42 -0400 Thread-Topic: [sacm] IETF 84 Thread-Index: AQHNVUeKYUpL4z7vTUubxQ1VahOvyJcQXxeAgAAExgCAAAGdgIASXC4wgAM7RgCAAAkFIA== 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] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 12 Jul 2012 18:03:49 -0000 No. You didn't miss anything. Kathleen has been the only contributor to d= ate. Dave ----- Original Message ----- From: Adam Montville To: Michael Hammer ; Waltermire, David A.; ka= thleen.moriarty@emc.com ; karen@scarfonecybersec= urity.com ; sacm@ietf.org Sent: Thu Jul 12 13:28:26 2012=0A= Subject: Re: [sacm] IETF 84 Have updated use cases been posted? If so, I missed it. From: Michael Hammer > Date: Tuesday, July 10, 2012 9:36 AM To: "david.waltermire@nist.gov" >, "kathleen.moriarty@em= c.com" >, "karen@scarfonecybersecurity.com" >, "sacm@ietf.org" > Subject: Re: [sacm] IETF 84 David, I just read the use cases draft and have a general comment. My impression of the use cases section is that it reads more like a functio= nal section. As a result, there seems to be a bit of overlap between some of the use cas= es. I normally expect to see something that defines initial state, events occur= ring, actions taking place and some end state result. For example, observed machine needs to use some configuration file. Checks= signature to see that file was/was not modified. Logs result. Proceeds w= ith process. Functions implied for Section 4: process for signing, process for monitori= ng, process for logging. If I read into what is there thus far: UC1 performs check on static items. UC2 performs checks on dynamic items (and hence should not duplicate UC1). UC3 performs self-checks on the dog guarding the hen-house. UC4 performs anomaly and threat alerts to peer systems. UC5 logs elements of the above, probably to a separate system, so that comp= romise or melt-down can be analyzed. Also, I understand that the whole point of this is to make the system autom= ated, but should something said about where the system user, system adminis= trator, or security administrator fits into the picture? Or, does the syst= em just not work (fail-safe) and someone has to dive into logs to find out = why? Lastly, does the system take any self-healing measures, or is that going ou= t of scope? Thanks, Mike From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Waltermire, David A. Sent: Thursday, June 28, 2012 12:45 PM To: kathleen.moriarty@emc.com; karen@scar= fonecybersecurity.com; sacm@ietf.or= g Subject: Re: [sacm] IETF 84 I think it would be valuable to have some discussion around the use cases a= nd some initial concepts for the charter. Sunday would work for me. Sincerely, Dave From:sacm-bounces@ietf.org [mailto:sacm-bounc= es@ietf.org] On Behalf Of kathleen.m= oriarty@emc.com Sent: Thursday, June 28, 2012 12:39 PM To: karen@scarfonecybersecurity.com= ; sacm@ietf.org Subject: Re: [sacm] IETF 84 Thanks for starting the thread, Adam and offering to help Karen! A few of us have been working to update the use case document that David Wa= ltermire circulated. We may need help here as I am not sure if we have con= tent for each of the use cases yet. I provided content to update use case = 5. The hope was to review the use cases in a side meeting and start looking at= a charter in support of the defined use cases. From there, we can figure = out what work is needed to support the use cases and charter. This would b= e used to set the milestones. Should we set a meeting for the Sunday again? Thank you, Kathleen From:sacm-bounces@ietf.org [mailto:sacm-bounc= es@ietf.org] On Behalf Of Karen Scar= fone Sent: Thursday, June 28, 2012 12:22 PM To: sacm@ietf.org Subject: Re: [sacm] IETF 84 I've gotten out of the loop on this as well. I'm still available to edit an= y documents being produced by this effort. Karen On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville > wrote: All: I've been out of this loop for a while, unfortunately. Hopefully, there is progress being made on the use cases and other efforts (I.e. content repository) that were proposed a couple of months ago. Can anyone tell me whether there is a scheduled meeting (side or otherwise) for SACM during IETF 84? If so, do we have any idea when it will be held? Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm -- Karen Scarfone, Principal Consultant, Scarfone Cybersecurity karen@scarfonecybersecurity.com (= 703)401-1018 From david.waltermire@nist.gov Thu Jul 12 11:08: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 8ABAA11E80C7 for ; Thu, 12 Jul 2012 11:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.1 X-Spam-Level: X-Spam-Status: No, score=-6.1 tagged_above=-999 required=5 tests=[AWL=0.499, 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 lt16YW-TinXD for ; Thu, 12 Jul 2012 11:08:17 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 67D8B11E8098 for ; Thu, 12 Jul 2012 11:08:17 -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; Thu, 12 Jul 2012 14:08:31 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 12 Jul 2012 14:05:13 -0400 From: "Waltermire, David A." To: "'amontville@tripwire.com'" , "'michael.hammer@yaanatech.com'" , "'kathleen.moriarty@emc.com'" , "'karen@scarfonecybersecurity.com'" , "'sacm@ietf.org'" Date: Thu, 12 Jul 2012 14:05:12 -0400 Thread-Topic: [sacm] IETF 84 Thread-Index: AQHNVUeKYUpL4z7vTUubxQ1VahOvyJcQXxeAgAAExgCAAAGdgIASXC4wgAM7RgCAAAkFIIAAAUJB 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] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 12 Jul 2012 18:08:21 -0000 I hit send too soon... If you have contributions, I would be happy to incorporate them into the dr= aft. I think the deadline has passed to update it, but I would be happy to= send an updated draft to the list before the meeting. Thanks, Dave ----- Original Message ----- From: sacm-bounces@ietf.org To: 'amontville@tripwire.com' ; 'michael.hammer@ya= anatech.com' ; 'kathleen.moriarty@emc.com' ; 'karen@scarfonecybersecurity.com' ; 'sacm@ietf.org' Sent: Thu Jul 12 14:00:42 2012=0A= Subject: Re: [sacm] IETF 84 No. You didn't miss anything. Kathleen has been the only contributor to d= ate. Dave ----- Original Message ----- From: Adam Montville To: Michael Hammer ; Waltermire, David A.; ka= thleen.moriarty@emc.com ; karen@scarfonecybersec= urity.com ; sacm@ietf.org Sent: Thu Jul 12 13:28:26 2012 Subject: Re: [sacm] IETF 84 Have updated use cases been posted? If so, I missed it. From: Michael Hammer > Date: Tuesday, July 10, 2012 9:36 AM To: "david.waltermire@nist.gov" >, "kathleen.moriarty@em= c.com" >, "karen@scarfonecybersecurity.com" >, "sacm@ietf.org" > Subject: Re: [sacm] IETF 84 David, I just read the use cases draft and have a general comment. My impression of the use cases section is that it reads more like a functio= nal section. As a result, there seems to be a bit of overlap between some of the use cas= es. I normally expect to see something that defines initial state, events occur= ring, actions taking place and some end state result. For example, observed machine needs to use some configuration file. Checks= signature to see that file was/was not modified. Logs result. Proceeds w= ith process. Functions implied for Section 4: process for signing, process for monitori= ng, process for logging. If I read into what is there thus far: UC1 performs check on static items. UC2 performs checks on dynamic items (and hence should not duplicate UC1). UC3 performs self-checks on the dog guarding the hen-house. UC4 performs anomaly and threat alerts to peer systems. UC5 logs elements of the above, probably to a separate system, so that comp= romise or melt-down can be analyzed. Also, I understand that the whole point of this is to make the system autom= ated, but should something said about where the system user, system adminis= trator, or security administrator fits into the picture? Or, does the syst= em just not work (fail-safe) and someone has to dive into logs to find out = why? Lastly, does the system take any self-healing measures, or is that going ou= t of scope? Thanks, Mike From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Waltermire, David A. Sent: Thursday, June 28, 2012 12:45 PM To: kathleen.moriarty@emc.com; karen@scar= fonecybersecurity.com; sacm@ietf.or= g Subject: Re: [sacm] IETF 84 I think it would be valuable to have some discussion around the use cases a= nd some initial concepts for the charter. Sunday would work for me. Sincerely, Dave From:sacm-bounces@ietf.org [mailto:sacm-bounc= es@ietf.org] On Behalf Of kathleen.m= oriarty@emc.com Sent: Thursday, June 28, 2012 12:39 PM To: karen@scarfonecybersecurity.com= ; sacm@ietf.org Subject: Re: [sacm] IETF 84 Thanks for starting the thread, Adam and offering to help Karen! A few of us have been working to update the use case document that David Wa= ltermire circulated. We may need help here as I am not sure if we have con= tent for each of the use cases yet. I provided content to update use case = 5. The hope was to review the use cases in a side meeting and start looking at= a charter in support of the defined use cases. From there, we can figure = out what work is needed to support the use cases and charter. This would b= e used to set the milestones. Should we set a meeting for the Sunday again? Thank you, Kathleen From:sacm-bounces@ietf.org [mailto:sacm-bounc= es@ietf.org] On Behalf Of Karen Scar= fone Sent: Thursday, June 28, 2012 12:22 PM To: sacm@ietf.org Subject: Re: [sacm] IETF 84 I've gotten out of the loop on this as well. I'm still available to edit an= y documents being produced by this effort. Karen On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville > wrote: All: I've been out of this loop for a while, unfortunately. Hopefully, there is progress being made on the use cases and other efforts (I.e. content repository) that were proposed a couple of months ago. Can anyone tell me whether there is a scheduled meeting (side or otherwise) for SACM during IETF 84? If so, do we have any idea when it will be held? Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm -- Karen Scarfone, Principal Consultant, Scarfone Cybersecurity karen@scarfonecybersecurity.com (= 703)401-1018 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From athiasjerome@gmail.com Thu Jul 12 11:08: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 D21FE11E80D3 for ; Thu, 12 Jul 2012 11:08:50 -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 DNbVsxEu1ORA for ; Thu, 12 Jul 2012 11:08:50 -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 B9A6111E8098 for ; Thu, 12 Jul 2012 11:08:49 -0700 (PDT) Received: by eekd4 with SMTP id d4so936634eek.31 for ; Thu, 12 Jul 2012 11:09:23 -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=stsOth1kGc9oDAtMzGg6YEsUP2JkSQKZdVIyNCvBn2o=; b=nx4E5d9qwM5+FqwnO2jVm3e8Wm+JqxsRF8gICdWcMPx+U8ZElquCOqZf60jlRAu8hZ XUFkNcGfVLa8Vd8HfzA/qkUJ8MmZNd3LReZUbQpavKRK7CfS2hMeeQ/SGKVppIaoZg9J 1YuSHUKwXxbcosz5qL7TvyirqZPBcCZbWt/39LXBfkNRPcLWgWKD2G5t1G8VRoNRCmMc MhRGmNyxUu8yP6JCLCbOunAHaZerCOujb1Ed0AHbIQpaq5yrJLBzmN2fvtYtf9U194L7 wSisYP5ac0P5v8suzsWDWAl85pAaWWbZwfpNkEZGHosn3/zwssHlsS+mqXbMW21dacEi ZMeQ== Received: by 10.14.100.201 with SMTP id z49mr13719679eef.229.1342116562703; Thu, 12 Jul 2012 11:09:22 -0700 (PDT) Received: from [192.168.1.82] (39.117.199.77.rev.sfr.net. [77.199.117.39]) by mx.google.com with ESMTPS id x52sm17829527eea.11.2012.07.12.11.09.21 (version=SSLv3 cipher=OTHER); Thu, 12 Jul 2012 11:09:22 -0700 (PDT) Message-ID: <4FFF12CE.8070503@gmail.com> Date: Thu, 12 Jul 2012 20:09:18 +0200 From: Jerome Athias User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: sacm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sacm] Collaborative platform X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 12 Jul 2012 18:08:50 -0000 Hi list, I would like to introduce the fact of having a collaborative platform for meetings and sharing ideas and documents. I just have one open for demo here: http://visio.mediatux.com/ if some are interested, tests and feedbacks are welcome. Regards Jerome From kathleen.moriarty@emc.com Thu Jul 12 11:18: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 9CB6721F85AC for ; Thu, 12 Jul 2012 11:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 eOtJETUsUk2T for ; Thu, 12 Jul 2012 11:18: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 AB39621F85AE for ; Thu, 12 Jul 2012 11:18:40 -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 q6CIJDPq003398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2012 14:19:13 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Thu, 12 Jul 2012 14:18:49 -0400 Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6CIIhFV000685; Thu, 12 Jul 2012 14:18:48 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Thu, 12 Jul 2012 14:18:45 -0400 From: To: Date: Thu, 12 Jul 2012 14:18:33 -0400 Thread-Topic: [sacm] IETF 84 Thread-Index: Ac1gWsVpIsPRavoIQtS454sUDQmraA== Message-ID: <9CDCB208-1A37-45A8-92CC-4205B83A68A5@emc.com> 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: karen@scarfonecybersecurity.com, michael.hammer@yaanatech.com, sacm@ietf.org, amontville@tripwire.com Subject: Re: [sacm] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 12 Jul 2012 18:18:41 -0000 Hi Dave,=20 We have until Monday 17:00PT to post a -01 version. It would be great if w= e can pull together and get that out. Thanks, Kathleen=20 Sent from my iPhone On Jul 12, 2012, at 2:09 PM, "Waltermire, David A." wrote: > I hit send too soon... >=20 > If you have contributions, I would be happy to incorporate them into the = draft. I think the deadline has passed to update it, but I would be happy = to send an updated draft to the list before the meeting. >=20 > Thanks, > Dave >=20 >=20 > ----- Original Message ----- > From: sacm-bounces@ietf.org > To: 'amontville@tripwire.com' ; 'michael.hammer@= yaanatech.com' ; 'kathleen.moriarty@emc.com' = ; 'karen@scarfonecybersecurity.com' ; 'sacm@ietf.org' > Sent: Thu Jul 12 14:00:42 2012 > Subject: Re: [sacm] IETF 84 >=20 > No. You didn't miss anything. Kathleen has been the only contributor to= date. >=20 > Dave >=20 >=20 > ----- Original Message ----- > From: Adam Montville > To: Michael Hammer ; Waltermire, David A.; = kathleen.moriarty@emc.com ; karen@scarfonecybers= ecurity.com ; sacm@ietf.org > Sent: Thu Jul 12 13:28:26 2012 > Subject: Re: [sacm] IETF 84 >=20 > Have updated use cases been posted? If so, I missed it. >=20 > From: Michael Hammer > > Date: Tuesday, July 10, 2012 9:36 AM > To: "david.waltermire@nist.gov" >, "kathleen.moriarty@= emc.com" >, "karen@scarfonecybersecurity.com" >, "sacm@ietf.org" > > Subject: Re: [sacm] IETF 84 >=20 > David, >=20 > I just read the use cases draft and have a general comment. >=20 > My impression of the use cases section is that it reads more like a funct= ional section. > As a result, there seems to be a bit of overlap between some of the use c= ases. > I normally expect to see something that defines initial state, events occ= urring, actions taking place and some end state result. > For example, observed machine needs to use some configuration file. Chec= ks signature to see that file was/was not modified. Logs result. Proceeds= with process. > Functions implied for Section 4: process for signing, process for monito= ring, process for logging. >=20 > If I read into what is there thus far: > UC1 performs check on static items. > UC2 performs checks on dynamic items (and hence should not duplicate UC1)= . > UC3 performs self-checks on the dog guarding the hen-house. > UC4 performs anomaly and threat alerts to peer systems. > UC5 logs elements of the above, probably to a separate system, so that co= mpromise or melt-down can be analyzed. >=20 > Also, I understand that the whole point of this is to make the system aut= omated, but should something said about where the system user, system admin= istrator, or security administrator fits into the picture? Or, does the sy= stem just not work (fail-safe) and someone has to dive into logs to find ou= t why? >=20 > Lastly, does the system take any self-healing measures, or is that going = out of scope? >=20 > Thanks, > Mike >=20 >=20 > From: sacm-bounces@ietf.org [mailto:sacm-bo= unces@ietf.org] On Behalf Of Waltermire, David A. > Sent: Thursday, June 28, 2012 12:45 PM > To: kathleen.moriarty@emc.com; karen@sc= arfonecybersecurity.com; sacm@ietf.= org > Subject: Re: [sacm] IETF 84 >=20 > I think it would be valuable to have some discussion around the use cases= and some initial concepts for the charter. Sunday would work for me. >=20 > Sincerely, > Dave >=20 > From:sacm-bounces@ietf.org [mailto:sacm-bou= nces@ietf.org] On Behalf Of kathleen= .moriarty@emc.com > Sent: Thursday, June 28, 2012 12:39 PM > To: karen@scarfonecybersecurity.com; sacm@ietf.org > Subject: Re: [sacm] IETF 84 >=20 > Thanks for starting the thread, Adam and offering to help Karen! >=20 > A few of us have been working to update the use case document that David = Waltermire circulated. We may need help here as I am not sure if we have c= ontent for each of the use cases yet. I provided content to update use cas= e 5. >=20 > The hope was to review the use cases in a side meeting and start looking = at a charter in support of the defined use cases. From there, we can figur= e out what work is needed to support the use cases and charter. This would= be used to set the milestones. >=20 > Should we set a meeting for the Sunday again? >=20 > Thank you, > Kathleen >=20 > From:sacm-bounces@ietf.org [mailto:sacm-bou= nces@ietf.org] On Behalf Of Karen Sc= arfone > Sent: Thursday, June 28, 2012 12:22 PM > To: sacm@ietf.org > Subject: Re: [sacm] IETF 84 >=20 > I've gotten out of the loop on this as well. I'm still available to edit = any documents being produced by this effort. >=20 >=20 > Karen > On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville > wrote: > All: >=20 > I've been out of this loop for a while, unfortunately. Hopefully, there > is progress being made on the use cases and other efforts (I.e. content > repository) that were proposed a couple of months ago. >=20 > Can anyone tell me whether there is a scheduled meeting (side or > otherwise) for SACM during IETF 84? If so, do we have any idea when it > will be held? >=20 > Regards, >=20 > Adam >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 >=20 >=20 > -- > Karen Scarfone, Principal Consultant, Scarfone Cybersecurity > karen@scarfonecybersecurity.com = (703)401-1018 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From david.waltermire@nist.gov Thu Jul 12 11:37: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 E599B11E80E9 for ; Thu, 12 Jul 2012 11:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=0.374, 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 Y+oEK1+OzGMp for ; Thu, 12 Jul 2012 11:37:52 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9225111E80ED for ; Thu, 12 Jul 2012 11:37:51 -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, 12 Jul 2012 14:38:05 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 12 Jul 2012 14:38:24 -0400 From: "Waltermire, David A." To: "'kathleen.moriarty@emc.com'" Date: Thu, 12 Jul 2012 14:34:46 -0400 Thread-Topic: [sacm] IETF 84 Thread-Index: Ac1gWsVpIsPRavoIQtS454sUDQmraAAAj5JV Message-ID: In-Reply-To: <9CDCB208-1A37-45A8-92CC-4205B83A68A5@emc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'amontville@tripwire.com'" , "'michael.hammer@yaanatech.com'" , "'sacm@ietf.org'" , "'karen@scarfonecybersecurity.com'" Subject: Re: [sacm] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 12 Jul 2012 18:37:53 -0000 That's good. I am happy to support the effort by editing any contributions= together. Kathleen, I have your text for UC 5. Does anyone else have any= text to contribute? Thanks, Dave ----- Original Message ----- From: sacm-bounces@ietf.org To: Waltermire, David A. Cc: karen@scarfonecybersecurity.com ; mich= ael.hammer@yaanatech.com ; sacm@ietf.org ; amontville@tripwire.com Sent: Thu Jul 12 14:18:33 2012=0A= Subject: Re: [sacm] IETF 84 Hi Dave,=20 We have until Monday 17:00PT to post a -01 version. It would be great if w= e can pull together and get that out. Thanks, Kathleen=20 Sent from my iPhone On Jul 12, 2012, at 2:09 PM, "Waltermire, David A." wrote: > I hit send too soon... >=20 > If you have contributions, I would be happy to incorporate them into the = draft. I think the deadline has passed to update it, but I would be happy = to send an updated draft to the list before the meeting. >=20 > Thanks, > Dave >=20 >=20 > ----- Original Message ----- > From: sacm-bounces@ietf.org > To: 'amontville@tripwire.com' ; 'michael.hammer@= yaanatech.com' ; 'kathleen.moriarty@emc.com' = ; 'karen@scarfonecybersecurity.com' ; 'sacm@ietf.org' > Sent: Thu Jul 12 14:00:42 2012 > Subject: Re: [sacm] IETF 84 >=20 > No. You didn't miss anything. Kathleen has been the only contributor to= date. >=20 > Dave >=20 >=20 > ----- Original Message ----- > From: Adam Montville > To: Michael Hammer ; Waltermire, David A.; = kathleen.moriarty@emc.com ; karen@scarfonecybers= ecurity.com ; sacm@ietf.org > Sent: Thu Jul 12 13:28:26 2012 > Subject: Re: [sacm] IETF 84 >=20 > Have updated use cases been posted? If so, I missed it. >=20 > From: Michael Hammer > > Date: Tuesday, July 10, 2012 9:36 AM > To: "david.waltermire@nist.gov" >, "kathleen.moriarty@= emc.com" >, "karen@scarfonecybersecurity.com" >, "sacm@ietf.org" > > Subject: Re: [sacm] IETF 84 >=20 > David, >=20 > I just read the use cases draft and have a general comment. >=20 > My impression of the use cases section is that it reads more like a funct= ional section. > As a result, there seems to be a bit of overlap between some of the use c= ases. > I normally expect to see something that defines initial state, events occ= urring, actions taking place and some end state result. > For example, observed machine needs to use some configuration file. Chec= ks signature to see that file was/was not modified. Logs result. Proceeds= with process. > Functions implied for Section 4: process for signing, process for monito= ring, process for logging. >=20 > If I read into what is there thus far: > UC1 performs check on static items. > UC2 performs checks on dynamic items (and hence should not duplicate UC1)= . > UC3 performs self-checks on the dog guarding the hen-house. > UC4 performs anomaly and threat alerts to peer systems. > UC5 logs elements of the above, probably to a separate system, so that co= mpromise or melt-down can be analyzed. >=20 > Also, I understand that the whole point of this is to make the system aut= omated, but should something said about where the system user, system admin= istrator, or security administrator fits into the picture? Or, does the sy= stem just not work (fail-safe) and someone has to dive into logs to find ou= t why? >=20 > Lastly, does the system take any self-healing measures, or is that going = out of scope? >=20 > Thanks, > Mike >=20 >=20 > From: sacm-bounces@ietf.org [mailto:sacm-bo= unces@ietf.org] On Behalf Of Waltermire, David A. > Sent: Thursday, June 28, 2012 12:45 PM > To: kathleen.moriarty@emc.com; karen@sc= arfonecybersecurity.com; sacm@ietf.= org > Subject: Re: [sacm] IETF 84 >=20 > I think it would be valuable to have some discussion around the use cases= and some initial concepts for the charter. Sunday would work for me. >=20 > Sincerely, > Dave >=20 > From:sacm-bounces@ietf.org [mailto:sacm-bou= nces@ietf.org] On Behalf Of kathleen= .moriarty@emc.com > Sent: Thursday, June 28, 2012 12:39 PM > To: karen@scarfonecybersecurity.com; sacm@ietf.org > Subject: Re: [sacm] IETF 84 >=20 > Thanks for starting the thread, Adam and offering to help Karen! >=20 > A few of us have been working to update the use case document that David = Waltermire circulated. We may need help here as I am not sure if we have c= ontent for each of the use cases yet. I provided content to update use cas= e 5. >=20 > The hope was to review the use cases in a side meeting and start looking = at a charter in support of the defined use cases. From there, we can figur= e out what work is needed to support the use cases and charter. This would= be used to set the milestones. >=20 > Should we set a meeting for the Sunday again? >=20 > Thank you, > Kathleen >=20 > From:sacm-bounces@ietf.org [mailto:sacm-bou= nces@ietf.org] On Behalf Of Karen Sc= arfone > Sent: Thursday, June 28, 2012 12:22 PM > To: sacm@ietf.org > Subject: Re: [sacm] IETF 84 >=20 > I've gotten out of the loop on this as well. I'm still available to edit = any documents being produced by this effort. >=20 >=20 > Karen > On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville > wrote: > All: >=20 > I've been out of this loop for a while, unfortunately. Hopefully, there > is progress being made on the use cases and other efforts (I.e. content > repository) that were proposed a couple of months ago. >=20 > Can anyone tell me whether there is a scheduled meeting (side or > otherwise) for SACM during IETF 84? If so, do we have any idea when it > will be held? >=20 > Regards, >=20 > Adam >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 >=20 >=20 > -- > Karen Scarfone, Principal Consultant, Scarfone Cybersecurity > karen@scarfonecybersecurity.com = (703)401-1018 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From Erik.Cockrell@polycom.com Thu Jul 12 12:48: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 800AD11E80CD for ; Thu, 12 Jul 2012 12:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 DIi1HSQnI4eZ for ; Thu, 12 Jul 2012 12:48:36 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id A875411E809B for ; Thu, 12 Jul 2012 12:48:36 -0700 (PDT) Received: from CRPMBOXPRD02.polycom.com ([fe80::b94b:feef:580:da7f]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Thu, 12 Jul 2012 12:49:09 -0700 From: "Cockrell, Erik" To: "sacm@ietf.org" Date: Thu, 12 Jul 2012 12:49:07 -0700 Thread-Topic: Copy of current use cases? Thread-Index: Ac1gZ2YcinKtOyJVRym7MoAsaKIy4g== Message-ID: <4038C3329CFD1D4EABBE867CFB81AC30013937A8B5@CRPMBOXPRD02.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4038C3329CFD1D4EABBE867CFB81AC30013937A8B5CRPMBOXPRD02p_" MIME-Version: 1.0 Subject: [sacm] Copy of current use cases? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 12 Jul 2012 19:48:37 -0000 --_000_4038C3329CFD1D4EABBE867CFB81AC30013937A8B5CRPMBOXPRD02p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all - I have just subscribed to sacm. Where/how can I access the use= cases that are being discussed? Thanks. Erik Cockrell, Product Security Engineer, Product Security Office The holy grail of security is airtight input validation. 7700 Parmer Lane, Bldg C, Suite 100, Austin, TX, 78729 | T: 512.372.7155 | = M: 512.739.4250 --_000_4038C3329CFD1D4EABBE867CFB81AC30013937A8B5CRPMBOXPRD02p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all –= ; I have just subscribed to sacm.  Where/how can I access the use case= s that are being discussed?  Thanks.

 

Erik Cockrell, Product Securi= ty Engineer, Product Security Office

The holy grail of security is airtight input validation.=

7700 Pa= rmer Lane, Bldg C, Suite 100, Austin, TX, 78729 | T: 5= 12.372.7155 | M: 512.739.4250

 

 

= --_000_4038C3329CFD1D4EABBE867CFB81AC30013937A8B5CRPMBOXPRD02p_-- From michael.hammer@yaanatech.com Thu Jul 12 14:23: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 4DE0811E80AD for ; Thu, 12 Jul 2012 14:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0LNMsxUK3Bx for ; Thu, 12 Jul 2012 14:23:54 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBB011E80A6 for ; Thu, 12 Jul 2012 14:23:54 -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; Thu, 12 Jul 2012 14:24:28 -0700 From: Michael Hammer To: "Erik.Cockrell@polycom.com" , "sacm@ietf.org" Thread-Topic: Copy of current use cases? Thread-Index: Ac1gZ2YcinKtOyJVRym7MoAsaKIy4gADUFrg Date: Thu, 12 Jul 2012 21:24:26 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38C2809@EX2K10MB1.corp.yaanatech.com> References: <4038C3329CFD1D4EABBE867CFB81AC30013937A8B5@CRPMBOXPRD02.polycom.com> In-Reply-To: <4038C3329CFD1D4EABBE867CFB81AC30013937A8B5@CRPMBOXPRD02.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.22] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0047_01CD6053.2F553DC0" MIME-Version: 1.0 Subject: Re: [sacm] Copy of current use cases? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 12 Jul 2012 21:23:55 -0000 ------=_NextPart_000_0047_01CD6053.2F553DC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0048_01CD6053.2F553DC0" ------=_NextPart_001_0048_01CD6053.2F553DC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit http://www.ietf.org/internet-drafts/draft-waltermire-sacm-use-cases-00.txt From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Cockrell, Erik Sent: Thursday, July 12, 2012 3:49 PM To: sacm@ietf.org Subject: [sacm] Copy of current use cases? Hello all - I have just subscribed to sacm. Where/how can I access the use cases that are being discussed? Thanks. Erik Cockrell, Product Security Engineer, Product Security Office The holy grail of security is airtight input validation. 7700 Parmer Lane, Bldg C, Suite 100, Austin, TX, 78729 | T: 512.372.7155 | M: 512.739.4250 ------=_NextPart_001_0048_01CD6053.2F553DC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<= a = href=3D"http://www.ietf.org/internet-drafts/draft-waltermire-sacm-use-cas= es-00.txt">http://www.ietf.org/internet-drafts/draft-waltermire-sacm-use-= cases-00.txt

 

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Cockrell, Erik
Sent: Thursday, July 12, 2012 3:49 = PM
To: sacm@ietf.org
Subject: [sacm] Copy of current = use cases?

 

Hello all = – I have just subscribed to sacm.  Where/how can I access the = use cases that are being discussed?  Thanks.

 

Er= ik Cockrell, Product Security Engineer, Product Security = Office

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

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

 

 

------=_NextPart_001_0048_01CD6053.2F553DC0-- ------=_NextPart_000_0047_01CD6053.2F553DC0 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 AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcx MjIxMjQyNVowIwYJKoZIhvcNAQkEMRYEFLNjU4IlQ2J7ORzrnN+rkm0tdXeuMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAM5d9n2u2KeGMuguadaw9DYOkRM6agCSNJ8O24kGykL+P fxuNyv69xWrzLRE1k0isJ8EsS4SutpSMscW72eoHvS2uzkg90hgnwWMHA8gw2FUzj1A0RPrLI2ZP EY/cwsgA5wc6Lg28TIluiGNOFVhdc2GNTEkJtcn97Athj85QwRUAAAAAAAA= ------=_NextPart_000_0047_01CD6053.2F553DC0-- From david.waltermire@nist.gov Thu Jul 12 14:31: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 A024C21F85AE for ; Thu, 12 Jul 2012 14:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.281 X-Spam-Level: X-Spam-Status: No, score=-5.281 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5UPn2064+RF for ; Thu, 12 Jul 2012 14:31:48 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6D52921F85AC for ; Thu, 12 Jul 2012 14:31:48 -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, 12 Jul 2012 17:32:02 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 12 Jul 2012 17:32:21 -0400 From: "Waltermire, David A." To: Michael Hammer , "Erik.Cockrell@polycom.com" , "sacm@ietf.org" Date: Thu, 12 Jul 2012 17:32:20 -0400 Thread-Topic: Copy of current use cases? Thread-Index: Ac1gZ2YcinKtOyJVRym7MoAsaKIy4gADUFrgAABFnYA= Message-ID: References: <4038C3329CFD1D4EABBE867CFB81AC30013937A8B5@CRPMBOXPRD02.polycom.com> <00C069FD01E0324C9FFCADF539701DB38C2809@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38C2809@EX2K10MB1.corp.yaanatech.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_D7A0423E5E193F40BE6E94126930C4930B9DE2C37EMBCLUSTERxcha_" MIME-Version: 1.0 Subject: Re: [sacm] Copy of current use cases? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 12 Jul 2012 21:31:49 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B9DE2C37EMBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" Thanks for posting the link! Sincerely, Dave From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Thursday, July 12, 2012 5:24 PM To: Erik.Cockrell@polycom.com; sacm@ietf.org Subject: Re: [sacm] Copy of current use cases? http://www.ietf.org/internet-drafts/draft-waltermire-sacm-use-cases-00.txt From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Cockrell, Erik Sent: Thursday, July 12, 2012 3:49 PM To: sacm@ietf.org Subject: [sacm] Copy of current use cases? Hello all - I have just subscribed to sacm. Where/how can I access the use cases that are being discussed? Thanks. Erik Cockrell, Product Security Engineer, Product Security Office The holy grail of security is airtight input validation. 7700 Parmer Lane, Bldg C, Suite 100, Austin, TX, 78729 | T: 512.372.7155 | M: 512.739.4250 --_000_D7A0423E5E193F40BE6E94126930C4930B9DE2C37EMBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNv bnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEtLQ0K LyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5N c29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHls ZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1V UyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+VGhhbmtzIGZvciBwb3N0aW5n IHRoZSBsaW5rITxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+U2luY2VyZWx5LDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OiMxRjQ5N0QnPkRhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IHNhY20tYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5NaWNoYWVsIEhh bW1lcjxicj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMTIsIDIwMTIgNToyNCBQTTxicj48 Yj5Ubzo8L2I+IEVyaWsuQ29ja3JlbGxAcG9seWNvbS5jb207IHNhY21AaWV0Zi5vcmc8YnI+PGI+ U3ViamVjdDo8L2I+IFJlOiBbc2FjbV0gQ29weSBvZiBjdXJyZW50IHVzZSBjYXNlcz88bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguNXB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PGEgaHJlZj0i aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd2FsdGVybWlyZS1zYWNt LXVzZS1jYXNlcy0wMC50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDAudHh0PC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz4gPGEgaHJlZj0ibWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZyI+c2FjbS1i b3VuY2VzQGlldGYub3JnPC9hPiA8YSBocmVmPSJtYWlsdG86W21haWx0bzpzYWNtLWJvdW5jZXNA aWV0Zi5vcmddIj5bbWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZ108L2E+IDxiPk9uIEJlaGFs ZiBPZiA8L2I+Q29ja3JlbGwsIEVyaWs8YnI+PGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDEy LCAyMDEyIDM6NDkgUE08YnI+PGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9y ZyI+c2FjbUBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFtzYWNtXSBDb3B5IG9mIGN1 cnJlbnQgdXNlIGNhc2VzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkhlbGxv IGFsbCAmIzgyMTE7IEkgaGF2ZSBqdXN0IHN1YnNjcmliZWQgdG8gc2FjbS4mbmJzcDsgV2hlcmUv aG93IGNhbiBJIGFjY2VzcyB0aGUgdXNlIGNhc2VzIHRoYXQgYXJlIGJlaW5nIGRpc2N1c3NlZD8m bmJzcDsgVGhhbmtzLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Z3JheSc+RXJpayBDb2Nr cmVsbCwgUHJvZHVjdCBTZWN1cml0eSBFbmdpbmVlciwgUHJvZHVjdCBTZWN1cml0eSBPZmZpY2U8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxpPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOnJl ZCc+VGhlIGhvbHkgZ3JhaWwgb2Ygc2VjdXJpdHkgaXMgYWlydGlnaHQgaW5wdXQgdmFsaWRhdGlv bi48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWJvdHRvbTozLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Z3JheSc+NzcwMCBQYXJtZXIgTGFuZSwgQmxk ZyBDLCBTdWl0ZSAxMDAsIEF1c3RpbiwgVFgsIDc4NzI5IDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojREQw MDAwJz58IDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpncmF5Jz5UOiA1MTIuMzcyLjcxNTUgPC9zcGFuPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOiNERDAwMDAnPnwgPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmdyYXknPk06IDUxMi43Mzku NDI1MDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2Pjwv Ym9keT48L2h0bWw+ --_000_D7A0423E5E193F40BE6E94126930C4930B9DE2C37EMBCLUSTERxcha_-- From shanna@juniper.net Thu Jul 12 14:32: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 4DE9421F85AA for ; Thu, 12 Jul 2012 14:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 YEnhOrmnhTZY for ; Thu, 12 Jul 2012 14:32:44 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 3D98B21F85AC for ; Thu, 12 Jul 2012 14:32:44 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT/9CnUucWD47axV6MryoSY2VYWo+D33z@postini.com; Thu, 12 Jul 2012 14:33:18 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, 12 Jul 2012 14:32:32 -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, 12 Jul 2012 14:32: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, 12 Jul 2012 17:32:31 -0400 From: Stephen Hanna To: "sacm@ietf.org" Date: Thu, 12 Jul 2012 17:32:30 -0400 Thread-Topic: Text for SACM Use Cases Thread-Index: Ac1gdddAVfX9l7rCS225dS7NP1ZcuA== 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] Text for SACM Use Cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 12 Jul 2012 21:32:45 -0000 Here's some text to be added to UC1, UC2, and UC3 in draft-waltermire-sacm-use-cases-00.txt. These should help explain how the use cases relate to NEA and some other relevant specifications and to each other. Thanks, Steve -------- UC1: Replace "Possible other things to address" and the following two bullets with this text: The Network Endpoint Assessment (NEA) protocols ([PA-TNC], [PB-TNC], [PT-TLS], and [PT-EAP]) may be used to query and transport the things to be measured, as well as providing for manual or automated remediation and mitigation. SCAP content ([XCCDF], [OVAL], [OCIL], etc.) may be transported over the NEA protocols to indicate which things are to be measured and send the results of the measurements. And enforcement may be implemented with [RADIUS] or [DIAMETER]. UC2: Insert this text before "Possible other things to address" and remove the first bullet after "Possible other things": The Trusted Computing Group's [IF-MAP] protocol provides a standard way to rapidly share events and updates related to user/device behavior and network events, enabling logging or swift response such as reduced or terminated access. UC3: Insert this text before "Possible other things to address" and remove the first bullet after "Possible other things": This use case extends UC1 to ensure that changes to the things measured in UC1 are rapidly detected, reported, and optionally responded to with manual or automated remediation and mitigation. From Erik.Cockrell@polycom.com Fri Jul 13 07:56: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 54EEA21F87C1 for ; Fri, 13 Jul 2012 07:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=0.929, 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 YEQrZ8rMyGzV for ; Fri, 13 Jul 2012 07:56:23 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id D832421F87C8 for ; Fri, 13 Jul 2012 07:56:22 -0700 (PDT) Received: from CRPMBOXPRD02.polycom.com ([fe80::b94b:feef:580:da7f]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Fri, 13 Jul 2012 07:56:58 -0700 From: "Cockrell, Erik" To: Michael Hammer , "sacm@ietf.org" Date: Fri, 13 Jul 2012 07:56:57 -0700 Thread-Topic: Copy of current use cases? Thread-Index: Ac1gZ2YcinKtOyJVRym7MoAsaKIy4gADUFrgACTDyzA= Message-ID: <4038C3329CFD1D4EABBE867CFB81AC30013937AA7F@CRPMBOXPRD02.polycom.com> References: <4038C3329CFD1D4EABBE867CFB81AC30013937A8B5@CRPMBOXPRD02.polycom.com> <00C069FD01E0324C9FFCADF539701DB38C2809@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38C2809@EX2K10MB1.corp.yaanatech.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_4038C3329CFD1D4EABBE867CFB81AC30013937AA7FCRPMBOXPRD02p_" MIME-Version: 1.0 Subject: Re: [sacm] Copy of current use cases? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 13 Jul 2012 14:56:25 -0000 --_000_4038C3329CFD1D4EABBE867CFB81AC30013937AA7FCRPMBOXPRD02p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks very much From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, July 12, 2012 5:24 PM To: Cockrell, Erik; sacm@ietf.org Subject: RE: Copy of current use cases? http://www.ietf.org/internet-drafts/draft-waltermire-sacm-use-cases-00.txt From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Coc= krell, Erik Sent: Thursday, July 12, 2012 3:49 PM To: sacm@ietf.org Subject: [sacm] Copy of current use cases? Hello all - I have just subscribed to sacm. Where/how can I access the use= cases that are being discussed? Thanks. Erik Cockrell, Product Security Engineer, Product Security Office The holy grail of security is airtight input validation. 7700 Parmer Lane, Bldg C, Suite 100, Austin, TX, 78729 | T: 512.372.7155 | = M: 512.739.4250 --_000_4038C3329CFD1D4EABBE867CFB81AC30013937AA7FCRPMBOXPRD02p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks very much

 

From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, July 12, 2012 5:24 PM
To: Cockrell, Erik= ; sacm@ietf.org
Subject: RE: Copy of current use cases?

 

http://www.ietf.org/internet-drafts/draft-walte= rmire-sacm-use-cases-00.txt

<= span style=3D'color:#1F497D'> 

 

=

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.or= g] On Behalf Of Cockrell, Erik
Sent: Thursday, July 12, 20= 12 3:49 PM
To: sacm@ietf.org
Subject: [sacm] Copy of cu= rrent use cases?

 

Hello all – I have just subscri= bed to sacm.  Where/how can I access the use cases that are being disc= ussed?  Thanks.

 

Erik Cockrell, Product Security Engineer, Product = Security Office

The holy grai= l of security is airtight input validation.

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

 

 

= --_000_4038C3329CFD1D4EABBE867CFB81AC30013937AA7FCRPMBOXPRD02p_-- From athiasjerome@gmail.com Sat Jul 14 04:59: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 C784A21F84E6 for ; Sat, 14 Jul 2012 04:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.855 X-Spam-Level: X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 ZZ+wEHuqxERs for ; Sat, 14 Jul 2012 04:59:31 -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 C709321F84B3 for ; Sat, 14 Jul 2012 04:59:30 -0700 (PDT) Received: by eekd4 with SMTP id d4so1365851eek.31 for ; Sat, 14 Jul 2012 05:00:09 -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 :content-type:content-transfer-encoding; bh=2LROM6+LEbp2quB+Xk3lHyi6Qxt9StiaeZi6Zt82kBk=; b=S9Sfdhe/E5yS3ex0OV8rRh9uqALzGPU0VmLqx9CnXy8QLyrGwmBtf4Kkst8eaoG2Lq nFv6feDAobDJsPTl2111Xoy2xxLz+qj3BAC2Y4MXLGP/WEMxCt9WaYr87sp2P9Af/xbK jsFgfg+VfsXF9mcI19/TxN/EKMSNtOUkIix4sAUnAp2jnIrxts3SYxxAyaVqy2joq7gH U5qaFl9Mjg81uKaklh/4cxFcT3LYWPCGuJ4k/hXhMNtbYJSw2+CQfo+OYtbvIXa0vQ8r jaKSVpxlhiL6wNGTJ/Uc3HuXUBzHkwezrUqaw2gzENK5u2ts1qW4BZt8N9wdXWtTNWLY qUrw== Received: by 10.14.175.134 with SMTP id z6mr1859559eel.12.1342267209031; Sat, 14 Jul 2012 05:00:09 -0700 (PDT) Received: from [192.168.1.82] (39.117.199.77.rev.sfr.net. [77.199.117.39]) by mx.google.com with ESMTPS id a7sm3441921eem.3.2012.07.14.05.00.05 (version=SSLv3 cipher=OTHER); Sat, 14 Jul 2012 05:00:08 -0700 (PDT) Message-ID: <50015F41.4070404@gmail.com> Date: Sat, 14 Jul 2012 12:00:01 +0000 From: Jerome Athias User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "sacm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sacm] New international plan to tackle cyber crime X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 14 Jul 2012 11:59:32 -0000 Hi list, quite off-topic, but the reports are interesting http://www.homelandsecuritynewswire.com/dr20120713-new-international-plan-to-tackle-cyber-crime-make-internet-safer From david.waltermire@nist.gov Mon Jul 16 14:42: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 289DE11E80FD for ; Mon, 16 Jul 2012 14:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.095 X-Spam-Level: X-Spam-Status: No, score=-6.095 tagged_above=-999 required=5 tests=[AWL=0.504, 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 VprQSRhIgkMG for ; Mon, 16 Jul 2012 14:42:51 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 26D8E11E8106 for ; Mon, 16 Jul 2012 14:42:51 -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; Mon, 16 Jul 2012 17:43:33 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 16 Jul 2012 17:43:35 -0400 From: "Waltermire, David A." To: "sacm@ietf.org" Date: Mon, 16 Jul 2012 17:43:34 -0400 Thread-Topic: SACM Use Cases Updated Thread-Index: Ac1jm9XrAK93NgVoQlyiwLE7fj55/A== 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [sacm] SACM Use Cases Updated X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 16 Jul 2012 21:42:52 -0000 SSBqdXN0IHBvc3RlZCBhbiB1cGRhdGVkIFNBQ00gdXNlIGNhc2VzIGRvY3VtZW50IGJhc2VkIG9u IGFsbCB0aGUgY29udHJpYnV0aW9ucyBhbmQgY29tbWVudHMgdG8gZGF0ZS4gIFRoYW5rcyBmb3Ig YWxsIHRoZSBpbnB1dCEgIExpbmtzIHRvIHRoZSB1cGRhdGVkIGRvY3VtZW50IGFyZSBiZWxvdy4g IEknZCBhcHByZWNpYXRlIGFueSBmZWVkYmFjay4NCg0KU2luY2VyZWx5LA0KRGF2ZQ0KDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg W21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBKdWx5IDE2 LCAyMDEyIDU6MzggUE0NClRvOiBXYWx0ZXJtaXJlLCBEYXZpZCBBLg0KU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13YWx0ZXJtaXJlLXNhY20tdXNlLWNhc2VzLTAx LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13YWx0ZXJtaXJlLXNhY20tdXNl LWNhc2VzLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEYXZpZCBX YWx0ZXJtaXJlIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6 CSBkcmFmdC13YWx0ZXJtaXJlLXNhY20tdXNlLWNhc2VzDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJ CSBBbmFseXNpcyBvZiBTZWN1cml0eSBBdXRvbWF0aW9uIGFuZCBDb250aW51b3VzIE1vbml0b3Jp bmcgKFNBQ00pIFVzZSBDYXNlcw0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDctMTYNCldHIElEOgkJ IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMw0KVVJMOiAgICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13YWx0ZXJtaXJl LXNhY20tdXNlLWNhc2VzLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMNCkh0bWxpemVk OiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FsdGVybWlyZS1zYWNt LXVzZS1jYXNlcy0wMQ0KRGlmZjogICAgICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDENCg0KQWJzdHJhY3Q6 DQogICBUaGlzIGRvY3VtZW50IGlkZW50aWZpZXMgZm91bmRhdGlvbmFsIHVzZSBjYXNlcywgZGVy aXZlZCBmdW5jdGlvbmFsDQogICBjYXBhYmlsaXRpZXMgYW5kIHJlcXVpcmVtZW50cywgYXJjaGl0 ZWN0dXJhbCBjb21wb25lbnRzLCBhbmQgdGhlDQogICBzdXBwb3J0aW5nIHN0YW5kYXJkcyBuZWVk ZWQgdG8gZGVmaW5lIGFuIGludGVyb3BlcmFibGUsIGF1dG9tYXRpb24NCiAgIGluZnJhc3RydWN0 dXJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgdGltZWx5LCBhY2N1cmF0ZSBhbmQgYWN0aW9uYWJsZQ0K ICAgc2l0dWF0aW9uYWwgYXdhcmVuZXNzIG92ZXIgYW4gb3JnYW5pemF0aW9uJ3MgSVQgc3lzdGVt cy4gIEF1dG9tYXRpb24NCiAgIHRvb2xzIGltcGxlbWVudGluZyBhIGNvbnRpbnVvdXMgbW9uaXRv cmluZyBhcHByb2FjaCB3aWxsIHV0aWxpemUgdGhpcw0KICAgaW5mcmFzdHJ1Y3R1cmUgdG9nZXRo ZXIgd2l0aCBleGlzdGluZyBhbmQgZW1lcmdpbmcgZXZlbnQsIGluY2lkZW50DQogICBhbmQgbmV0 d29yayBtYW5hZ2VtZW50IHN0YW5kYXJkcyB0byBwcm92aWRlIHZpc2liaWxpdHkgaW50byB0aGUg c3RhdGUNCiAgIG9mIGFzc2V0cywgdXNlciBhY3Rpdml0aWVzIGFuZCBuZXR3b3JrIGJlaGF2aW9y LiAgU3Rha2Vob2xkZXJzIHdpbGwNCiAgIGJlIGFibGUgdG8gdXNlIHRoZXNlIHRvb2xzIHRvIGFn Z3JlZ2F0ZSBhbmQgYW5hbHl6ZSByZWxldmFudCBzZWN1cml0eQ0KICAgYW5kIG9wZXJhdGlvbmFs IGRhdGEgdG8gdW5kZXJzdGFuZCB0aGUgb3JnYW5pemF0aW9ucyBzZWN1cml0eQ0KICAgcG9zdHVy ZSwgcXVhbnRpZnkgYnVzaW5lc3MgcmlzaywgYW5kIG1ha2UgaW5mb3JtZWQgZGVjaXNpb25zIHRo YXQNCiAgIHN1cHBvcnQgb3JnYW5pemF0aW9uYWwgb2JqZWN0aXZlcyB3aGlsZSBwcm90ZWN0aW5n IGNyaXRpY2FsDQogICBpbmZvcm1hdGlvbi4gIE9yZ2FuaXphdGlvbnMgd2lsbCBiZSBhYmxlIHRv IHVzZSB0aGVzZSB0b29scyB0bw0KICAgYXVnbWVudCBhbmQgYXV0b21hdGUgaW5mb3JtYXRpb24g c2hhcmluZyBhY3Rpdml0aWVzIHRvIGNvbGxhYm9yYXRlDQogICB3aXRoIHBhcnRuZXJzIHRvIGlk ZW50aWZ5IGFuZCBtaXRpZ2F0ZSB0aHJlYXRzLiAgT3RoZXIgYXV0b21hdGlvbg0KICAgdG9vbHMg d2lsbCBiZSBhYmxlIHRvIGludGVncmF0ZSB3aXRoIHRoZXNlIGNhcGFiaWxpdGllcyB0byBlbmZv cmNlDQogICBwb2xpY2llcyBiYXNlZCBvbiBodW1hbiBkZWNpc2lvbnMgdG8gaGFyZGVuIHN5c3Rl bXMsIHByZXZlbnQgbWlzdXNlDQogICBhbmQgcmVkdWNlIHRoZSBvdmVyYWxsIGF0dGFjayBzdXJm YWNlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJp YXQNCg== From amontville@tripwire.com Tue Jul 17 08: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 1425421F86AA for ; Tue, 17 Jul 2012 08:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.974 X-Spam-Level: X-Spam-Status: No, score=-3.974 tagged_above=-999 required=5 tests=[AWL=-0.375, 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 M-R3u3KGR7OA for ; Tue, 17 Jul 2012 08:30:20 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0133021F86A2 for ; Tue, 17 Jul 2012 08:30:19 -0700 (PDT) Received: from mail65-db3-R.bigfish.com (10.3.81.231) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Jul 2012 15:31:07 +0000 Received: from mail65-db3 (localhost [127.0.0.1]) by mail65-db3-R.bigfish.com (Postfix) with ESMTP id 9791D10025D; Tue, 17 Jul 2012 15:31:06 +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: -36 X-BigFish: VPS-36(zzbb2dI98dI9371I1b0aL936eI148cI542M1432I1528Izz1202hzz1033IL8275dhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail65-db3 (localhost.localdomain [127.0.0.1]) by mail65-db3 (MessageSwitch) id 1342539064584981_8655; Tue, 17 Jul 2012 15:31:04 +0000 (UTC) Received: from DB3EHSMHS001.bigfish.com (unknown [10.3.81.230]) by mail65-db3.bigfish.com (Postfix) with ESMTP id 8CFD9320098; Tue, 17 Jul 2012 15:31:04 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by DB3EHSMHS001.bigfish.com (10.3.87.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 17 Jul 2012 15:31:03 +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, 17 Jul 2012 08:32:29 -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, 17 Jul 2012 08:31:00 -0700 From: Adam Montville To: "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: [sacm] SACM Use Cases Updated Thread-Index: Ac1jm9XrAK93NgVoQlyiwLE7fj55/AAlVPQA Date: Tue, 17 Jul 2012 15:30: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.2.120421 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: <43F15DAC21289C469A21FB14B09E37D7@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] SACM Use Cases Updated X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 17 Jul 2012 15:30:21 -0000 Dave, Thanks for posting. And, thanks to everyone who contributed. Regards, Adam On 7/16/12 2:43 PM, "Waltermire, David A." wrote: >I just posted an updated SACM use cases document based on all the >contributions and comments to date. Thanks for all the input! Links to >the updated document are below. I'd appreciate any feedback. > >Sincerely, >Dave > > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Monday, July 16, 2012 5:38 PM >To: Waltermire, David A. >Subject: New Version Notification for >draft-waltermire-sacm-use-cases-01.txt > > >A new version of I-D, draft-waltermire-sacm-use-cases-01.txt >has been successfully submitted by David Waltermire and posted to the >IETF repository. > >Filename: draft-waltermire-sacm-use-cases >Revision: 01 >Title: Analysis of Security Automation and Continuous Monitoring (SACM) >Use Cases >Creation date: 2012-07-16 >WG ID: Individual Submission >Number of pages: 13 >URL: =20 >http://www.ietf.org/internet-drafts/draft-waltermire-sacm-use-cases-01.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-waltermire-sacm-use-cases >Htmlized: =20 >http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-01 >Diff: =20 >http://tools.ietf.org/rfcdiff?url2=3Ddraft-waltermire-sacm-use-cases-01 > >Abstract: > This document identifies foundational use cases, derived functional > capabilities and requirements, architectural components, and the > supporting standards needed to define an interoperable, automation > infrastructure required to support timely, accurate and actionable > situational awareness over an organization's IT systems. Automation > tools implementing a continuous monitoring approach will utilize this > infrastructure together with existing and emerging event, incident > and network management standards to provide visibility into the state > of assets, user activities and network behavior. Stakeholders will > be able to use these tools to aggregate and analyze relevant security > and operational data to understand the organizations security > posture, quantify business risk, and make informed decisions that > support organizational objectives while protecting critical > information. Organizations will be able to use these tools to > augment and automate information sharing activities to collaborate > with partners to identify and mitigate threats. Other automation > tools will be able to integrate with these capabilities to enforce > policies based on human decisions to harden systems, prevent misuse > and reduce the overall attack surface. > > =20 > =20 > > >The IETF Secretariat >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm > From Kent_Landfield@mcafee.com Tue Jul 17 16:43:54 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECD111E80E2 for ; Tue, 17 Jul 2012 16:43:54 -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=[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 BmHYYG6hY0oV for ; Tue, 17 Jul 2012 16:43:53 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 47E1A11E80D2 for ; Tue, 17 Jul 2012 16:43:53 -0700 (PDT) Received: from DALEXHT1.corp.nai.org (unknown [10.64.5.51]) by dalsmrelay2.nai.com with smtp id 5081_1cbf_6913c796_47f9_470e_832b_7f41fa1af0fe; Tue, 17 Jul 2012 18:44:40 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::b534:4a0d:1289:2d2d]) by DALEXHT1.corp.nai.org ([::1]) with mapi; Tue, 17 Jul 2012 18:44:33 -0500 From: To: Date: Tue, 17 Jul 2012 18:45:28 -0500 Thread-Topic: SACM Vancouver Side Meeting Agenda Thread-Index: Ac1kdh19hE1o2BRuTyS6ItQvSXawkQ== 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 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC2B13FA37698kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: [sacm] SACM Vancouver Side Meeting Agenda X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 17 Jul 2012 23:43:54 -0000 --_000_CC2B13FA37698kentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, The Security Automation and Continuous Monitoring effort is going to have a= Side meeting at the IETF 84 meeting in Vancouver later this month. What f= ollows is a draft agenda for the meeting. I encourage all to send suggesti= ons for additional discussion items to the list so we can get them added to= the agenda as needed. 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 We will be requesting MeetEcho support. When we know more we will update th= e list. 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 We encourage you to submit other topics you would like to see added to the = agenda. Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com --_000_CC2B13FA37698kentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
All,=

 

T= he Security Automation and Continuous Monitoring effort is going to have a = Side meeting at the IETF 84 meeting in Vancouver later this month.  Wh= at follows is a draft agend= a for the meeting.  I encourage all to send suggestions for additional= discussion items to the list so we can get them added to the agenda as nee= ded.


 

SACM Side Me= eting IETF 84

 

Security Automation and Continuous Moni= toring =96 SACM (pronounced as Sack-em)

 

Sid= e Meeting Chairs: David Waltermire, Kent Landfield

 

Description: A side meeting to continue the discussions around secu= rity automation and continuous monitoring working group development efforts= . In this meeting we will be reviewing the Use Case document and then focus= ing on a draft charter for the potential working group.

 

Here are the meeting specifics:<= /p>


=

Date: Thursday, Augus= t 2, 2012

Time: 18:30 =96 20:00 PDT

Room: Plaza C

 

We will be requesting MeetEcho su= pport. When we know more we will update the list.

 

Agenda: 

            * = Agenda Bashing

            * Status of work sinc= e last IETF meeting=

         &nbs= p;  * Internet Draft Discussions to:

            =       - support the charter/use cases=

      =             - other potential future drafts

            * Discu= ss draft WG Charter<= /o:p>

 

Current Drafts:

<= p class=3D"MsoNormal" style=3D"margin-top: 0in; margin-right: 0in; margin-l= eft: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New= Roman', serif; "> - http= ://www.ietf.org/id/draft-waltermire-sacm-use-cases-01.txt - <= /span>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 Ex= change and Management

 <= /p>


We encourage you to submit= other topics you would like to se= e added to the agenda.

 

Thanks.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 <= /span>
= Mobile: +1.81= 7.637.8026=
Web: www.mcafee.com
= --_000_CC2B13FA37698kentlandfieldmcafeecom_-- From cmschmidt@mitre.org Wed Jul 18 08:43: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 228F621F8659 for ; Wed, 18 Jul 2012 08:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0i7-rCV8JBM for ; Wed, 18 Jul 2012 08:43:43 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0676721F8798 for ; Wed, 18 Jul 2012 08:43:43 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F30FE21B0098; Wed, 18 Jul 2012 11:44:32 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C03CB21B00E5; Wed, 18 Jul 2012 11:44:32 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.64]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.02.0309.002; Wed, 18 Jul 2012 11:44:32 -0400 From: "Schmidt, Charles M." To: "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: SACM Use Cases Updated Thread-Index: Ac1jm9XrAK93NgVoQlyiwLE7fj55/ABXmEJA Date: Wed, 18 Jul 2012 15:44:31 +0000 Message-ID: <80B432C0A0D105468E74A98942733F771ABA5B75@IMCMBX04.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.58] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0074_01CD64D2.4AF0B090" MIME-Version: 1.0 Subject: Re: [sacm] SACM Use Cases Updated X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 18 Jul 2012 15:43:44 -0000 ------=_NextPart_000_0074_01CD64D2.4AF0B090 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Dave, Thanks for all your effort getting this together. I was noting the multiple references to TCG's TNC protocols (both the IETF NEA work which mirrors some of the exchanges, and the reference to MAP, which does not have a corresponding IETF effort that I am aware of). I was curious as to how closely bundled you see SACM being with TNC. Was your thought just to utilize the defined network protocols or were you envisioning that other aspects of the TNC and/or NEA architecture would be part of the solution? Also, in my reading of the use cases, you have identified lots of existing efforts for network exchange of information. Are you seeing this effort as largely re-using existing wire protocols, possibly with different payloads, or do you feel that wire-protocol development would be part of a SACM charter. Right now, as far as my understanding goes, it seems like the wire protocols, and many of the data model references utilize existing work and that the needed development would be in designing a composition (i.e., what I would call an architecture, although I'm probably not using that word correctly in a formal sense) of these existing works. Is this correct? Certainly this effort would want to make use of existing work rather than duplicating development with other efforts - I'm just trying to get a better sense of what SACM might consider "covered-ground" vs. what it considers to be in need of development/management/refinement. I don't know if these questions are relevant for a use case doc, but I imagine any charter discussions would need some level of answers on these. Thanks, Charles >-----Original Message----- >From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >Waltermire, David A. >Sent: Monday, July 16, 2012 4:44 PM >To: sacm@ietf.org >Subject: [sacm] SACM Use Cases Updated > >I just posted an updated SACM use cases document based on all the >contributions and comments to date. Thanks for all the input! Links to the >updated document are below. I'd appreciate any feedback. > >Sincerely, >Dave > > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Monday, July 16, 2012 5:38 PM >To: Waltermire, David A. >Subject: New Version Notification for draft-waltermire-sacm-use-cases-01.txt > > >A new version of I-D, draft-waltermire-sacm-use-cases-01.txt >has been successfully submitted by David Waltermire and posted to the IETF >repository. > >Filename: draft-waltermire-sacm-use-cases >Revision: 01 >Title: Analysis of Security Automation and Continuous Monitoring >(SACM) Use Cases >Creation date: 2012-07-16 >WG ID: Individual Submission >Number of pages: 13 >URL: http://www.ietf.org/internet-drafts/draft-waltermire-sacm-use- >cases-01.txt >Status: http://datatracker.ietf.org/doc/draft-waltermire-sacm-use-cases >Htmlized: http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-01 >Diff: http://tools.ietf.org/rfcdiff?url2=draft-waltermire-sacm-use-cases- >01 > >Abstract: > This document identifies foundational use cases, derived functional > capabilities and requirements, architectural components, and the > supporting standards needed to define an interoperable, automation > infrastructure required to support timely, accurate and actionable > situational awareness over an organization's IT systems. Automation > tools implementing a continuous monitoring approach will utilize this > infrastructure together with existing and emerging event, incident > and network management standards to provide visibility into the state > of assets, user activities and network behavior. Stakeholders will > be able to use these tools to aggregate and analyze relevant security > and operational data to understand the organizations security > posture, quantify business risk, and make informed decisions that > support organizational objectives while protecting critical > information. Organizations will be able to use these tools to > augment and automate information sharing activities to collaborate > with partners to identify and mitigate threats. Other automation > tools will be able to integrate with these capabilities to enforce > policies based on human decisions to harden systems, prevent misuse > and reduce the overall attack surface. > > > > >The IETF Secretariat >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_000_0074_01CD64D2.4AF0B090 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCCBS0w ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6 8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5 Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ 9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX /MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN 2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI 8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED 393Jb0YbzrcElFv6ZDCCBhwwggQEoAMCAQICCjXQ+u0AAgAAHHUwDQYJKoZIhvcNAQEFBQAwUDET MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMDIwODE4MjYzN1oXDTE1MDIwNzE4MjYzN1owTjEL MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxHjAcBgNVBAMTFVNj aG1pZHQuQ2hhcmxlcy4yNTY1ODCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMrfqe4f m+ZeRZvWO7aYp89KmWSTnFKgZjWprxFQ8zmAlth3LKEVdNn4wZgdUz54uHZvi5uCvcQU0trt2iDw F/hQ6jdn3VZhZsmA7TnRHRocBYIWdhvTEjOXpsKj51kz6uizhseb3lGubSj2DwN6A6C4f5SQt5yw CkpwX0pz9WqaSrT2aGoHgWx9MOBww1+v5DS5VNhHIyCVw0eFoSJ8aZxcWMIRBDdoFOCFR33KKfU9 P+/vYaG7OiNQlko5d0vvCBApYGURyaBKde1Krd0wRTP9FCc5GD+5OYxZx4XAhBMgQuh2Hv7E8EM+ ORpRQ2fW1Pno5dTl/92Sl1RITgxcyvkCAwEAAaOCAfgwggH0MCgGA1UdJQQhMB8GCCsGAQUFBwME BgkrBgEEAXMCAQcGCCsGAQUFBwMCMB0GA1UdDgQWBBTYG13f8BosUG6c5VDRxlP6AJYFezAOBgNV HQ8BAf8EBAMCBsAwHgYDVR0RBBcwFYETY21zY2htaWR0QG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRp ZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9y Zy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYI KwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUy MENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+Bgkr BgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsShb6uAYE2g9KXfYeg+0kCAWQC AQcwFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgwNAYJKwYBBAGCNxUKBCcwJTAKBggrBgEFBQcDBDAL BgkrBgEEAXMCAQcwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggIBALqulox86p0q7Ry3fzT8 GOIMzBtv2HfzWXNciUVnvEtYtqfeSL+SmDU6JnVX2Mga7yzUdHnZ5J8+VfSARUpIIxoe56EI0Zc5 DJx1C4Uu5RErFCDf6Ye+YjZQHx6PI9jajX3b0Z1yyHDs5pfaDHZHLR7H5POdhJuna2SCk+d35/0g ciyUfa+yuwSZvpxsUSz6X/RnNe07w4K8631cShm3aAFE2ZQNndk+qqVDQ10MuDM/hLJMQFKCe+KV V2qqtrU879aF4nUh6aoq/i5pjHmV1c2uPx+LVX9uwaOQPOxIgbEuSC8dP6W5FAquGgLNI0bxCn5q eMza1rOXVQcpI5TCVzBtWfqPp0ipzWe/+PCl/T/aFbTeygC/JY/KjSpD+PMzOFjf7lhGjIx/bQUp pgbrcaUU2YX3ueygXDn9MyZZdS58hu49tC1Juq2TmhG8q/HAgD631tqRde6a2fuKfQX6cE0L6T2/ +bU39U+EExPz00bBzc2aMKMgayCFoqU2xH/nl2r8I9FiZbjcBwl02kvumOYcRTftIzesoj59LgGR y6iS728LHv1SJw11FE2yCVYb4Q1xtlKc8d9qp8p5UcCIu+zKFYqFRqSbdPBav7ZI169fR19tZWwy CzmXDYACGX6X38coRpdaTStwYC9Ed/2oB1bsr8iw57EAwD25hKX8RcbdMIIGYjCCBEqgAwIBAgIK FJcW0gAAAAAABDANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQ RSBSb290IENBLTEwHhcNMTEwNjE0MTc0NDQ0WhcNMTcwNjE0MTc1NDQ0WjBQMRMwEQYKCZImiZPy LGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0 aW9uIFBFIENBLTEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDSxK9RXieqdTz4JWRk RMs/EOuF0P0S9SbspadLJkx/LDDnaAwmAnqfqm1n7/p82oVjy1yCye3SZu4Yp7fmDIAtWbkHvYOf xHkRv1ho/fhaNN0YRkd65oJJz2ngEbNZxdIiCoialQfX/iWU7ApQ+ovKbFV60v5E0p2mPncs20NY RfsaetdhnBZbFD9flDcXwJqSvGGGBfm7ifFCR1LrtEcNKjMwf7YEWZO0Vk3ZyhVq+k7JNLEbKv0O fBz8DU8GiGU+j88QlrgGW8PLkwNk7nsS/DJp8aLudTuVqIE2CA9mqn5QjU/EZYNHGzSfCr+/usUm bojyVSJukhhrAXspRAMz+Cia3yi3q3w8TnAljXWN1dhx1iuUv5GxyzMjfqK1tMuCUU2XzGNNqoVa 1mqolBiyDTCOr9d/IC0YHYMBSpQ+xi0x9zjXKt4FmQmkEAZgF4hsZZqcJYL/iCQiwiz8fEyVPZuv oWvdEXOozFYCpmkT0MZCJwyIux0Z6vJp6VLtN/6rZgc2y54HlTrp3ifazmpsfrk3NdHxlZTZug9k jEI+vEoyp/79nAPyTWQQ1MEP0ErCWav80/HOi0MLx/7lIUfvVOjkOFgFb+iDvR4T3RAQrnEpgTO+ fc7Jyzh9LpFDqm0slwDP4Hj9cC3IzdED5BU43PGAe+HoZ8OD/1ovVgwo/wIDAQABo4IBYzCCAV8w EAYJKwYBBAGCNxUBBAMCAQIwIwYJKwYBBAGCNxUCBBYEFFCiOtgZb+Zdflkw5sC2y01sUQaVMB0G A1UdDgQWBBRpZyAh1EjB0BsGbvMIKOI6gn1BMTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRbh32f/my+Aunz4Ck6ilQl LJ84LzBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBv cmF0aW9uJTIwUEUlMjBSb290JTIwQ0EtMS5jcmwwWwYIKwYBBQUHAQEETzBNMEsGCCsGAQUFBzAC hj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBSb290JTIw Q0EtMS5jcnQwDQYJKoZIhvcNAQELBQADggIBAHnDPfdYKxqNOtAYXMyyel83Vs8cCDAQZhSuIB0c 6GkGoEdFrmWH9pwi42V96rCp7TvbNNKNJXbVHfJUAp+uqw663DL/sXXff9ZFxPxKOdPnpA8cKM7R BH9e437Nw3d28A7PaGbP6tXmSqhXAhYZ4U12y1U5cOf2G/phUoAAMlnVJdfmXzMazvLo2SIeixAJ yCze6rHQTFQ/N+gAjbVuRJ+Hs8FEKVzMSwqlNoupe2ELqL4dMAKT6P08sAfxm2SrRlQvcWPYvqM/ 1C10bgc2tdu+WGzRuP5Wx9Yr15KO9SW4z7fn2RVEXQgoDDno5vCIcfUPuKB5n+Kt9eBCitsgSD9y YsNUN9LEVIvjAb8MV2LWLfge1bumo6g7QMRa4Fgifw5siGwi7V2EaJQo6UAIVvxKKFC7W4p6CkrY 2ga1d7GIQ0DPiWZOezOakJVAxL5gf+3WdNt0igKc/yLfbdHn6hCd1KPgDqkSKr8zWOZI/jiDBW95 7xAmaO6QdGQDBZrQHWpIVwQGzF5bGrqms2kq49l3t7KmBu0C/9tExqKAmlf4Y5lfQGdCbKQpAq71 2DVQHYuDXmVQEAc2vlJ1C5hS3Iw9DwBWTfJ4vyB48buhBhbIhPiFta5OizXlKcsIi99ikA1yiZx/ DBtjaw4JU6qJzWUFB2ecyGCNPtNbYjURA0A9MIIGhTCCBG2gAwIBAgIKNdD96gACAAAcdjANBgkq hkiG9w0BAQUFADBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUx IjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTEwHhcNMTIwMjA4MTgyNjM4WhcNMTUw MjA3MTgyNjM4WjBOMQswCQYDVQQGEwJVUzEOMAwGA1UEChMFTUlUUkUxDzANBgNVBAsTBlBlb3Bs ZTEeMBwGA1UEAxMVU2NobWlkdC5DaGFybGVzLjI1NjU4MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAorGFoUP/zIAgRw12Ip6aDMZvkFCAOAQaWFer+PdAqnFNTH1v758Y3SaoCVYV8A+l 4FQryRUFLooFo4iGAGIom2pJ+gOO0McZdIZV77mzpaKIGavG2ER4nNcR6Hmo/iN/SxxK8yCskq9/ gUU/M+OjsQlCihw/6eEDZLyMwH9ugtPbtlt64xKSXQMDAarayTWs6mnW52RQdHukS2Z2PknWnug2 fg1oujCHFhr7ozY8+ACo6A5efGv8mbHupUlKmldD0HImJXSPinWG7eNzhIYG1/TArbMIfngiImIf iHpJM+xUSWDd5Uj1d6BphpdKRjaqr45xpTrdA4epQNj2WP8v7QIDAQABo4ICYTCCAl0wEwYDVR0l BAwwCgYIKwYBBQUHAwQwgZQGCSqGSIb3DQEJDwSBhjCBgzAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAS0w CwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBGTALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEFMB0GA1Ud DgQWBBQoJcp1KJQWbg6AC0wyjvYg3JaECDAOBgNVHQ8BAf8EBAMCBSAwHgYDVR0RBBcwFYETY21z Y2htaWR0QG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8E QjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUl MjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUu b3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpo dHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwj ho6WV4GNiT2CpKsShb6uAYE2hquSaISo7EUCAWQCAQ8wFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgw GwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAHKX0H9OV/dwo Z9iKg2gM3SWDeGQ2fxCS3LW4Bp865NB2wlv8CP74O1xfFXIWqrKtqJZKStZ3D516vwhe6hP9AllS qyoAc6m7gqrpZlcbwyurBXXFhvZ3ZpEyasgyFhVSPqCIn4IOeAeHZSiMIh/rIUspSVW/DsYhpNpd CoiL3R3br1oAfJ+ijTxtTFvo/LLp/xnNONtpObqQylxO0HIU/3boqmFWy+w5P/GooxPwfwczLjks Cdo8RSUh/qZmYOaSRQPlgLMkqIrYwa2TGVWm00K2uIs7V5r3qlulobOccKjM649dORGnJnwCygsd zUbFutDHYSPEpmfY7Bj0oZo2qsJNstpAPqXSX4WvjVroYtV6P2fJ0PsYiTWwQtzBg9gQJfVUSVi6 MvExmrGJLI5kHUtuFGxkyq4arl2nvTGsi6D+75qXktGXaMHC2pPoUa2NXkJ2ogDw/7QPF60DuHJ3 RZ1XYebDKV/JURT6feN5LJvqxxd0KhvEyPZaxPZlkXvbToRWMGUthfYkhaZMvO7TV0nU4+gEjyWG z2AVh9G7nf5D+w/KlQSHrMCxGbwAVgUUIzcQhpD061hCYHisOpsyW/Th0lFgFFcFZeanVsyaLHkq 6cwnCQyPAdBqsKpArS11BP5zt36v7m8M/bm/OYPgNnqNXMU7PqRFVvbXRWV/qlsxggMjMIIDHwIB ATBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UE AxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIKNdD67QACAAAcdTAJBgUrDgMCGgUAoIIBmjAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA3MTgxNTQ0MjJaMCMG CSqGSIb3DQEJBDEWBBQu+3z9YiIyZgpYIdJ7v41vEOU+7jBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDAHBgUrDgMCGjBtBgkrBgEEAYI3EAQxYDBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTAT BgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIK NdD96gACAAAcdjBvBgsqhkiG9w0BCRACCzFgoF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMG CgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgo1 0P3qAAIAABx2MA0GCSqGSIb3DQEBAQUABIIBABDmoOI/sqxpI7sU4WZSbCC0fGZ7RzTiBJDeqGbd ZN+MbPSdOjlkWtUA9oXfz8tuVN0MoPFoqh3sU5X9wsm2OEE7BeQQKCbfR1riYy1qkLKdlYuxp0Ix SS7bpmezFLocqGHUi6vxgTnnX/mjzSVW9WIER4LMSLRt96k4FE77xOIYaHND//r5vZtBkbROqs42 CjF++Uz53HYtbx+fTxL65G9ZZrzE5JueqtyaM7HXblZR8VSAdYnZ2xFHG9JQb4958naAqXKnx0eI dF2h5vjMmPJudYo/Zp9Zvf6nssIWrAGlE0QIWQqn0946YS2Gk819ow6kp0KakvmO4mkAlX84eGcA AAAAAAA= ------=_NextPart_000_0074_01CD64D2.4AF0B090-- From Kent_Landfield@mcafee.com Wed Jul 18 15:27: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 8EEB911E81D0 for ; Wed, 18 Jul 2012 15:27:49 -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=[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 D+dAK4LjjATU for ; Wed, 18 Jul 2012 15:27:48 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED3811E81CD for ; Wed, 18 Jul 2012 15:27:48 -0700 (PDT) Received: from DALEXHT1.corp.nai.org (unknown [10.64.5.51]) by dalsmrelay2.nai.com with smtp id 50f1_9521_446c39e0_ebc7_4908_8d29_0f8847242131; Wed, 18 Jul 2012 17:28:24 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::b534:4a0d:1289:2d2d]) by DALEXHT1.corp.nai.org ([::1]) with mapi; Wed, 18 Jul 2012 17:28:25 -0500 From: To: , Date: Wed, 18 Jul 2012 17:29:19 -0500 Thread-Topic: [emerging-specs] SACM Vancouver Side Meeting Agenda Thread-Index: Ac1lNKS/XS3f+iCsQvyTTgev2KPocQ== Message-ID: In-Reply-To: <9F61CC8E6ED7BC4DBA90C13F25D29C00AB9621@umechphf.easf.csd.disa.mil> 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_CC2CA06237D65kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] [emerging-specs] SACM Vancouver Side Meeting Agenda X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 18 Jul 2012 22:27:49 -0000 --_000_CC2CA06237D65kentlandfieldmcafeecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The purpose of the use case document was to assist in trying to capture hig= her level areas that may drive charter discussions. It is also a means to = describe other related efforts occurring in the IETF. This is not a conops= . We do want to include other areas such as cloud, networks and mobile devi= ces. The focus is really on security automation use cases and what areas c= an drive those sorts of standards efforts. FYI, these are very much in a draft and incomplete state. They need input = and expansion so if you have text or suggestions, please don't hesitate to = send them to the list. Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , "Joseph L CIV (US)" > Reply-To: "emerging-specs@nist.gov" > Date: Wednesday, July 18, 2012 5:13 PM To: "emerging-specs@nist.gov" > Subject: Re: [emerging-specs] SACM Vancouver Side Meeting Agenda What level of specificity is expected? The use cases talk at a high level = about things like: "configuration" that could mean network config; hardware= config; installed software, patches, and drivers; OS and application setti= ng config; and Installed AV, HIPS, and DLP versions and policies + .dat fil= es among others. Do you want supporting details so a user could understand= specifically what each entails, or is the intent to keep it at a high-leve= l general description? Do you also want the specific workflow-specific use cases, such as ensuring= all the correct protective and assessment sensors and tasks are in place, = that correct reporting is occurring, etc? Are the use cases intended to extend to "cloud" environments, networks, and= mobile devices? **** Please note new e-mail address **** Joseph L. Wolfkiel Engineering Group Lead DISA PEO MA/IA52 (301) 225-8820 Joseph.L.Wolfkiel.civ@mail.mil -----Original Message----- From: emerging-specs-bounces@nist.gov [mailto:emerging-specs-bounces@nist.gov] On Behalf Of Kent_Landfield@mca= fee.com Sent: Wednesday, July 18, 2012 5:34 PM To: emerging-specs@nist.gov Subject: Re: [emerging-specs] SACM Vancouver Side Meeting Agenda The current drafts for both the repository and the use cases are available = at the links below. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , "Joseph L CIV (US)" > Reply-To: "emerging-specs@nist.gov" > Date: Wednesday, July 18, 2012 1:07 PM To: "emerging-specs@nist.gov" > Subject: Re: [emerging-specs] SACM Vancouver Side Meeting Agenda Where is the current use cases document? **** Please note new e-mail address **** Joseph L. Wolfkiel Engineering Group Lead DISA PEO MA/IA52 (301) 225-8820 Joseph.L.Wolfkiel.civ@mail.mil -----Original Message----- From: emerging-specs-bounces@nist.gov [mailto:emerging-specs-bounces@nist.gov] On Behalf Of Kent_Landfield@mca= fee.com Sent: Wednesday, July 18, 2012 12:05 PM To: scap-dev@nist.gov Cc: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG; emerging-specs@nist.gov Subject: [emerging-specs] SACM Vancouver Side Meeting Agenda All, The Security Automation and Continuous Monitoring effort is going to have a= Side meeting at the IETF 84 meeting in Vancouver later this month. What f= ollows is a draft agenda for the meeting. I encourage all to send suggesti= ons for additional discussion items to the list so we can get them added to= the agenda as needed. SACM Side Meeting IETF 84 Security Automation and Continuous Monitoring - 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 - 20:00 PDT Room: Plaza C We will be requesting MeetEcho support. When we know more we will update th= e list. 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 We encourage you to submit other topics you would like to see added to the = agenda. Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com --_000_CC2CA06237D65kentlandfieldmcafeecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The = purpose of the use case document was to assist in trying to capture higher = level areas that may drive charter discussions.  It is also a means to= describe other related efforts  occurring in the IETF. This is not a = conops. We do want to include other areas such as cloud, networks and mobil= e devices.  The focus is really on security automation use cases and w= hat areas can drive those sorts of standards efforts.

<= div>FYI, these are very much in a draft and incomplete state.  They ne= ed input and expansion so if you have text or suggestions, please don't hes= itate to send them to the list.

Thanks.
=


McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.80= 26
Web:&n= bsp;www.mcafee.com

=
From: <Wolfkiel>, "Jose= ph L CIV (US)" <jose= ph.l.wolfkiel.civ@mail.mil>
Repl= y-To: "emerging-specs@ni= st.gov" <emerging-specs@n= ist.gov>
Date: Wednesday= , July 18, 2012 5:13 PM
To: "emerging-specs@nist.gov" <<= a href=3D"mailto:emerging-specs@nist.gov">emerging-specs@nist.gov>Subject: Re: [emerging-specs] SA= CM Vancouver Side Meeting Agenda

What level of specificity = is expected?  The use cases talk at a high level about things lik= e: "configuration" that could mean network config; hardware config; install= ed software, patches, and drivers; OS and application setting config; and I= nstalled AV, HIPS, and DLP versions and policies + .dat files among others.=   Do you want supporting details so a user could understand speci= fically what each entails, or is the intent to keep it at a high-level gene= ral description?

Do you also want the specific wor= kflow-specific use cases, such as ensuring all the correct protective and a= ssessment sensors and tasks are in place, that correct reporting is occurri= ng, etc?

Are the use cases intended to extend to "= cloud" environments, networks, and mobile devices?

**** Please note new e-mail address ****

Joseph L= . Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820


-----Original Message-----
Sent: Wednesday, July 18, 2012 5:34 PM
<= div>To: emerging-specs@nist.gov<= /a>




From: <Wolfkiel>, "Joseph L CIV (U= S)" <joseph.l.wolfkiel= .civ@mail.mil>
Date: Wednesday, July= 18, 2012 1:07 PM
Subject: Re: [emerging-specs] S= ACM Vancouver Side Meeting Agenda


<= br>
Where is the current use cases document?

**** Please not= e new e-mail address ****

Joseph L. Wolfkiel
Engineering Gro= up Lead
= DISA PEO MA/IA52
(301) 225-8820

=
-----Original Message-----
Sent: Wednesday, July 18, 2012 12:05 PM
Subject: [emergin= g-specs] SACM Vancouver Side Meeting Agenda

All,
<= br>

The Security Automation and Continuous Monitoring effort= is going to have a Side meeting at the IETF 84 meeting in Vancouver later = this month.  What follows is a draft agenda for the meeting. = ; I encourage all to send suggestions for additional discussion items = to the list so we can get them added to the agenda as needed.




SACM Side Mee= ting IETF 84


Security Automation and Continuo= us Monitoring - SACM (pronounced as Sack-em)


<= /div>
= Side Meeting Chairs: David Waltermire, Kent Landfield

<= div>
Description: A side meeting to continue the discussions around sec= urity automation and continuous monitoring working group development effort= s. In this meeting we will be reviewing the Use Case document and then focu= sing on a draft charter for the potential working group.


Here are the meeting specifics:




Date: Thursday, August 2, 2012

<= /div>
= Time: 18:30 - 20:00 PDT

Room: Plaza C


= We will be requesting MeetEcho support. When we know more we will u= pdate the list.


Agenda:

=
 = ;           * Agenda= Bashing

        &nb= sp;   * Status of work since last IETF meeting
            *= Internet Draft Discussions to:

    &nbs= p;            &= nbsp;- support the charter/use cases

   &nb= sp;            =   - other potential future drafts

  &nbs= p;         * Discuss draft WG = Charter


Current Drafts:

<= div> - http:= //www.ietf.org/id/draft-waltermire-sacm-use-cases-01.txt - draft-walter= mire-sacm-use-cases-01 - Analysis of Security Automation and Continuous Mon= itoring (SACM) Use Cases

- http://www.ietf.org/id/draft-w= altermire-content-repository-00.txt - draft-waltermire-content-reposito= ry-00 - Automated XML Content Data Exchange and Management





We encourage you= to submit other topics you would like to see added to the agenda.


Thanks.



<= /div>

Kent Landfield

McAfee | An Intel Company
Dire= ct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com <http://www.mcafee.com/>

=


= --_000_CC2CA06237D65kentlandfieldmcafeecom_-- From osantos@cisco.com Sun Jul 22 18:03: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 2C0B521F8582 for ; Sun, 22 Jul 2012 18:03:03 -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 7c6CXTbj7geA for ; Sun, 22 Jul 2012 18:03:01 -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 566C821F8585 for ; Sun, 22 Jul 2012 18:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=osantos@cisco.com; l=4151; q=dns/txt; s=iport; t=1343005374; x=1344214974; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=TIl/awTb5IvRV/JtNNqD6lNfQHp+mbeRp0eTPQLU6aM=; b=Q2hvJU+4GVY3azLPzbbVLe4bI5Hm2jQ4KDUhfLnHY95h42NCkXAe0Zre kXrd7JDF9gyq7gwr7QxnthzHsgLK0xA1aXviIHC18ck0xMH5YyYXRO8UO ojV2YkZ3NlLSI2AowQST9kFlgzspxyGYQNxFjApNf8+b6HtywslSlxQYY Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAD+iDFCtJV2a/2dsb2JhbAA7BwO5MYEHgiABAQEEAQEBDwEnGxkDAhICBAEIBwoEAQEfCSIMCxQJCAEBBAESCRmHawufTp8EBItJEIMigyEDlUmBFI0TgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,634,1336348800"; d="scan'208";a="104218211" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 23 Jul 2012 01:02:53 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6N12rra019837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Jul 2012 01:02:53 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Sun, 22 Jul 2012 20:02:53 -0500 From: "Omar Santos (osantos)" To: "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: [sacm] SACM Use Cases Updated Thread-Index: Ac1jm9XrAK93NgVoQlyiwLE7fj55/AE223KA Date: Mon, 23 Jul 2012 01:02:38 +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.2.120421 x-originating-ip: [10.82.236.191] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19058.001 x-tm-as-result: No--58.394500-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: <940C6B41762D6F4D8A76EA613BBF40AA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] SACM Use Cases Updated X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 23 Jul 2012 01:03:03 -0000 Hi Dave/team, My apologies for the delay. The following are a minor suggestion/feedback for the SACM Use Cases (draft-waltermire-sacm-use-cases). Under 3.4. UC4: Secure Exchange of Risk and Compliance Information Perhaps we can add "new reports of potential zero-day vulnerabilities to vendors." I know that we have the following: o Potential sharing of risk and/or threat behavioral information with partners as well as reference data and content like USGCB, NVD, IAVM, and machine-readable US-CERT alerts However, it may be a good use case expand on the notification to vendors of potential zero-day vulnerabilities and also the coordination/exchange of information of potential industry-wide vulnerabilities (i.e., protocol vulnerabilities; or any other issue that may affect multiple vendors). We can also include some language about the aforementioned under "3.5. UC5: Automated Forensics Investigation" 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 On 7/16/12 5:43 PM, "Waltermire, David A." wrote: >I just posted an updated SACM use cases document based on all the >contributions and comments to date. Thanks for all the input! Links to >the updated document are below. I'd appreciate any feedback. > >Sincerely, >Dave > > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Monday, July 16, 2012 5:38 PM >To: Waltermire, David A. >Subject: New Version Notification for >draft-waltermire-sacm-use-cases-01.txt > > >A new version of I-D, draft-waltermire-sacm-use-cases-01.txt >has been successfully submitted by David Waltermire and posted to the >IETF repository. > >Filename: draft-waltermire-sacm-use-cases >Revision: 01 >Title: Analysis of Security Automation and Continuous Monitoring (SACM) >Use Cases >Creation date: 2012-07-16 >WG ID: Individual Submission >Number of pages: 13 >URL: =20 >http://www.ietf.org/internet-drafts/draft-waltermire-sacm-use-cases-01.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-waltermire-sacm-use-cases >Htmlized: =20 >http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-01 >Diff: =20 >http://tools.ietf.org/rfcdiff?url2=3Ddraft-waltermire-sacm-use-cases-01 > >Abstract: > This document identifies foundational use cases, derived functional > capabilities and requirements, architectural components, and the > supporting standards needed to define an interoperable, automation > infrastructure required to support timely, accurate and actionable > situational awareness over an organization's IT systems. Automation > tools implementing a continuous monitoring approach will utilize this > infrastructure together with existing and emerging event, incident > and network management standards to provide visibility into the state > of assets, user activities and network behavior. Stakeholders will > be able to use these tools to aggregate and analyze relevant security > and operational data to understand the organizations security > posture, quantify business risk, and make informed decisions that > support organizational objectives while protecting critical > information. Organizations will be able to use these tools to > augment and automate information sharing activities to collaborate > with partners to identify and mitigate threats. Other automation > tools will be able to integrate with these capabilities to enforce > policies based on human decisions to harden systems, prevent misuse > and reduce the overall attack surface. > > =20 > =20 > > >The IETF Secretariat >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From smullen@us.ibm.com Mon Jul 23 06:52: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 5083121F86C6 for ; Mon, 23 Jul 2012 06:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wglFYJGfY8CT for ; Mon, 23 Jul 2012 06:52:01 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by ietfa.amsl.com (Postfix) with ESMTP id 4478D21F84C5 for ; Mon, 23 Jul 2012 06:52:01 -0700 (PDT) Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 23 Jul 2012 07:51:58 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 23 Jul 2012 07:48:37 -0600 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 018333E40052 for ; Mon, 23 Jul 2012 13:48:33 +0000 (WET) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q6NDmFVf116730 for ; Mon, 23 Jul 2012 07:48:16 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q6NDmCSK008084 for ; Mon, 23 Jul 2012 07:48:12 -0600 Received: from d03nm691.boulder.ibm.com (d03nm691.boulder.ibm.com [9.17.195.188]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q6NDm9Yw007305; Mon, 23 Jul 2012 07:48:09 -0600 To: sacm@ietf.org MIME-Version: 1.0 X-KeepSent: 55C2FFB3:3333CAE6-86257A44:00324AFB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Shawn Mullen Message-ID: Date: Mon, 23 Jul 2012 08:48:07 -0500 X-MIMETrack: Serialize by Router on D03NM691/03/M/IBM(Release 8.5.1FP4HF305 | July 28, 2011) at 07/23/2012 07:48:08, Serialize complete at 07/23/2012 07:48:08 Content-Type: multipart/alternative; boundary="=_alternative 003292F486257A44_=" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12072313-7282-0000-0000-00000B36A9AB Cc: Stephen Whitlock , j.hietala@opengroup.org Subject: [sacm] SCAM Use Case 5 "Define Security Policy" X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 23 Jul 2012 13:52:05 -0000 This is a multipart message in MIME format. --=_alternative 003292F486257A44_= Content-Type: text/plain; charset="US-ASCII" During the Washington DC 7/18/12 Open Group Conference Steve Hanna, John Banghart, and Kathleen.Moriarty presented the SACM overview and called for participation. In particular they ask for review and contributions to the use case definition. Therefore I am proposing the following. Looking at this form how a enterprise would roll-out or implement a SACM environment, I belive the first use case is a simple way to define or author a security policy. This defined policy bridges the organization's security principles and goals into a policy that form that can be applied to a system or used to check a system, e.g. XML. Formally stated I suggest UC5 as follows. 3.5 UC5 Define Security Policy This use case provides a method for IT security principles and requirements to be expressed in a common descriptive language such as XML. This common descriptive language will define the organizations security policy. The security policy definition will be at a sufficiently high level to facilitate simplicity and ease of use, It will not require the author to specify the configuration methods and commands to implementation the policy on the differing IT devices. However it will be possible for the IT devices to bridge this high security policy into actionable configuration settings. Given the above use case, a CIO or CSO can express the security and governance requirements in a single common secruity policy xml file. This single file can be applied to all IT devices such as servers, clients, network devices, etc. Given this state, UC1 can be attained, That is we now have a common security policy which can be assessment and enforced against. A single security policy also facilitates UC4 making GRC reporting common no matter the device being assessed. That is high level security policy not only bridges the organization security principles into a device configuration it also provides the inverse for reporting devices assessment back up to the CIO/CSO level. My other comment is on simplicity. Just like security should be built in and not bolted on. Simplicity should be clearly defined and built in. Complexity is the enemy of security. Not only does simplicity increase adoption it also eliminates the number of components to be trusted and reduces attack surfaces. --------- existing Use cases for reference ----------- 3.1. 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. 3.2. UC2: Behavioral Monitoring and Enforcement Controlling access to networks and services based on the detection and analysis of host and/or user behavior using automatable information from various sources. 3.3. UC3: Security Control Verification and Monitoring Continuous assessment of the implementation and effectiveness of security controls based on machine processable content. 3.4. UC4: Secure Exchange of Governance, Risk and Compliance (GRC) Information Sharing security and/or operationally relevant information within and across trust boundaries using secure, automated communication channels and formats. Shawn Mullen Power Software Security Architect cell - (512) 914-8134 11400 Burnet Road internal 9551 Austin, TX 78758-3493 office (512) 286-7683 (T/L: 363-7683) --=_alternative 003292F486257A44_= Content-Type: text/html; charset="US-ASCII" During the Washington DC 7/18/12 Open Group Conference Steve Hanna,
John Banghart, and Kathleen.Moriarty presented the SACM overview and
called for participation.  In particular they ask for review and
contributions to the use case definition.  Therefore I am proposing the
following.

Looking at this form how a enterprise would roll-out or implement a
SACM environment, I belive the first use case is a simple way to define or
author a security policy.  This defined policy bridges the organization's
security principles and goals into a policy that form that can be applied to a
system or used to check a system, e.g. XML.  Formally  stated I suggest UC5 as
follows.

3.5 UC5 Define Security Policy

   This use case provides a method for IT security principles and requirements
   to be expressed in a common  descriptive  language such as XML. This common
   descriptive  language will define the  organizations  security  policy. The
   security  policy  definition  will  be  at a  sufficiently  high  level  to
   facilitate  simplicity  and ease of use, It will not  require the author to
   specify the configuration methods and commands to implementation the policy
   on the differing IT devices. However it will be possible for the IT devices
   to bridge this high security policy into actionable configuration settings.
   
Given the above use case, a CIO or CSO can express the security and governance
requirements in a single common secruity policy xml file.  This single file
can be applied to all IT devices such as servers,  clients,  network  devices,
etc.  Given this state, UC1 can be attained,  That is we now have a common
security policy which can be assessment and enforced against.

A single security policy also facilitates UC4 making GRC reporting
common no matter  the  device  being  assessed.  That is high  level  security
policy not only bridges the  organization  security  principles  into a device
configuration  it also provides the inverse for reporting  devices  assessment
back up to the CIO/CSO level.  

My other comment is on  simplicity.  Just like security should be built in and
not bolted on.  Simplicity  should be clearly defined and built in. Complexity
is the enemy of security.  Not only does simplicity  increase adoption it also
eliminates the number of components to be trusted and reduces attack surfaces.

--------- existing Use cases for reference -----------

3.1.  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.


3.2.  UC2: Behavioral Monitoring and Enforcement

   Controlling access to networks and services based on the detection
   and analysis of host and/or user behavior using automatable
   information from various sources.

3.3.  UC3: Security Control Verification and Monitoring

   Continuous assessment of the implementation and effectiveness of
   security controls based on machine processable content.

3.4.  UC4: Secure Exchange of Governance, Risk and Compliance (GRC)
      Information

   Sharing security and/or operationally relevant information within and
   across trust boundaries using secure, automated communication
   channels and formats.


Shawn Mullen                          
Power Software Security  Architect

cell -  (512) 914-8134
11400 Burnet Road internal 9551
Austin, TX 78758-3493
office (512) 286-7683
(T/L: 363-7683) --=_alternative 003292F486257A44_=-- From kathleen.moriarty@emc.com Mon Jul 23 07:15: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 68CE921F8598 for ; Mon, 23 Jul 2012 07:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 YJqIUzg-dEi4 for ; Mon, 23 Jul 2012 07:15:23 -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 5912D21F867D for ; Mon, 23 Jul 2012 07:15:22 -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 q6NEFJsA009790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2012 10:15:21 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 23 Jul 2012 10:14:58 -0400 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6NEEwxh001521; Mon, 23 Jul 2012 10:14:58 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Mon, 23 Jul 2012 10:14:57 -0400 From: To: , , Date: Mon, 23 Jul 2012 10:14:56 -0400 Thread-Topic: [sacm] SACM Use Cases Updated Thread-Index: Ac1jm9XrAK93NgVoQlyiwLE7fj55/AE223KAABlqxhA= 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] SACM Use Cases Updated X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 23 Jul 2012 14:15:24 -0000 Thanks, Omar! =20 Those are good suggestions. I agree some will go to UC5, where some of the= work (drafts to support the use cases) is handled in MILE and SACM will ha= ve relationships with the work in MILE (we may need SACM to have drafts sup= porting these relationships). Some of this updated version of UC4 will get= handled through MILE as well, I suspect. It is good to build out the bigg= er picture in this document though, thanks! Best regards, Kathleen -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Oma= r Santos (osantos) Sent: Sunday, July 22, 2012 9:03 PM To: Waltermire, David A.; sacm@ietf.org Subject: Re: [sacm] SACM Use Cases Updated Hi Dave/team, My apologies for the delay. The following are a minor suggestion/feedback for the SACM Use Cases (draft-waltermire-sacm-use-cases). Under 3.4. UC4: Secure Exchange of Risk and Compliance Information Perhaps we can add "new reports of potential zero-day vulnerabilities to vendors." I know that we have the following: o Potential sharing of risk and/or threat behavioral information with partners as well as reference data and content like USGCB, NVD, IAVM, and machine-readable US-CERT alerts However, it may be a good use case expand on the notification to vendors of potential zero-day vulnerabilities and also the coordination/exchange of information of potential industry-wide vulnerabilities (i.e., protocol vulnerabilities; or any other issue that may affect multiple vendors). We can also include some language about the aforementioned under "3.5. UC5: Automated Forensics Investigation" 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 On 7/16/12 5:43 PM, "Waltermire, David A." wrote: >I just posted an updated SACM use cases document based on all the >contributions and comments to date. Thanks for all the input! Links to >the updated document are below. I'd appreciate any feedback. > >Sincerely, >Dave > > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Monday, July 16, 2012 5:38 PM >To: Waltermire, David A. >Subject: New Version Notification for >draft-waltermire-sacm-use-cases-01.txt > > >A new version of I-D, draft-waltermire-sacm-use-cases-01.txt >has been successfully submitted by David Waltermire and posted to the >IETF repository. > >Filename: draft-waltermire-sacm-use-cases >Revision: 01 >Title: Analysis of Security Automation and Continuous Monitoring (SACM) >Use Cases >Creation date: 2012-07-16 >WG ID: Individual Submission >Number of pages: 13 >URL: =20 >http://www.ietf.org/internet-drafts/draft-waltermire-sacm-use-cases-01.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-waltermire-sacm-use-cases >Htmlized: =20 >http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-01 >Diff: =20 >http://tools.ietf.org/rfcdiff?url2=3Ddraft-waltermire-sacm-use-cases-01 > >Abstract: > This document identifies foundational use cases, derived functional > capabilities and requirements, architectural components, and the > supporting standards needed to define an interoperable, automation > infrastructure required to support timely, accurate and actionable > situational awareness over an organization's IT systems. Automation > tools implementing a continuous monitoring approach will utilize this > infrastructure together with existing and emerging event, incident > and network management standards to provide visibility into the state > of assets, user activities and network behavior. Stakeholders will > be able to use these tools to aggregate and analyze relevant security > and operational data to understand the organizations security > posture, quantify business risk, and make informed decisions that > support organizational objectives while protecting critical > information. Organizations will be able to use these tools to > augment and automate information sharing activities to collaborate > with partners to identify and mitigate threats. Other automation > tools will be able to integrate with these capabilities to enforce > policies based on human decisions to harden systems, prevent misuse > and reduce the overall attack surface. > > =20 > =20 > > >The IETF Secretariat >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From kathleen.moriarty@emc.com Mon Jul 23 07:20: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 95FBC21F86FD for ; Mon, 23 Jul 2012 07:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 JemqoGj5aLIY for ; Mon, 23 Jul 2012 07:20:56 -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 55AB821F8703 for ; Mon, 23 Jul 2012 07:20:56 -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 q6NEKrKo002748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2012 10:20:55 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 23 Jul 2012 10:20:40 -0400 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6NEKecE021293; Mon, 23 Jul 2012 10:20:40 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Mon, 23 Jul 2012 10:20:40 -0400 From: To: , Date: Mon, 23 Jul 2012 10:20:38 -0400 Thread-Topic: [sacm] SCAM Use Case 5 "Define Security Policy" Thread-Index: Ac1o2yRXcJvWh3QZRrqAuvTe4CSGgQAAqung 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_F5063677821E3B4F81ACFB7905573F2403B95B39MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: s.whitlock@opengroup.org, j.hietala@opengroup.org Subject: Re: [sacm] SCAM Use Case 5 "Define Security Policy" X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 23 Jul 2012 14:20:57 -0000 --_000_F5063677821E3B4F81ACFB7905573F2403B95B39MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Shawn, Thank you for chiming in! Would you see the proposed UC5 as a new UC1 sinc= e policy is a building block? This would just mean we have another Use cas= e to build out the full picture. Your suggestion makes perfect sense. >From a conversation last week, we may want to have a use case on configurat= ion management as well, before we get to enforcement, reporting, and remedi= ation. It would be a building block along with the policy information sugg= ested by Shawn. Any thoughts? Thanks, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Sha= wn Mullen Sent: Monday, July 23, 2012 9:48 AM To: sacm@ietf.org Cc: Stephen Whitlock; j.hietala@opengroup.org Subject: [sacm] SCAM Use Case 5 "Define Security Policy" During the Washington DC 7/18/12 Open Group Conference Steve Hanna, John Banghart, and Kathleen.Moriarty presented the SACM overview and called for participation. In particular they ask for review and contributions to the use case definition. Therefore I am proposing the following. Looking at this form how a enterprise would roll-out or implement a SACM environment, I belive the first use case is a simple way to define or author a security policy. This defined policy bridges the organization's security principles and goals into a policy that form that can be applied t= o a system or used to check a system, e.g. XML. Formally stated I suggest UC5= as follows. 3.5 UC5 Define Security Policy This use case provides a method for IT security principles and requireme= nts to be expressed in a common descriptive language such as XML. This com= mon descriptive language will define the organizations security policy. = The security policy definition will be at a sufficiently high level = to facilitate simplicity and ease of use, It will not require the author= to specify the configuration methods and commands to implementation the pol= icy on the differing IT devices. However it will be possible for the IT devi= ces to bridge this high security policy into actionable configuration settin= gs. Given the above use case, a CIO or CSO can express the security and governa= nce requirements in a single common secruity policy xml file. This single file can be applied to all IT devices such as servers, clients, network devic= es, etc. Given this state, UC1 can be attained, That is we now have a common security policy which can be assessment and enforced against. A single security policy also facilitates UC4 making GRC reporting common no matter the device being assessed. That is high level secur= ity policy not only bridges the organization security principles into a dev= ice configuration it also provides the inverse for reporting devices assessm= ent back up to the CIO/CSO level. My other comment is on simplicity. Just like security should be built in = and not bolted on. Simplicity should be clearly defined and built in. Complex= ity is the enemy of security. Not only does simplicity increase adoption it a= lso eliminates the number of components to be trusted and reduces attack surfac= es. --------- existing Use cases for reference ----------- 3.1. 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. 3.2. UC2: Behavioral Monitoring and Enforcement Controlling access to networks and services based on the detection and analysis of host and/or user behavior using automatable information from various sources. 3.3. UC3: Security Control Verification and Monitoring Continuous assessment of the implementation and effectiveness of security controls based on machine processable content. 3.4. UC4: Secure Exchange of Governance, Risk and Compliance (GRC) Information Sharing security and/or operationally relevant information within and across trust boundaries using secure, automated communication channels and formats. Shawn Mullen Power Software Security Architect cell - (512) 914-8134 11400 Burnet Road internal 9551 Austin, TX 78758-3493 office (512) 286-7683 (T/L: 363-7683) --_000_F5063677821E3B4F81ACFB7905573F2403B95B39MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Shawn,

 

=

Thank you for chiming in!  Would you see t= he proposed UC5 as a new UC1 since policy is a building block?  This w= ould just mean we have another Use case to build out the full picture. = ; Your suggestion makes perfect sense.

 

From= a conversation last week, we may want to have a use case on configuration = management as well, before we get to enforcement, reporting, and remediatio= n.  It would be a building block along with the policy information sug= gested by Shawn.  Any thoughts?

 

Thanks,<= o:p>

Kathleen=

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] = On Behalf Of Shawn Mullen
Sent: Monday, July 23, 2012 9:48 AM=
To: sacm@ietf.org
Cc: Stephen Whitlock; j.hietala@open= group.org
Subject: [sacm] SCAM Use Case 5 "Define Security P= olicy"

 

During the Washington DC 7/18/12 Open Group Conference St= eve Hanna,
John Banghart, and Kathleen.Moriarty presented the SACM overvi= ew and
called for participation.  In particular they ask for review = and
contributions to the use case definition.  Therefore I am propos= ing the
following.

Looking at this form how a enterprise would roll= -out or implement a
SACM environment, I belive the first use case is a si= mple way to define or
author a security policy.  This defined policy= bridges the organization's
security principles and goals into a policy t= hat form that can be applied to a
system or used to check a system, e.g. = XML.  Formally  stated I suggest UC5 as
follows.
3.5 UC5 = Define Security Policy

   This use case provides a method f= or IT security principles and requirements
   to be expressed i= n a common  descriptive  language such as XML. This common=
&nbs= p;  descriptive  language will define the  organizations &nb= sp;security  policy. The
   security  policy  de= finition  will  be  at a  sufficiently  high  = ;level  to
   facilitate  simplicity  and ease o= f use, It will not  require the author to
   specify the c= onfiguration methods and commands to implementation the policy
<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>  &nb= sp;on the differing IT devices. However it will be possible for the IT devi= ces
   to bridge this high security policy into actionable conf= iguration settings.
   
Given the above use case, a CIO or CS= O can express the security and governance
requirements in a single common= secruity policy xml file.  This single file
can be applied to all I= T devices such as servers,  clients,  network  devices,
et= c.  Given this state, UC1 can be attained,  That is we now have a= common
security policy which can be assessment and enforced against.

A single security policy also facilitates UC4 making GRC reporting
com= mon no matter  the  device  being  assessed.  That= is high  level  security
policy not only bridges the  org= anization  security  principles  into a device
configurati= on  it also provides the inverse for reporting  devices  ass= essment
back up to the CIO/CSO level.  

My other comment is = on  simplicity.  Just like security should be built in and=
not = bolted on.  Simplicity  should be clearly defined and built in. C= omplexity
is the enemy of security.  Not only does simplicity  = increase adoption it also
eliminates the number of components to be trust= ed and reduces attack surfaces.

--------- existing Use cases for refe= rence -----------

3.1.  UC1: Assessment and Enforcement of Accep= table State

   Controlling access to networks and services = based on the assessment
   and analysis of host and/or network = state based on machine
   processable content.

<= br>3.2. &= nbsp;UC2: Behavioral Monitoring and Enforcement

   Control= ling access to networks and services based on the detection
   = and analysis of host and/or user behavior using automatable
   = information from various sources.

3.3.  UC3: Security Control Ve= rification and Monitoring

   Continuous assessment of the i= mplementation and effectiveness of
   security controls based o= n machine processable content.

3.4.  UC4: Secure Exchange of Gov= ernance, Risk and Compliance (GRC)
      Information

   Sharing security and/or operationally relevant information wi= thin and
   across trust boundaries using secure, automated com= munication
   channels and formats.


Shawn Mullen &nbs= p;                     &n= bsp;  
Power Software Security  Architect

cell -  = ;(512) 914-8134
11400 Burnet Road internal 9551
Austin, TX 78758-349= 3
office (512) 286-7683
(T/L: 363-7683)

= --_000_F5063677821E3B4F81ACFB7905573F2403B95B39MX15Acorpemccom_-- From bakerj@mitre.org Mon Jul 23 18:08: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 F28E111E80BF for ; Mon, 23 Jul 2012 18:08:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jK4rqXVQ3Pl8 for ; Mon, 23 Jul 2012 18:08:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9C73F11E8085 for ; Mon, 23 Jul 2012 18:08:23 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B866421B0F2E; Mon, 23 Jul 2012 21:08:22 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A607021B10C0; Mon, 23 Jul 2012 21:08:22 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.210]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0309.002; Mon, 23 Jul 2012 21:08:21 -0400 From: "Baker, Jon" To: Shawn Mullen , "sacm@ietf.org" Thread-Topic: [sacm] SCAM Use Case 5 "Define Security Policy" Thread-Index: AQHNaNpak8miK4GLo0S1olkhqORyEpc3n0bw Date: Tue, 24 Jul 2012 01:08:22 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D38651301F15EC9@IMCMBX03.MITRE.ORG> References: In-Reply-To: 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_6C1C15D8B5510B4B8FF132B10D38651301F15EC9IMCMBX03MITREOR_" MIME-Version: 1.0 Cc: Stephen Whitlock , "j.hietala@opengroup.org" Subject: Re: [sacm] SCAM Use Case 5 "Define Security Policy" X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 24 Jul 2012 01:08:25 -0000 --_000_6C1C15D8B5510B4B8FF132B10D38651301F15EC9IMCMBX03MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How does the use case discussion you provided below align with the work the= opengroup has done on ACEML? 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: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Sha= wn Mullen Sent: Monday, July 23, 2012 9:48 AM To: sacm@ietf.org Cc: Stephen Whitlock; j.hietala@opengroup.org Subject: [sacm] SCAM Use Case 5 "Define Security Policy" During the Washington DC 7/18/12 Open Group Conference Steve Hanna, John Banghart, and Kathleen.Moriarty presented the SACM overview and called for participation. In particular they ask for review and contributions to the use case definition. Therefore I am proposing the following. Looking at this form how a enterprise would roll-out or implement a SACM environment, I belive the first use case is a simple way to define or author a security policy. This defined policy bridges the organization's security principles and goals into a policy that form that can be applied t= o a system or used to check a system, e.g. XML. Formally stated I suggest UC5= as follows. 3.5 UC5 Define Security Policy This use case provides a method for IT security principles and requireme= nts to be expressed in a common descriptive language such as XML. This com= mon descriptive language will define the organizations security policy. = The security policy definition will be at a sufficiently high level = to facilitate simplicity and ease of use, It will not require the author= to specify the configuration methods and commands to implementation the pol= icy on the differing IT devices. However it will be possible for the IT devi= ces to bridge this high security policy into actionable configuration settin= gs. Given the above use case, a CIO or CSO can express the security and governa= nce requirements in a single common secruity policy xml file. This single file can be applied to all IT devices such as servers, clients, network devic= es, etc. Given this state, UC1 can be attained, That is we now have a common security policy which can be assessment and enforced against. A single security policy also facilitates UC4 making GRC reporting common no matter the device being assessed. That is high level secur= ity policy not only bridges the organization security principles into a dev= ice configuration it also provides the inverse for reporting devices assessm= ent back up to the CIO/CSO level. My other comment is on simplicity. Just like security should be built in = and not bolted on. Simplicity should be clearly defined and built in. Complex= ity is the enemy of security. Not only does simplicity increase adoption it a= lso eliminates the number of components to be trusted and reduces attack surfac= es. --------- existing Use cases for reference ----------- 3.1. 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. 3.2. UC2: Behavioral Monitoring and Enforcement Controlling access to networks and services based on the detection and analysis of host and/or user behavior using automatable information from various sources. 3.3. UC3: Security Control Verification and Monitoring Continuous assessment of the implementation and effectiveness of security controls based on machine processable content. 3.4. UC4: Secure Exchange of Governance, Risk and Compliance (GRC) Information Sharing security and/or operationally relevant information within and across trust boundaries using secure, automated communication channels and formats. Shawn Mullen Power Software Security Architect cell - (512) 914-8134 11400 Burnet Road internal 9551 Austin, TX 78758-3493 office (512) 286-7683 (T/L: 363-7683) --_000_6C1C15D8B5510B4B8FF132B10D38651301F15EC9IMCMBX03MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How does the use case dis= cussion you provided below align with the work the opengroup has done on AC= EML?

 <= /p>

Jon

 <= /p>

=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 Collab= oration

The MITRE Corporation

Email: bakerj@mitre= .org

 <= /p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Shawn Mullen
Sent: Monday, July 23, 2012 9:48 AM
To: sacm@ietf.org
Cc: Stephen Whitlock; j.hietala@opengroup.org
Subject: [sacm] SCAM Use Case 5 "Define Security Policy"

 

During the Was= hington DC 7/18/12 Open Group Conference Steve Hanna,
John Banghart, and Kathleen.Moriarty presented the SACM overview= and
called for participation.  In particular they ask for revie= w and
contributions to the use case definition.  Therefore I am p= roposing the
following.

Looking at this form how a enterprise would roll-out or implemen= t a
SACM environment, I belive the first use case is a simple way to= define or
author a security policy.  This defined policy bridges the = organization's
security principles and goals into a policy that form that can b= e applied to a
system or used to check a system, e.g. XML.  Formally  = ;stated I suggest UC5 as
follows.

3.5 UC5 Define Security Policy

   This use case provides a method for IT security pri= nciples and requirements
   to be expressed in a common  descriptive  = ;language such as XML. This common
   descriptive  language will define the  or= ganizations  security  policy. The
   security  policy  definition  will &= nbsp;be  at a  sufficiently  high  level  to
   facilitate  simplicity  and ease of use, = It will not  require the author to
   specify the configuration methods and commands to i= mplementation the policy
   on the differing IT devices. However it will be pos= sible for the IT devices
   to bridge this high security policy into actionable= configuration settings.
   
Given the above use case, a CIO or CSO can express the security = and governance
requirements in a single common secruity policy xml file.  = This single file
can be applied to all IT devices such as servers,  clients,=  network  devices,
etc.  Given this state, UC1 can be attained,  That is = we now have a common
security policy which can be assessment and enforced against.

A single security policy also facilitates UC4 making GRC reporti= ng
common no matter  the  device  being  assess= ed.  That is high  level  security
policy not only bridges the  organization  security &n= bsp;principles  into a device
configuration  it also provides the inverse for reporting &= nbsp;devices  assessment
back up to the CIO/CSO level.  

My other comment is on  simplicity.  Just like securit= y should be built in and
not bolted on.  Simplicity  should be clearly defined = and built in. Complexity
is the enemy of security.  Not only does simplicity  i= ncrease adoption it also
eliminates the number of components to be trusted and reduces at= tack surfaces.

--------- existing Use cases for reference -----------

3.1.  UC1: Assessment and Enforcement of Acceptable State

   Controlling access to networks and services based o= n the assessment
   and analysis of host and/or network state based on = machine
   processable content.


3.2.  UC2: Behavioral Monitoring and Enforcement

   Controlling access to networks and services based o= n the detection
   and analysis of host and/or user behavior using aut= omatable
   information from various sources.

3.3.  UC3: Security Control Verification and Monitoring

   Continuous assessment of the implementation and eff= ectiveness of
   security controls based on machine processable cont= ent.

3.4.  UC4: Secure Exchange of Governance, Risk and Complian= ce (GRC)
      Information

   Sharing security and/or operationally relevant info= rmation within and
   across trust boundaries using secure, automated com= munication
   channels and formats.


Shawn Mullen               &n= bsp;          
Power Software Security  Architect

cell -  (512) 914-8134
11400 Burnet Road internal 9551
Austin, TX 78758-3493
office (512) 286-7683
(T/L: 363-7683)

--_000_6C1C15D8B5510B4B8FF132B10D38651301F15EC9IMCMBX03MITREOR_-- From smullen@us.ibm.com Tue Jul 24 06:05: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 B627A21F85D1 for ; Tue, 24 Jul 2012 06:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFCcRbs5vzK5 for ; Tue, 24 Jul 2012 06:05:32 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by ietfa.amsl.com (Postfix) with ESMTP id B845D21F85E4 for ; Tue, 24 Jul 2012 06:05:31 -0700 (PDT) Received: from /spool/local by e1.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 24 Jul 2012 09:05:19 -0400 Received: from d01dlp02.pok.ibm.com (9.56.224.85) by e1.ny.us.ibm.com (192.168.1.101) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 24 Jul 2012 09:00:28 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 78C696E803F for ; Tue, 24 Jul 2012 09:00:20 -0400 (EDT) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q6OD0Im1421192 for ; Tue, 24 Jul 2012 09:00:19 -0400 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q6OD0Gak020870 for ; Tue, 24 Jul 2012 07:00:17 -0600 Received: from d03nm691.boulder.ibm.com (d03nm691.boulder.ibm.com [9.17.195.188]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q6OD0EPa020770; Tue, 24 Jul 2012 07:00:14 -0600 In-Reply-To: <6C1C15D8B5510B4B8FF132B10D38651301F15EC9@IMCMBX03.MITRE.ORG> References: <6C1C15D8B5510B4B8FF132B10D38651301F15EC9@IMCMBX03.MITRE.ORG> To: "Baker, Jon" , MIME-Version: 1.0 X-KeepSent: 9293EEBB:B38E8C30-86257A45:003BF99F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Shawn Mullen Message-ID: Date: Tue, 24 Jul 2012 08:00:14 -0500 X-MIMETrack: Serialize by Router on D03NM691/03/M/IBM(Release 8.5.1FP4HF305 | July 28, 2011) at 07/24/2012 07:00:13, Serialize complete at 07/24/2012 07:00:13 Content-Type: multipart/alternative; boundary="=_alternative 003E53BB86257A45_=" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12072413-6078-0000-0000-00000D8127BD Cc: Stephen Whitlock , "j.hietala@opengroup.org" , "sacm@ietf.org" Subject: Re: [sacm] SCAM Use Case 5 "Define Security Policy" X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 24 Jul 2012 13:05:34 -0000 This is a multipart message in MIME format. --=_alternative 003E53BB86257A45_= Content-Type: text/plain; charset="US-ASCII" Jon, I believe it aligns exactly with the issues faced by industry CIO/CSOs. Yes, this is what we tried to address with ACEML. I equally believe the IETF process is perfectly suited to address this problem and vet the solution. I also still believe that a blend of SCAP/ACEML/other will be the optimal and probable solution. As to Kathleen's comment/questions... > From a conversation last week, we may want to have a use case on configuration management as well, before we get to enforcement, reporting, and remediation. It would be a building > block along with the policy information suggested by Shawn. Any thoughts? Yes I believe there is a foundational necessity for SACM to address of expressing security and IT governance principles in a policy that can be implemented and enforced by technology solutions. I'm currently on tour of Asia Pacific financial companies and this is a reoccurring theme. Shawn Mullen Power Software Security Architect cell - (512) 914-8134 11400 Burnet Road internal 9551 Austin, TX 78758-3493 office (512) 286-7683 (T/L: 363-7683) From: "Baker, Jon" To: Shawn Mullen/Austin/IBM@IBMUS, "sacm@ietf.org" Cc: Stephen Whitlock , "j.hietala@opengroup.org" Date: 07/23/2012 08:08 PM Subject: RE: [sacm] SCAM Use Case 5 "Define Security Policy" How does the use case discussion you provided below align with the work the opengroup has done on ACEML? Jon ============================================ Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Shawn Mullen Sent: Monday, July 23, 2012 9:48 AM To: sacm@ietf.org Cc: Stephen Whitlock; j.hietala@opengroup.org Subject: [sacm] SCAM Use Case 5 "Define Security Policy" During the Washington DC 7/18/12 Open Group Conference Steve Hanna, John Banghart, and Kathleen.Moriarty presented the SACM overview and called for participation. In particular they ask for review and contributions to the use case definition. Therefore I am proposing the following. Looking at this form how a enterprise would roll-out or implement a SACM environment, I belive the first use case is a simple way to define or author a security policy. This defined policy bridges the organization's security principles and goals into a policy that form that can be applied to a system or used to check a system, e.g. XML. Formally stated I suggest UC5 as follows. 3.5 UC5 Define Security Policy This use case provides a method for IT security principles and requirements to be expressed in a common descriptive language such as XML. This common descriptive language will define the organizations security policy. The security policy definition will be at a sufficiently high level to facilitate simplicity and ease of use, It will not require the author to specify the configuration methods and commands to implementation the policy on the differing IT devices. However it will be possible for the IT devices to bridge this high security policy into actionable configuration settings. Given the above use case, a CIO or CSO can express the security and governance requirements in a single common secruity policy xml file. This single file can be applied to all IT devices such as servers, clients, network devices, etc. Given this state, UC1 can be attained, That is we now have a common security policy which can be assessment and enforced against. A single security policy also facilitates UC4 making GRC reporting common no matter the device being assessed. That is high level security policy not only bridges the organization security principles into a device configuration it also provides the inverse for reporting devices assessment back up to the CIO/CSO level. My other comment is on simplicity. Just like security should be built in and not bolted on. Simplicity should be clearly defined and built in. Complexity is the enemy of security. Not only does simplicity increase adoption it also eliminates the number of components to be trusted and reduces attack surfaces. --------- existing Use cases for reference ----------- 3.1. 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. 3.2. UC2: Behavioral Monitoring and Enforcement Controlling access to networks and services based on the detection and analysis of host and/or user behavior using automatable information from various sources. 3.3. UC3: Security Control Verification and Monitoring Continuous assessment of the implementation and effectiveness of security controls based on machine processable content. 3.4. UC4: Secure Exchange of Governance, Risk and Compliance (GRC) Information Sharing security and/or operationally relevant information within and across trust boundaries using secure, automated communication channels and formats. Shawn Mullen Power Software Security Architect cell - (512) 914-8134 11400 Burnet Road internal 9551 Austin, TX 78758-3493 office (512) 286-7683 (T/L: 363-7683) --=_alternative 003E53BB86257A45_= Content-Type: text/html; charset="US-ASCII" Jon,

I believe it aligns exactly with the issues faced by industry CIO/CSOs.  Yes, this is what we tried to address with ACEML.  I equally believe the IETF process is perfectly suited to address this problem and vet the solution.  I also still believe that a blend of SCAP/ACEML/other will be the optimal and probable solution.

As to Kathleen's comment/questions...
> From a conversation last week, we may want to have a use case on configuration management as well, before we get to enforcement, reporting, and remediation.  It would be a building
> block along with the policy information suggested by Shawn.  Any thoughts?
 
Yes I believe there is a foundational necessity for SACM to address of expressing security and IT governance principles in a policy that can be implemented and enforced by technology solutions.  I'm currently on tour of Asia Pacific financial companies and this is a reoccurring theme.

Shawn Mullen                          
Power Software Security  Architect

cell -  (512) 914-8134
11400 Burnet Road internal 9551
Austin, TX 78758-3493
office (512) 286-7683
(T/L: 363-7683)



From:        "Baker, Jon" <bakerj@mitre.org>
To:        Shawn Mullen/Austin/IBM@IBMUS, "sacm@ietf.org" <sacm@ietf.org>
Cc:        Stephen Whitlock <s.whitlock@opengroup.org>, "j.hietala@opengroup.org" <j.hietala@opengroup.org>
Date:        07/23/2012 08:08 PM
Subject:        RE: [sacm] SCAM Use Case 5 "Define Security Policy"



How does the use case discussion you provided below align with the work the opengroup has done on ACEML?
 
Jon
 
============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: bakerj@mitre.org
 
From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Shawn Mullen
Sent: Monday, July 23, 2012 9:48 AM
To: sacm@ietf.org
Cc: Stephen Whitlock; j.hietala@opengroup.org
Subject: [sacm] SCAM Use Case 5 "Define Security Policy"
 
During the Washington DC 7/18/12 Open Group Conference Steve Hanna,
John Banghart, and Kathleen.Moriarty presented the SACM overview and
called for participation.  In particular they ask for review and
contributions to the use case definition.  Therefore I am proposing the
following.

Looking at this form how a enterprise would roll-out or implement a
SACM environment, I belive the first use case is a simple way to define or
author a security policy.  This defined policy bridges the organization's
security principles and goals into a policy that form that can be applied to a
system or used to check a system, e.g. XML.  Formally  stated I suggest UC5 as
follows.

3.5 UC5 Define Security Policy

  This use case provides a method for IT security principles and requirements
  to be expressed in a common  descriptive  language such as XML. This common
  descriptive  language will define the  organizations  security  policy. The
  security  policy  definition  will  be  at a  sufficiently  high  level  to
  facilitate  simplicity  and ease of use, It will not  require the author to
  specify the configuration methods and commands to implementation the policy
  on the differing IT devices. However it will be possible for the IT devices
  to bridge this high security policy into actionable configuration settings.
   
Given the above use case, a CIO or CSO can express the security and governance
requirements in a single common secruity policy xml file.  This single file
can be applied to all IT devices such as servers,  clients,  network  devices,
etc.  Given this state, UC1 can be attained,  That is we now have a common
security policy which can be assessment and enforced against.

A single security policy also facilitates UC4 making GRC reporting
common no matter  the  device  being  assessed.  That is high  level  security
policy not only bridges the  organization  security  principles  into a device
configuration  it also provides the inverse for reporting  devices  assessment
back up to the CIO/CSO level.  

My other comment is on  simplicity.  Just like security should be built in and
not bolted on.  Simplicity  should be clearly defined and built in. Complexity
is the enemy of security.  Not only does simplicity  increase adoption it also
eliminates the number of components to be trusted and reduces attack surfaces.

--------- existing Use cases for reference -----------

3.1.  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.


3.2.  UC2: Behavioral Monitoring and Enforcement

  Controlling access to networks and services based on the detection
  and analysis of host and/or user behavior using automatable
  information from various sources.

3.3.  UC3: Security Control Verification and Monitoring

  Continuous assessment of the implementation and effectiveness of
  security controls based on machine processable content.

3.4.  UC4: Secure Exchange of Governance, Risk and Compliance (GRC)
     Information

  Sharing security and/or operationally relevant information within and
  across trust boundaries using secure, automated communication
  channels and formats.


Shawn Mullen                          
Power Software Security  Architect

cell -  (512) 914-8134
11400 Burnet Road internal 9551
Austin, TX 78758-3493
office (512) 286-7683
(T/L: 363-7683)
--=_alternative 003E53BB86257A45_=-- From john.banghart@nist.gov Tue Jul 24 06:11: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 5DBE721F863B for ; Tue, 24 Jul 2012 06:11:02 -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=[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 K0KZBJiPXjAl for ; Tue, 24 Jul 2012 06:11:01 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEEA21F8627 for ; Tue, 24 Jul 2012 06:11:00 -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; Tue, 24 Jul 2012 09:10:42 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 24 Jul 2012 09:10:55 -0400 From: "Banghart, John" To: Shawn Mullen , "Baker, Jon" , "kathleen.moriarty@emc.com" Date: Tue, 24 Jul 2012 09:10:50 -0400 Thread-Topic: [sacm] SCAM Use Case 5 "Define Security Policy" Thread-Index: Ac1pnbEfeIOlEDZFTGuBVBTW+RakBQ== 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_CC3416E8103B4johnbanghartnistgov_" MIME-Version: 1.0 Cc: Stephen Whitlock , "j.hietala@opengroup.org" , "sacm@ietf.org" Subject: Re: [sacm] SCAM Use Case 5 "Define Security Policy" X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 24 Jul 2012 13:11:02 -0000 --_000_CC3416E8103B4johnbanghartnistgov_ Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Shawn, That certainly makes a lot of sense to me. -John From: Shawn Mullen > Date: Tuesday, July 24, 2012 9:00 AM To: "Baker, Jon" >, "kathleen.mor= iarty@emc.com" > Cc: Stephen Whitlock >, "j.hietala@opengroup.org" >, "sacm@ietf.org" > Subject: Re: [sacm] SCAM Use Case 5 "Define Security Policy" Jon, I believe it aligns exactly with the issues faced by industry CIO/CSOs. Ye= s, this is what we tried to address with ACEML. I equally believe the IETF= process is perfectly suited to address this problem and vet the solution. = I also still believe that a blend of SCAP/ACEML/other will be the optimal = and probable solution. As to Kathleen's comment/questions... > From a conversation last week, we may want to have a use case on configur= ation management as well, before we get to enforcement, reporting, and reme= diation. It would be a building > block along with the policy information suggested by Shawn. Any thoughts= ? Yes I believe there is a foundational necessity for SACM to address of expr= essing security and IT governance principles in a policy that can be implem= ented and enforced by technology solutions. I'm currently on tour of Asia = Pacific financial companies and this is a reoccurring theme. Shawn Mullen Power Software Security Architect cell - (512) 914-8134 11400 Burnet Road internal 9551 Austin, TX 78758-3493 office (512) 286-7683 (T/L: 363-7683) From: "Baker, Jon" > To: Shawn Mullen/Austin/IBM@IBMUS, "sacm@ietf.org" > Cc: Stephen Whitlock >, "j.hietala@opengroup.org" > Date: 07/23/2012 08:08 PM Subject: RE: [sacm] SCAM Use Case 5 "Define Security Policy" ________________________________ How does the use case discussion you provided below align with the work the= opengroup has done on ACEML? 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: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Shawn Mullen Sent: Monday, July 23, 2012 9:48 AM To: sacm@ietf.org Cc: Stephen Whitlock; j.hietala@opengroup.org Subject: [sacm] SCAM Use Case 5 "Define Security Policy" During the Washington DC 7/18/12 Open Group Conference Steve Hanna, John Banghart, and Kathleen.Moriarty presented the SACM overview and called for participation. In particular they ask for review and contributions to the use case definition. Therefore I am proposing the following. Looking at this form how a enterprise would roll-out or implement a SACM environment, I belive the first use case is a simple way to define or author a security policy. This defined policy bridges the organization's security principles and goals into a policy that form that can be applied t= o a system or used to check a system, e.g. XML. Formally stated I suggest UC5= as follows. 3.5 UC5 Define Security Policy This use case provides a method for IT security principles and requiremen= ts to be expressed in a common descriptive language such as XML. This comm= on descriptive language will define the organizations security policy. T= he security policy definition will be at a sufficiently high level = to facilitate simplicity and ease of use, It will not require the author = to specify the configuration methods and commands to implementation the poli= cy on the differing IT devices. However it will be possible for the IT devic= es to bridge this high security policy into actionable configuration setting= s. Given the above use case, a CIO or CSO can express the security and governa= nce requirements in a single common secruity policy xml file. This single file can be applied to all IT devices such as servers, clients, network devic= es, etc. Given this state, UC1 can be attained, That is we now have a common security policy which can be assessment and enforced against. A single security policy also facilitates UC4 making GRC reporting common no matter the device being assessed. That is high level secur= ity policy not only bridges the organization security principles into a dev= ice configuration it also provides the inverse for reporting devices assessm= ent back up to the CIO/CSO level. My other comment is on simplicity. Just like security should be built in = and not bolted on. Simplicity should be clearly defined and built in. Complex= ity is the enemy of security. Not only does simplicity increase adoption it a= lso eliminates the number of components to be trusted and reduces attack surfac= es. --------- existing Use cases for reference ----------- 3.1. 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. 3.2. UC2: Behavioral Monitoring and Enforcement Controlling access to networks and services based on the detection and analysis of host and/or user behavior using automatable information from various sources. 3.3. UC3: Security Control Verification and Monitoring Continuous assessment of the implementation and effectiveness of security controls based on machine processable content. 3.4. UC4: Secure Exchange of Governance, Risk and Compliance (GRC) Information Sharing security and/or operationally relevant information within and across trust boundaries using secure, automated communication channels and formats. Shawn Mullen Power Software Security Architect cell - (512) 914-8134 11400 Burnet Road internal 9551 Austin, TX 78758-3493 office (512) 286-7683 (T/L: 363-7683) --_000_CC3416E8103B4johnbanghartnistgov_ Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Shawn,

That certainly makes a lot of sense to me.

-John

From: Shawn Mullen <smullen@us.ibm.c= om>
Date: Tuesday, July = 24, 2012 9:00 AM
To: "Baker, Jo= n" <bakerj@mitre.org>, "kathleen.moriarty@emc.com" <= kathleen.moriarty@emc.com&= gt;
Cc: Stephen Whitlock <s.whitlock@opengroup.org>,= "j.hietala@opengroup.org" &= lt;j.hietala@opengroup.org&g= t;, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] SCAM Use Case 5 "Define Security Policy"
<= /div>

Jon,

I believe it aligns exactly = with the issues faced by industry CIO/CSOs.  Yes, this is what we trie= d to address with ACEML.  I equally believe the IETF process is perfec= tly suited to address this problem and vet the solution.  I also still believe that a blend of SCAP/ACEML/other will be the op= timal and probable solution.

As to Kathleen's comment/questions...
> From a conversation last week, we may w= ant to have a use case on configuration management as well, before we get t= o enforcement, reporting, and remediation.  It would be a building
> block a= long with the policy information suggested by Shawn.  Any thoughts?
  <= br>Yes I believe there is a foundation= al necessity for SACM to address of expressing security and IT governance p= rinciples in a policy that can be implemented and enforced by technology so= lutions.  I'm currently on tour of Asia Pacific financial companies and this is a reoccurring theme.
Shawn Mullen       &n= bsp;                  
Power Software Security  Architect

cell -  (512) 914-8134
11400 Burnet Road internal 9551
Austin, TX 78758-3493
office (512) 286-7683
(T/L: 363-7683)



From:        "Baker, Jon" <b= akerj@mitre.org>
To:        Shawn Mullen/Austin/IBM@IBMUS, "sacm@ietf.org" <sacm@ietf.org= >
C= c:        S= tephen Whitlock <s.whitlock@= opengroup.org>, "j.hietal= a@opengroup.org" <j.hieta= la@opengroup.org>
Date:        07/23/2012 08:08 PM
Subject:        RE: [sacm] SCAM Use Case 5 "Define Securit= y Policy"



How does the use case discussion you provided bel= ow align with the work the opengroup has done on ACEML?
 
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
 
Fro= m: sacm-bounces@ietf.org [= mailto:sacm-bounces@ietf.org] On Behalf Of Shawn Mullen
Sent: Monday, July 23, 2012 9:48 AM
To: sacm@ietf.org
Cc: Stephen Whitlock; j.hiet= ala@opengroup.org
Subject: [sacm] SCAM Use Case 5 "Define Security Policy"
 
During the Washington DC 7/18/12 Open Group Conference Steve = Hanna,
John Banghart, and Kathleen.Moriarty presented the SACM overview and
called for participation.  In particular they ask for review and
contributions to the use case definition.  Therefore I am proposing th= e
following.

Looking at this form how a enterprise would roll-out or implement a
SACM environment, I belive the first use case is a simple way to define or<= /font>
author a security policy.  This defined policy bridges the organizatio= n's
security principles and goals into a policy that form that can be applied t= o a
system or used to check a system, e.g. XML.  Formally  stated I s= uggest UC5 as
follows.

3.5 UC5 Define Security Policy

  This use case provides a method for IT security principles and requi= rements
  to be expressed in a common  descriptive  language such as= XML. This common
  descriptive  language will define the  organizations  = ;security  policy. The
  security  policy  definition  will  be  at = a  sufficiently  high  level  to
  facilitate  simplicity  and ease of use, It will not  = ;require the author to
  specify the configuration methods and commands to implementation the= policy
  on the differing IT devices. However it will be possible for the IT = devices
  to bridge this high security policy into actionable configuration se= ttings.
   
Given the above use case, a CIO or CSO can express the security and governa= nce
requirements in a single common secruity policy xml file.  This single= file
can be applied to all IT devices such as servers,  clients,  netw= ork  devices,<= font size=3D"2" face=3D"Arial">
etc.  Given this state, UC1 can be attained,  That is we now have= a common
security policy which can be assessment and enforced against.

A single security policy also facilitates UC4 making GRC reporting
common no matter  the  device  being  assessed.  T= hat is high  level  security
policy not only bridges the  organization  security  princip= les  into a device
configuration  it also provides the inverse for reporting  device= s  assessment<= font size=3D"2" face=3D"Arial">
back up to the CIO/CSO level.  

My other comment is on  simplicity.  Just like security should be= built in and
not bolted on.  Simplicity  should be clearly defined and built i= n. Complexity
is the enemy of security.  Not only does simplicity  increase ado= ption it also
eliminates the number of components to be trusted and reduces attack surfac= es.

--------- existing Use cases for reference -----------

3.1.  UC1: Assessment and Enforcement of Acceptable State

  Controlling access to networks and services based on the assessment<= /font>
  and analysis of host and/or network state based on machine
  processable content.


3.2.  UC2: Behavioral Monitoring and Enforcement

  Controlling access to networks and services based on the detection
  and analysis of host and/or user behavior using automatable
  information from various sources.

3.3.  UC3: Security Control Verification and Monitoring

  Continuous assessment of the implementation and effectiveness of
  security controls based on machine processable content.

3.4.  UC4: Secure Exchange of Governance, Risk and Compliance (GRC)
     Information

  Sharing security and/or operationally relevant information within an= d
  across trust boundaries using secure, automated communication=
  channels and formats.
Shawn Mullen                  =        
Power Software Security  Architect

cell -  (512) 914-8134
11400 Burnet Road internal 9551
Austin, TX 78758-3493
office (512) 286-7683
(T/L: 363-7683)
--_000_CC3416E8103B4johnbanghartnistgov_-- From david.waltermire@nist.gov Tue Jul 24 09:41: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 9D3DB11E808E for ; Tue, 24 Jul 2012 09:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.282 X-Spam-Level: X-Spam-Status: No, score=-5.282 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ue+kxtXr71FF for ; Tue, 24 Jul 2012 09:41:31 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 5C70A11E8086 for ; Tue, 24 Jul 2012 09:41:30 -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; Tue, 24 Jul 2012 12:41:05 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 24 Jul 2012 12:41:19 -0400 From: "Waltermire, David A." To: "kathleen.moriarty@emc.com" , "smullen@us.ibm.com" , "sacm@ietf.org" Date: Tue, 24 Jul 2012 12:41:17 -0400 Thread-Topic: [sacm] SCAM Use Case 5 "Define Security Policy" Thread-Index: Ac1o2yRXcJvWh3QZRrqAuvTe4CSGgQAAqungADdCy1A= 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_D7A0423E5E193F40BE6E94126930C4930B9FAC9510MBCLUSTERxcha_" MIME-Version: 1.0 Cc: "s.whitlock@opengroup.org" , "j.hietala@opengroup.org" Subject: Re: [sacm] SCAM Use Case 5 "Define Security Policy" X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 24 Jul 2012 16:41:34 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B9FAC9510MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" I am inclined to create subsections under the current use case sections. Within these subsections, we can flesh out the "building blocks" such as what Shawn has provided. Does this sound like a reasonable way to organize the material? Sincerely, Dave From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of kathleen.moriarty@emc.com Sent: Monday, July 23, 2012 10:21 AM To: smullen@us.ibm.com; sacm@ietf.org Cc: s.whitlock@opengroup.org; j.hietala@opengroup.org Subject: Re: [sacm] SCAM Use Case 5 "Define Security Policy" Shawn, Thank you for chiming in! Would you see the proposed UC5 as a new UC1 since policy is a building block? This would just mean we have another Use case to build out the full picture. Your suggestion makes perfect sense. >From a conversation last week, we may want to have a use case on configuration management as well, before we get to enforcement, reporting, and remediation. It would be a building block along with the policy information suggested by Shawn. Any thoughts? Thanks, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Shawn Mullen Sent: Monday, July 23, 2012 9:48 AM To: sacm@ietf.org Cc: Stephen Whitlock; j.hietala@opengroup.org Subject: [sacm] SCAM Use Case 5 "Define Security Policy" During the Washington DC 7/18/12 Open Group Conference Steve Hanna, John Banghart, and Kathleen.Moriarty presented the SACM overview and called for participation. In particular they ask for review and contributions to the use case definition. Therefore I am proposing the following. Looking at this form how a enterprise would roll-out or implement a SACM environment, I belive the first use case is a simple way to define or author a security policy. This defined policy bridges the organization's security principles and goals into a policy that form that can be applied to a system or used to check a system, e.g. XML. Formally stated I suggest UC5 as follows. 3.5 UC5 Define Security Policy This use case provides a method for IT security principles and requirements to be expressed in a common descriptive language such as XML. This common descriptive language will define the organizations security policy. The security policy definition will be at a sufficiently high level to facilitate simplicity and ease of use, It will not require the author to specify the configuration methods and commands to implementation the policy on the differing IT devices. However it will be possible for the IT devices to bridge this high security policy into actionable configuration settings. Given the above use case, a CIO or CSO can express the security and governance requirements in a single common secruity policy xml file. This single file can be applied to all IT devices such as servers, clients, network devices, etc. Given this state, UC1 can be attained, That is we now have a common security policy which can be assessment and enforced against. A single security policy also facilitates UC4 making GRC reporting common no matter the device being assessed. That is high level security policy not only bridges the organization security principles into a device configuration it also provides the inverse for reporting devices assessment back up to the CIO/CSO level. My other comment is on simplicity. Just like security should be built in and not bolted on. Simplicity should be clearly defined and built in. Complexity is the enemy of security. Not only does simplicity increase adoption it also eliminates the number of components to be trusted and reduces attack surfaces. --------- existing Use cases for reference ----------- 3.1. 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. 3.2. UC2: Behavioral Monitoring and Enforcement Controlling access to networks and services based on the detection and analysis of host and/or user behavior using automatable information from various sources. 3.3. UC3: Security Control Verification and Monitoring Continuous assessment of the implementation and effectiveness of security controls based on machine processable content. 3.4. UC4: Secure Exchange of Governance, Risk and Compliance (GRC) Information Sharing security and/or operationally relevant information within and across trust boundaries using secure, automated communication channels and formats. Shawn Mullen Power Software Security Architect cell - (512) 914-8134 11400 Burnet Road internal 9551 Austin, TX 78758-3493 office (512) 286-7683 (T/L: 363-7683) --_000_D7A0423E5E193F40BE6E94126930C4930B9FAC9510MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNv bnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEtLQ0K LyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRp di5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9k eSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlv bjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBhbSBpbmNsaW5l ZCB0byBjcmVhdGUgc3Vic2VjdGlvbnMgdW5kZXIgdGhlIGN1cnJlbnQgdXNlIGNhc2Ugc2VjdGlv bnMuJm5ic3A7IFdpdGhpbiB0aGVzZSBzdWJzZWN0aW9ucywgd2UgY2FuIGZsZXNoIG91dCB0aGUg JiM4MjIwO2J1aWxkaW5nIGJsb2NrcyYjODIyMTsgc3VjaCBhcyB3aGF0IFNoYXduIGhhcyBwcm92 aWRlZC4mbmJzcDsgRG9lcyB0aGlzIHNvdW5kIGxpa2UgYSByZWFzb25hYmxlIHdheSB0byBvcmdh bml6ZSB0aGUgbWF0ZXJpYWw/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNpbmNlcmVseSw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+RGF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2 IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIic+IHNhY20tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNhY20tYm91 bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5rYXRobGVlbi5tb3JpYXJ0eUBlbWMu Y29tPGJyPjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMjMsIDIwMTIgMTA6MjEgQU08YnI+PGI+ VG86PC9iPiBzbXVsbGVuQHVzLmlibS5jb207IHNhY21AaWV0Zi5vcmc8YnI+PGI+Q2M6PC9iPiBz LndoaXRsb2NrQG9wZW5ncm91cC5vcmc7IGouaGlldGFsYUBvcGVuZ3JvdXAub3JnPGJyPjxiPlN1 YmplY3Q6PC9iPiBSZTogW3NhY21dIFNDQU0gVXNlIENhc2UgNSAmcXVvdDtEZWZpbmUgU2VjdXJp dHkgUG9saWN5JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5TaGF3biw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoYW5rIHlvdSBmb3Ig Y2hpbWluZyBpbiEmbmJzcDsgV291bGQgeW91IHNlZSB0aGUgcHJvcG9zZWQgVUM1IGFzIGEgbmV3 IFVDMSBzaW5jZSBwb2xpY3kgaXMgYSBidWlsZGluZyBibG9jaz8mbmJzcDsgVGhpcyB3b3VsZCBq dXN0IG1lYW4gd2UgaGF2ZSBhbm90aGVyIFVzZSBjYXNlIHRvIGJ1aWxkIG91dCB0aGUgZnVsbCBw aWN0dXJlLiZuYnNwOyBZb3VyIHN1Z2dlc3Rpb24gbWFrZXMgcGVyZmVjdCBzZW5zZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPkZyb20gYSBjb252ZXJzYXRpb24gbGFzdCB3ZWVrLCB3ZSBtYXkgd2FudCB0 byBoYXZlIGEgdXNlIGNhc2Ugb24gY29uZmlndXJhdGlvbiBtYW5hZ2VtZW50IGFzIHdlbGwsIGJl Zm9yZSB3ZSBnZXQgdG8gZW5mb3JjZW1lbnQsIHJlcG9ydGluZywgYW5kIHJlbWVkaWF0aW9uLiZu YnNwOyBJdCB3b3VsZCBiZSBhIGJ1aWxkaW5nIGJsb2NrIGFsb25nIHdpdGggdGhlIHBvbGljeSBp bmZvcm1hdGlvbiBzdWdnZXN0ZWQgYnkgU2hhd24uJm5ic3A7IEFueSB0aG91Z2h0cz88bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+S2F0aGxlZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+ PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gPGEgaHJlZj0ibWFpbHRvOnNhY20t Ym91bmNlc0BpZXRmLm9yZyI+c2FjbS1ib3VuY2VzQGlldGYub3JnPC9hPiA8YSBocmVmPSJtYWls dG86W21haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmddIj5bbWFpbHRvOnNhY20tYm91bmNlc0Bp ZXRmLm9yZ108L2E+IDxiPk9uIEJlaGFsZiBPZiA8L2I+U2hhd24gTXVsbGVuPGJyPjxiPlNlbnQ6 PC9iPiBNb25kYXksIEp1bHkgMjMsIDIwMTIgOTo0OCBBTTxicj48Yj5Ubzo8L2I+IDxhIGhyZWY9 Im1haWx0bzpzYWNtQGlldGYub3JnIj5zYWNtQGlldGYub3JnPC9hPjxicj48Yj5DYzo8L2I+IFN0 ZXBoZW4gV2hpdGxvY2s7IDxhIGhyZWY9Im1haWx0bzpqLmhpZXRhbGFAb3Blbmdyb3VwLm9yZyI+ ai5oaWV0YWxhQG9wZW5ncm91cC5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBbc2FjbV0gU0NB TSBVc2UgQ2FzZSA1ICZxdW90O0RlZmluZSBTZWN1cml0eSBQb2xpY3kmcXVvdDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+RHVyaW5nIHRoZSBXYXNoaW5ndG9uIERDIDcvMTgv MTIgT3BlbiBHcm91cCBDb25mZXJlbmNlIFN0ZXZlIEhhbm5hLDwvc3Bhbj4gPGJyPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5K b2huIEJhbmdoYXJ0LCBhbmQgS2F0aGxlZW4uTW9yaWFydHkgcHJlc2VudGVkIHRoZSBTQUNNIG92 ZXJ2aWV3IGFuZCA8L3NwYW4+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5jYWxsZWQgZm9yIHBhcnRpY2lwYXRpb24uICZu YnNwO0luIHBhcnRpY3VsYXIgdGhleSBhc2sgZm9yIHJldmlldyBhbmQgPC9zcGFuPjxicj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+Y29udHJpYnV0aW9ucyB0byB0aGUgdXNlIGNhc2UgZGVmaW5pdGlvbi4gJm5ic3A7VGhlcmVm b3JlIEkgYW0gcHJvcG9zaW5nIHRoZTwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5mb2xsb3dpbmcuPC9zcGFu PiA8YnI+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiJz5Mb29raW5nIGF0IHRoaXMgZm9ybSBob3cgYSBlbnRlcnByaXNlIHdv dWxkIHJvbGwtb3V0IG9yIGltcGxlbWVudCBhIDwvc3Bhbj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPlNBQ00gZW52aXJv bm1lbnQsIEkgYmVsaXZlIHRoZSBmaXJzdCB1c2UgY2FzZSBpcyBhIHNpbXBsZSB3YXkgdG8gZGVm aW5lIG9yPC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPmF1dGhvciBhIHNlY3VyaXR5IHBvbGljeS4gJm5ic3A7 VGhpcyBkZWZpbmVkIHBvbGljeSBicmlkZ2VzIHRoZSBvcmdhbml6YXRpb24nczwvc3Bhbj4gPGJy PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiJz5zZWN1cml0eSBwcmluY2lwbGVzIGFuZCBnb2FscyBpbnRvIGEgcG9saWN5IHRoYXQg Zm9ybSB0aGF0IGNhbiBiZSBhcHBsaWVkIHRvIGE8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+c3lzdGVtIG9y IHVzZWQgdG8gY2hlY2sgYSBzeXN0ZW0sIGUuZy4gWE1MLiAmbmJzcDtGb3JtYWxseSAmbmJzcDtz dGF0ZWQgSSBzdWdnZXN0IFVDNSBhczwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5mb2xsb3dzLjwvc3Bhbj4g PGJyPjxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+My41IFVDNSBEZWZpbmUgU2VjdXJpdHkgUG9saWN5PC9zcGFuPiA8YnI+ PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7VGhpcyB1c2UgY2FzZSBwcm92aWRlcyBhIG1ldGhvZCBm b3IgSVQgc2VjdXJpdHkgcHJpbmNpcGxlcyBhbmQgcmVxdWlyZW1lbnRzPC9zcGFuPiA8YnI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiInPiZuYnNwOyAmbmJzcDt0byBiZSBleHByZXNzZWQgaW4gYSBjb21tb24gJm5ic3A7ZGVzY3Jp cHRpdmUgJm5ic3A7bGFuZ3VhZ2Ugc3VjaCBhcyBYTUwuIFRoaXMgY29tbW9uPC9zcGFuPiA8YnI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiInPiZuYnNwOyAmbmJzcDtkZXNjcmlwdGl2ZSAmbmJzcDtsYW5ndWFnZSB3aWxsIGRlZmlu ZSB0aGUgJm5ic3A7b3JnYW5pemF0aW9ucyAmbmJzcDtzZWN1cml0eSAmbmJzcDtwb2xpY3kuIFRo ZTwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7c2VjdXJpdHkgJm5ic3A7cG9saWN5ICZu YnNwO2RlZmluaXRpb24gJm5ic3A7d2lsbCAmbmJzcDtiZSAmbmJzcDthdCBhICZuYnNwO3N1ZmZp Y2llbnRseSAmbmJzcDtoaWdoICZuYnNwO2xldmVsICZuYnNwO3RvPC9zcGFuPiA8YnI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiIn PiZuYnNwOyAmbmJzcDtmYWNpbGl0YXRlICZuYnNwO3NpbXBsaWNpdHkgJm5ic3A7YW5kIGVhc2Ug b2YgdXNlLCBJdCB3aWxsIG5vdCAmbmJzcDtyZXF1aXJlIHRoZSBhdXRob3IgdG88L3NwYW4+IDxi cj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIic+Jm5ic3A7ICZuYnNwO3NwZWNpZnkgdGhlIGNvbmZpZ3VyYXRpb24gbWV0aG9kcyBh bmQgY29tbWFuZHMgdG8gaW1wbGVtZW50YXRpb24gdGhlIHBvbGljeTwvc3Bhbj4gPGJyPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi Jz4mbmJzcDsgJm5ic3A7b24gdGhlIGRpZmZlcmluZyBJVCBkZXZpY2VzLiBIb3dldmVyIGl0IHdp bGwgYmUgcG9zc2libGUgZm9yIHRoZSBJVCBkZXZpY2VzPC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZuYnNw OyAmbmJzcDt0byBicmlkZ2UgdGhpcyBoaWdoIHNlY3VyaXR5IHBvbGljeSBpbnRvIGFjdGlvbmFi bGUgY29uZmlndXJhdGlvbiBzZXR0aW5ncy48L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNw OyA8L3NwYW4+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiJz5HaXZlbiB0aGUgYWJvdmUgdXNlIGNhc2UsIGEgQ0lPIG9yIENT TyBjYW4gZXhwcmVzcyB0aGUgc2VjdXJpdHkgYW5kIGdvdmVybmFuY2U8L3NwYW4+IDxicj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+cmVxdWlyZW1lbnRzIGluIGEgc2luZ2xlIGNvbW1vbiBzZWNydWl0eSBwb2xpY3kgeG1sIGZp bGUuICZuYnNwO1RoaXMgc2luZ2xlIGZpbGUgPC9zcGFuPjxicj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Y2FuIGJlIGFwcGxp ZWQgdG8gYWxsIElUIGRldmljZXMgc3VjaCBhcyBzZXJ2ZXJzLCAmbmJzcDtjbGllbnRzLCAmbmJz cDtuZXR3b3JrICZuYnNwO2RldmljZXMsPC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPmV0Yy4gJm5ic3A7R2l2 ZW4gdGhpcyBzdGF0ZSwgVUMxIGNhbiBiZSBhdHRhaW5lZCwgJm5ic3A7VGhhdCBpcyB3ZSBub3cg aGF2ZSBhIGNvbW1vbjwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5zZWN1cml0eSBwb2xpY3kgd2hpY2ggY2Fu IGJlIGFzc2Vzc21lbnQgYW5kIGVuZm9yY2VkIGFnYWluc3QuIDwvc3Bhbj48YnI+PGJyPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi Jz5BIHNpbmdsZSBzZWN1cml0eSBwb2xpY3kgYWxzbyBmYWNpbGl0YXRlcyBVQzQgbWFraW5nIEdS QyByZXBvcnRpbmcgPC9zcGFuPjxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Y29tbW9uIG5vIG1hdHRlciAmbmJzcDt0aGUg Jm5ic3A7ZGV2aWNlICZuYnNwO2JlaW5nICZuYnNwO2Fzc2Vzc2VkLiAmbmJzcDtUaGF0IGlzIGhp Z2ggJm5ic3A7bGV2ZWwgJm5ic3A7c2VjdXJpdHk8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+cG9saWN5IG5v dCBvbmx5IGJyaWRnZXMgdGhlICZuYnNwO29yZ2FuaXphdGlvbiAmbmJzcDtzZWN1cml0eSAmbmJz cDtwcmluY2lwbGVzICZuYnNwO2ludG8gYSBkZXZpY2U8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Y29uZmln dXJhdGlvbiAmbmJzcDtpdCBhbHNvIHByb3ZpZGVzIHRoZSBpbnZlcnNlIGZvciByZXBvcnRpbmcg Jm5ic3A7ZGV2aWNlcyAmbmJzcDthc3Nlc3NtZW50PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPmJhY2sgdXAg dG8gdGhlIENJTy9DU08gbGV2ZWwuICZuYnNwOzwvc3Bhbj4gPGJyPjxicj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+TXkgb3Ro ZXIgY29tbWVudCBpcyBvbiAmbmJzcDtzaW1wbGljaXR5LiAmbmJzcDtKdXN0IGxpa2Ugc2VjdXJp dHkgc2hvdWxkIGJlIGJ1aWx0IGluIGFuZDwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5ub3QgYm9sdGVkIG9u LiAmbmJzcDtTaW1wbGljaXR5ICZuYnNwO3Nob3VsZCBiZSBjbGVhcmx5IGRlZmluZWQgYW5kIGJ1 aWx0IGluLiBDb21wbGV4aXR5PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPmlzIHRoZSBlbmVteSBvZiBzZWN1 cml0eS4gJm5ic3A7Tm90IG9ubHkgZG9lcyBzaW1wbGljaXR5ICZuYnNwO2luY3JlYXNlIGFkb3B0 aW9uIGl0IGFsc288L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+ZWxpbWluYXRlcyB0aGUgbnVtYmVyIG9mIGNv bXBvbmVudHMgdG8gYmUgdHJ1c3RlZCBhbmQgcmVkdWNlcyBhdHRhY2sgc3VyZmFjZXMuPC9zcGFu PiA8YnI+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiJz4tLS0tLS0tLS0gZXhpc3RpbmcgVXNlIGNhc2VzIGZvciByZWZlcmVu Y2UgLS0tLS0tLS0tLS08L3NwYW4+IDxicj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjMuMS4gJm5ic3A7VUMxOiBBc3Nl c3NtZW50IGFuZCBFbmZvcmNlbWVudCBvZiBBY2NlcHRhYmxlIFN0YXRlPC9zcGFuPiA8YnI+PGJy PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiJz4mbmJzcDsgJm5ic3A7Q29udHJvbGxpbmcgYWNjZXNzIHRvIG5ldHdvcmtzIGFuZCBz ZXJ2aWNlcyBiYXNlZCBvbiB0aGUgYXNzZXNzbWVudDwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDsg Jm5ic3A7YW5kIGFuYWx5c2lzIG9mIGhvc3QgYW5kL29yIG5ldHdvcmsgc3RhdGUgYmFzZWQgb24g bWFjaGluZTwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7cHJvY2Vzc2FibGUgY29udGVu dC48L3NwYW4+IDxicj48YnI+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4zLjIuICZuYnNwO1VDMjogQmVoYXZpb3JhbCBN b25pdG9yaW5nIGFuZCBFbmZvcmNlbWVudDwvc3Bhbj4gPGJyPjxicj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZu YnNwO0NvbnRyb2xsaW5nIGFjY2VzcyB0byBuZXR3b3JrcyBhbmQgc2VydmljZXMgYmFzZWQgb24g dGhlIGRldGVjdGlvbjwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7YW5kIGFuYWx5c2lz IG9mIGhvc3QgYW5kL29yIHVzZXIgYmVoYXZpb3IgdXNpbmcgYXV0b21hdGFibGU8L3NwYW4+IDxi cj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIic+Jm5ic3A7ICZuYnNwO2luZm9ybWF0aW9uIGZyb20gdmFyaW91cyBzb3VyY2VzLjwv c3Bhbj4gPGJyPjxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIic+My4zLiAmbmJzcDtVQzM6IFNlY3VyaXR5IENvbnRyb2wgVmVy aWZpY2F0aW9uIGFuZCBNb25pdG9yaW5nPC9zcGFuPiA8YnI+PGJyPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5i c3A7Q29udGludW91cyBhc3Nlc3NtZW50IG9mIHRoZSBpbXBsZW1lbnRhdGlvbiBhbmQgZWZmZWN0 aXZlbmVzcyBvZjwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7c2VjdXJpdHkgY29udHJv bHMgYmFzZWQgb24gbWFjaGluZSBwcm9jZXNzYWJsZSBjb250ZW50Ljwvc3Bhbj4gPGJyPjxicj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIic+My40LiAmbmJzcDtVQzQ6IFNlY3VyZSBFeGNoYW5nZSBvZiBHb3Zlcm5hbmNlLCBSaXNr IGFuZCBDb21wbGlhbmNlIChHUkMpPC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZuYnNwOyAmbmJzcDsgJm5i c3A7IEluZm9ybWF0aW9uPC9zcGFuPiA8YnI+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7U2hhcmlu ZyBzZWN1cml0eSBhbmQvb3Igb3BlcmF0aW9uYWxseSByZWxldmFudCBpbmZvcm1hdGlvbiB3aXRo aW4gYW5kPC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZuYnNwOyAmbmJzcDthY3Jvc3MgdHJ1c3QgYm91bmRh cmllcyB1c2luZyBzZWN1cmUsIGF1dG9tYXRlZCBjb21tdW5pY2F0aW9uPC9zcGFuPiA8YnI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiInPiZuYnNwOyAmbmJzcDtjaGFubmVscyBhbmQgZm9ybWF0cy48L3NwYW4+IDxicj48YnI+PGJy PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiJz5TaGF3biBNdWxsZW4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxi cj5Qb3dlciBTb2Z0d2FyZSBTZWN1cml0eSAmbmJzcDtBcmNoaXRlY3Q8YnI+PGJyPmNlbGwgLSAm bmJzcDsoNTEyKSA5MTQtODEzNDxicj4xMTQwMCBCdXJuZXQgUm9hZCBpbnRlcm5hbCA5NTUxIDxi cj5BdXN0aW4sIFRYIDc4NzU4LTM0OTM8YnI+b2ZmaWNlICg1MTIpIDI4Ni03NjgzPGJyPihUL0w6 IDM2My03NjgzKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_D7A0423E5E193F40BE6E94126930C4930B9FAC9510MBCLUSTERxcha_-- From bakerj@mitre.org Mon Jul 30 11:55: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 3FA8521F851B for ; Mon, 30 Jul 2012 11:55:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhdOiJosKlDb for ; Mon, 30 Jul 2012 11:55:48 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 54B1721F850C for ; Mon, 30 Jul 2012 11:55:48 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EBC6121B0FD5 for ; Mon, 30 Jul 2012 14:55:47 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DC75121B0FB1 for ; Mon, 30 Jul 2012 14:55:47 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.146]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.02.0309.002; Mon, 30 Jul 2012 14:55:47 -0400 From: "Baker, Jon" To: "sacm@ietf.org" Thread-Topic: remote participation in IETF 84 side meeting? Thread-Index: Ac1uhO62z3tXMTwpSjmL3ZiqiZIrIg== Date: Mon, 30 Jul 2012 18:55:47 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D38651301FAE622@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: multipart/alternative; boundary="_000_6C1C15D8B5510B4B8FF132B10D38651301FAE622IMCMBX03MITREOR_" MIME-Version: 1.0 Subject: [sacm] remote participation in 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: Mon, 30 Jul 2012 18:55:49 -0000 --_000_6C1C15D8B5510B4B8FF132B10D38651301FAE622IMCMBX03MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Will remote participation be possible in the SACM side meeting later this w= eek? 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 --_000_6C1C15D8B5510B4B8FF132B10D38651301FAE622IMCMBX03MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Will remote participation be possible in the SACM si= de meeting later this week?

 

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

 

--_000_6C1C15D8B5510B4B8FF132B10D38651301FAE622IMCMBX03MITREOR_-- From david.waltermire@nist.gov Mon Jul 30 12:31: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 0375C11E81BE for ; Mon, 30 Jul 2012 12:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.971 X-Spam-Level: X-Spam-Status: No, score=-5.971 tagged_above=-999 required=5 tests=[AWL=0.127, 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 lLiU56ENgdek for ; Mon, 30 Jul 2012 12:31:22 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 2E60E11E808D for ; Mon, 30 Jul 2012 12:31:22 -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; Mon, 30 Jul 2012 15:31:11 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 30 Jul 2012 15:31:13 -0400 From: "Waltermire, David A." To: "'bakerj@mitre.org'" , "'sacm@ietf.org'" Date: Mon, 30 Jul 2012 15:30:22 -0400 Thread-Topic: [sacm] remote participation in IETF 84 side meeting? Thread-Index: Ac1uhO62z3tXMTwpSjmL3ZiqiZIrIgABNSqo Message-ID: In-Reply-To: <6C1C15D8B5510B4B8FF132B10D38651301FAE622@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E4AMBCLUSTERxcha_" MIME-Version: 1.0 Subject: Re: [sacm] remote participation in 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: Mon, 30 Jul 2012 19:31:23 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E4AMBCLUSTERxcha_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSB3b3JraW5nIG9uIE1lZXRlY2hvIHN1cHBvcnQgYW5kIGhvcGUgdG8gcHJvdmlkZSB0aGUg ZGV0YWlscyBBU0FQIGZvciBUaHVyc2RheS4NCg0KVGhhbmtzLA0KRGF2ZQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogc2FjbS1ib3VuY2VzQGlldGYub3JnIDxzYWNt LWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogc2FjbUBpZXRmLm9yZyA8c2FjbUBpZXRmLm9yZz4NClNl bnQ6IE1vbiBKdWwgMzAgMTQ6NTU6NDcgMjAxMg0KU3ViamVjdDogW3NhY21dIHJlbW90ZSBwYXJ0 aWNpcGF0aW9uIGluIElFVEYgODQgc2lkZSBtZWV0aW5nPw0KDQpXaWxsIHJlbW90ZSBwYXJ0aWNp cGF0aW9uIGJlIHBvc3NpYmxlIGluIHRoZSBTQUNNIHNpZGUgbWVldGluZyBsYXRlciB0aGlzIHdl ZWs/DQoNCkpvbg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KSm9uYXRoYW4gTy4gQmFrZXINCkcwMjIgLSBJQSBJbmR1c3RyeSBDb2xsYWJvcmF0aW9uDQpU aGUgTUlUUkUgQ29ycG9yYXRpb24NCkVtYWlsOiBiYWtlcmpAbWl0cmUub3JnPG1haWx0bzpiYWtl cmpAbWl0cmUub3JnPg0KDQo= --_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E4AMBCLUSTERxcha_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxtZXRhIG5hbWU9IkdlbmVy YXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPjxk aXY+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD4NCkkgYW0gd29ya2luZyBvbiBN ZWV0ZWNobyBzdXBwb3J0IGFuZCBob3BlIHRvIHByb3ZpZGUgdGhlIGRldGFpbHMgQVNBUCBmb3Ig VGh1cnNkYXkuPGJyPjxicj5UaGFua3MsPGJyPkRhdmU8L2ZvbnQ+PC9kaXY+DQo8YnI+PGRpdj48 aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXIgdGFiaW5kZXg9LTE+DQo8Zm9udCBm YWNlPVRhaG9tYSBzaXplPTI+DQo8Yj5Gcm9tPC9iPjogc2FjbS1ib3VuY2VzQGlldGYub3JnICZs dDtzYWNtLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DTxicj48Yj5UbzwvYj46IHNhY21AaWV0Zi5vcmcg Jmx0O3NhY21AaWV0Zi5vcmcmZ3Q7DTxicj48Yj5TZW50PC9iPjogTW9uIEp1bCAzMCAxNDo1NTo0 NyAyMDEyPGJyPjxiPlN1YmplY3Q8L2I+OiBbc2FjbV0gcmVtb3RlIHBhcnRpY2lwYXRpb24gaW4g SUVURiA4NCBzaWRlIG1lZXRpbmc/DTxicj48L2ZvbnQ+PGJyPjwvZGl2Pg0KDQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2lsbCByZW1vdGUgcGFydGlj aXBhdGlvbiBiZSBwb3NzaWJsZSBpbiB0aGUgU0FDTSBzaWRlIG1lZXRpbmcgbGF0ZXIgdGhpcyB3 ZWVrPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvbmF0aGFuIE8uIEJha2VyPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HMDIyIC0gSUEgSW5kdXN0cnkgQ29sbGFib3JhdGlvbjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIE1JVFJFIENvcnBvcmF0aW9u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FbWFpbDogPGEgaHJlZj0ibWFp bHRvOmJha2VyakBtaXRyZS5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj5iYWtlcmpAbWl0 cmUub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E4AMBCLUSTERxcha_-- From david.waltermire@nist.gov Mon Jul 30 18:16: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 0058721F85A5 for ; Mon, 30 Jul 2012 18:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.23 X-Spam-Level: X-Spam-Status: No, score=-7.23 tagged_above=-999 required=5 tests=[AWL=1.369, 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 SKLvf3Jv+lfH for ; Mon, 30 Jul 2012 18:16:36 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id B880221F853E for ; Mon, 30 Jul 2012 18:16:35 -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; Mon, 30 Jul 2012 21:16:31 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 30 Jul 2012 21:16:34 -0400 From: "Waltermire, David A." To: "sacm@ietf.org" Date: Mon, 30 Jul 2012 21:15:42 -0400 Thread-Topic: Agenda and Remote Participation Info for the SACM BOF Thread-Index: AQHNbroA4NqnQfgRGEqDiS9aUR2yUA== 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: [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: Tue, 31 Jul 2012 01:16:37 -0000 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:=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 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 Kent_Landfield@mcafee.com Tue Jul 31 15:12: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 AE91C11E80D9 for ; Tue, 31 Jul 2012 15:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 BHAP66U3m2Tv for ; Tue, 31 Jul 2012 15:12:19 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 47D2E21F8867 for ; Tue, 31 Jul 2012 15:12:19 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 055f_56aa_48417a47_81ef_4bc9_bf82_1f37312b502f; Tue, 31 Jul 2012 17:12:18 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::b534:4a0d:1289:2d2d]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Tue, 31 Jul 2012 17:11:18 -0500 From: To: Date: Tue, 31 Jul 2012 17:12:16 -0500 Thread-Topic: Proposed SACM Charter Thread-Index: Ac1vaWiOyVMyhOX0SPq1pV9F173E/A== 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 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC3DA650389E2kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: [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: Tue, 31 Jul 2012 22:12:20 -0000 --_000_CC3DA650389E2kentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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_CC3DA650389E2kentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi al= l,

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

------= --

Security Automation Continuous Monitoring (SACM)

 

Propos= ed Working Group Charter

&= nbsp;

Chairs= :

TBD

TBD

&= nbsp;

Securi= ty Area Directors:

 =     Stephen Farrell <>

 =     Sean Turner <turners@ie= ca.com>=

&= nbsp;

Securi= ty Area Advisor:

 =     Sean Turner <turners@ie= ca.com>=

&= nbsp;

Mailin= g Lists:

 =     General Discussion: sacm= @ietf.org<= /o:p>

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

 =     Archive:         http://w= ww.ietf.org/mail-archive/web/sacm

&= nbsp;

Des= cription of Working Group

&= nbsp;

Securi= ng 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 enable security automation standards= in support of information security processes and practices where practica= l, such that security practitioners can be better utilized within their organizations and we can meet the more advanced needs of the security community (e.g. information sharing, continuous monitoring, 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.

&= nbsp;

The in= itial work has been fruitful, 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 gr= oup are the emerging security automation specifications relating to event management and continuous monitoring.

&= nbsp;

By und= ertaking this work, we recognize that there are multiple categories of problems in the security automation domain: def= ining expressions for particular domain concepts (i.e. specifications), cura= ting domain concept instance collections in content repositories (i.e. operations)= , and enabling interoperability through the development and use of interfaces= and communications protocols. 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 their users) can rely and support the automated exchange of vulnerability and configuration information.

&= nbsp;

This w= orking group will provide solutions to these categories of problems and the main areas of focus for this working gr= oup are described as follows:

&= nbsp;

1.&nbs= p;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. =

&= nbsp;

2. Define, either by normative reference, adoption, or creation, a set of standards that can be used = to continuously monitor and report on systems=92 state and security proce= ss 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.

&= nbsp;

This w= orking group will produce the following:

&= nbsp;

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

* A Standards Track doc= ument specifying benchmark configuration representation 

* An Infor= mational document stating guidelines / requirements for specifying checking languages

* Standards Track docum= ents specifying device state checking languages

* A Standards Track doc= ument specifying an interrogative checking language 

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

* A Standards Track doc= ument specifying asset identification and reporting information

* A Standards Track doc= ument specifying interfaces and communication protocols used for security automation and continuous monitoring 

* A Standards Track doc= ument describing the messages and network protocols for distributing Security Automation Con= tent 

* A Standards Track doc= ument describing integrating security automation and Network Endpoint Assessment capabilitie= s

* A Standards Track doc= ument describing protocols and data formats 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.709= 6 Mobile: &= #43;1.817.637.8026
www.mcafee.com
--_000_CC3DA650389E2kentlandfieldmcafeecom_--