From nobody Wed Dec 2 05:36:21 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480BB1A8AEC; Wed, 2 Dec 2015 05:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmIcMULuv_Kv; Wed, 2 Dec 2015 05:36:16 -0800 (PST) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id 011B31A8AED; Wed, 2 Dec 2015 05:36:16 -0800 (PST) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AA7896C03A6; Wed, 2 Dec 2015 08:36:15 -0500 (EST) Received: from imshyb01.MITRE.ORG (imshyb01.mitre.org [129.83.29.2]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 941F46C006F; Wed, 2 Dec 2015 08:36:15 -0500 (EST) Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 2 Dec 2015 08:36:15 -0500 Received: from na01-bn1-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1130.7 via Frontend Transport; Wed, 2 Dec 2015 08:36:15 -0500 Received: from BLUPR09MB104.namprd09.prod.outlook.com (10.255.212.24) by BLUPR09MB102.namprd09.prod.outlook.com (10.255.212.141) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 2 Dec 2015 13:36:13 +0000 Received: from BLUPR09MB104.namprd09.prod.outlook.com ([10.255.212.24]) by BLUPR09MB104.namprd09.prod.outlook.com ([10.255.212.24]) with mapi id 15.01.0331.023; Wed, 2 Dec 2015 13:36:13 +0000 From: "Haynes, Dan" To: "Romascanu, Dan (Dan)" , Linda Dunbar , "opsec@ietf.org" , "opsawg@ietf.org" Thread-Topic: [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario Thread-Index: AQHRJTTczVSGd0+Bu0KNrmLDTqBEuZ63wXFw Date: Wed, 2 Dec 2015 13:36:13 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA6BE9F6C7@AZ-FFEXMB04.global.avaya.com> <4A95BA014132FF49AE685FAB4B9F17F657DA3D4B@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA6BEA384A@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BEA384A@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dhaynes@mitre.org; x-originating-ip: [192.160.51.88] x-microsoft-exchange-diagnostics: 1; BLUPR09MB102; 5:KZJVaL9EG1N/hdEcrrBxeIIbpmpQQ4LoSbjIELS1xIHuhrVsJBYq0v5FHf6BjTXP7oqglCFG5N9xF9ec/IL2YdgoXU3NX1nf0196OCprqqxrlL88KvvEwO4S33LmIXDi5EbKTC7gfAV3AAPFKtBVVA==; 24:/IyyFslBNmxhi3skZeGkd7TpMXW3VLww0PnzwLEFu1zjibWGs4EQNXxKSS8t3kqYesUyy0ymlm49/lq+awGPwt0g5KN8X/suCwq7QsKjxfc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR09MB102; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BLUPR09MB102; BCL:0; PCL:0; RULEID:; SRVR:BLUPR09MB102; x-forefront-prvs: 077884B8B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(164054003)(199003)(377454003)(52604005)(189002)(101416001)(54356999)(40100003)(19617315012)(19300405004)(5004730100002)(97736004)(105586002)(19625215002)(189998001)(74316001)(19580405001)(5002640100001)(1096002)(76576001)(16236675004)(33656002)(2501003)(106116001)(1220700001)(10400500002)(66066001)(92566002)(11100500001)(5001960100002)(76176999)(5001770100001)(790700001)(102836003)(106356001)(6116002)(99286002)(86362001)(586003)(19580395003)(5008740100001)(81156007)(2950100001)(3846002)(19609705001)(77096005)(87936001)(2900100001)(50986999)(15975445007)(5003600100002)(2201001)(122556002)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB102; H:BLUPR09MB104.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR09MB1042C7D6839BAC9A2512005A50E0BLUPR09MB104namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2015 13:36:13.7370 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR09MB102 X-OriginatorOrg: mitre.org Archived-At: Cc: "sacm@ietf.org" Subject: Re: [OPSEC] [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 13:36:19 -0000 --_000_BLUPR09MB1042C7D6839BAC9A2512005A50E0BLUPR09MB104namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Linda, Please let us know if there are any specific questions that we can answer f= or you, to help clarify the document, after considering it in the context o= f the SACM charter as Dan mentioned. Thanks, Danny From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Romascanu, Dan (Da= n) Sent: Sunday, November 22, 2015 9:48 AM To: Linda Dunbar ; opsec@ietf.org; opsawg@ietf.org Cc: sacm@ietf.org Subject: Re: [OPSEC] [sacm] [OPSAWG] Feedback on the SACM Vulnerability Ass= essment Scenario Hi Linda, Thanks for answering the call for review and having a look at this work. Concerning your 'little disappointment': This I-D needs to be read in the c= ontext of the current charter of the SACM WG. The WG charter focus for this= phase is on the 'endpoint posture' and on the 'enterprise use case'. Maybe= this makes things somehow more clear. Regards, Dan From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, November 19, 2015 10:36 PM To: Romascanu, Dan (Dan); opsec@ietf.org; opsawg@iet= f.org Cc: sacm@ietf.org Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment = Scenario Reading through the document has made me feel that the Title of the draft i= s misleading. Based on the title I was expecting to see the Vulnerability Assessment of v= arious network scenarios, which will be very useful information for enterpr= ise and service provider network administrators to put in adequate tools to= protect those vulnerability. But the document only describes the procedure in authenticating a end user/= points and states that you need to compare with the Vulnerability report (a= lmost like a common sense ) without saying how and what. I guess I had too= high the expectation, but a little disappointed of not finding the informa= tion I was looking for. Linda Dunbar From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (= Dan) Sent: Thursday, November 19, 2015 7:51 AM To: opsec@ietf.org; opsawg@ietf.org Cc: sacm@ietf.org Subject: [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario Hi, I am reiterating a request that I made at IETF 94 in the OPSAWG meeting, an= d also sent to the mail lists of opsec and opsawg. The SACM WG is consideri= ng a document https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scena= rio/ that describes the operational practice of vulnerability repo= rts, which we believe is an important use case in the security assessment l= ife cycle. We are requiring feedback from operators about the scenario desc= ribe in this document - does it make sense? Is it similar with what you do = in operational real life? Are you using similar or different methods for vu= lnerability assessment in your networks? A quick reading and short feedback= would be greatly appreciated. Thanks and Regards, Dan --_000_BLUPR09MB1042C7D6839BAC9A2512005A50E0BLUPR09MB104namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Linda,


Please let us know if there are any specific questions that we can answer f= or you, to help clarify the document, after considering it in the context o= f the SACM charter as Dan mentioned.

 

Thanks,

Danny

 

From: OPSEC [mailto:opsec-bounces@ietf.org] <= b>On Behalf Of Romascanu, Dan (Dan)
Sent: Sunday, November 22, 2015 9:48 AM
To: Linda Dunbar <linda.dunbar@huawei.com>; opsec@ietf.org; op= sawg@ietf.org
Cc: sacm@ietf.org
Subject: Re: [OPSEC] [sacm] [OPSAWG] Feedback on the SACM Vulnerabil= ity Assessment Scenario

 

Hi Linda, <= /span>

 

Thanks for answering t= he call for review and having a look at this work.

 

Concerning your ‘= ;little disappointment’: This I-D needs to be read in the context of = the current charter of the SACM WG. The WG charter focus for this phase is = on the ‘endpoint posture’ and on the ‘enterprise use case’. Maybe this makes things somehow more clear.

 

Regards,

 

Dan<= /p>

 

 

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, November 19, 2015 10:36 PM
To: Romascanu, Dan (Dan); opsec@ie= tf.org; opsawg@ietf.org
Cc: sacm@ietf.org
Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability Asse= ssment Scenario

 

Reading through the do= cument has made me feel that the Title of the draft is misleading.

Based on the title I w= as expecting to see the Vulnerability Assessment of various network scenari= os, which will be very useful information for enterprise and service provid= er network administrators to put in adequate tools to protect those vulnerability.

 

But the document only = describes the procedure in authenticating a end user/points and states that= you need to compare with the Vulnerability report (almost like a common se= nse ) without saying how and what.  I guess I had too high the expectation, but a little disappointed of not fin= ding the information I was looking for.

 

Linda Dunbar

 

 

 

From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, November 19, 2015 7:51 AM
To: opsec@ietf.org; opsawg@ietf.org
Cc: sacm@ietf.org
Subject: [OPSAWG] Feedback on the SACM Vulnerability Assessment Scen= ario

 

Hi,

 

I am reiterating a request that I made at IETF 94 in= the OPSAWG meeting, and also sent to the mail lists of opsec and opsawg. T= he SACM WG is considering a document https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/ that = describes the operational practice of vulnerability reports, which we belie= ve is an important use case in the security assessment life cycle. We are r= equiring feedback from operators about the scenario describe in this document – does it make sense? I= s it similar with what you do in operational real life? Are you using simil= ar or different methods for vulnerability assessment in your networks? A qu= ick reading and short feedback would be greatly appreciated.

 

Thanks and Regards,

 

Dan

 

--_000_BLUPR09MB1042C7D6839BAC9A2512005A50E0BLUPR09MB104namprd_-- From nobody Wed Dec 2 06:16:20 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F1A1A8FD3; Wed, 2 Dec 2015 05:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkaCYjlkkt7X; Wed, 2 Dec 2015 05:53:32 -0800 (PST) Received: from UCOL19PA11.eemsg.mail.mil (ucol19pa11.eemsg.mail.mil [214.24.24.84]) by ietfa.amsl.com (Postfix) with ESMTP id B8B411A9004; Wed, 2 Dec 2015 05:53:31 -0800 (PST) X-EEMSG-Attachment-filename: smime.p7s X-IronPort-AV: E=Sophos;i="5.20,373,1444694400"; d="p7s'?scan'208";a="62195565" Received: from edge-mech01.mail.mil ([214.21.130.103]) by UCOL19PA11.eemsg.mail.mil with ESMTP; 02 Dec 2015 13:53:31 +0000 Received: from UMECHPAOL.easf.csd.disa.mil (214.21.130.39) by edge-mech01.mail.mil (214.21.130.103) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 2 Dec 2015 13:53:05 +0000 Received: from UMECHPAO0.easf.csd.disa.mil ([169.254.4.97]) by umechpaol.easf.csd.disa.mil ([214.21.130.39]) with mapi id 14.03.0266.001; Wed, 2 Dec 2015 13:53:05 +0000 From: "Wolfkiel, Joseph L CIV DISA ID (US)" To: "Haynes, Dan" , "Romascanu, Dan (Dan)" , Linda Dunbar , "opsec@ietf.org" , "opsawg@ietf.org" Thread-Topic: [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario Thread-Index: AdEtB9R3BRnyl7YDSxiobivBcy4MHw== Date: Wed, 2 Dec 2015 13:53:04 +0000 Message-ID: <9F61CC8E6ED7BC4DBA90C13F25D29C006325E379@umechpao0.easf.csd.disa.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [214.21.44.12] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0026_01D12CDE.DA1FBD10" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 02 Dec 2015 06:16:18 -0800 Cc: "sacm@ietf.org" Subject: Re: [OPSEC] [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 13:53:36 -0000 ------=_NextPart_000_0026_01D12CDE.DA1FBD10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think the disappointment may have been headed off if the document was more explicit, right at the beginning, about what a "vulnerability report" is. I got 2/3 of the way through the document before I understood that "vulnerability report" and "vulnerability definition" are effectively the same construct. A vulnerability report apparently is an announcement that a vulnerability has been discovered and defined to the point where endpoint managers can run assessments on their endpoints to determine if their endpoints have the vulnerability or not. This concept is confusing because generally, with existing vulnerability scanners, new vulnerability "reports" are a subset of updated vulnerability definitions that automatically propagated to the tools and aren't delivered as stand-alone "reports". So a vulnerability "report" would look something like the report at https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-8395 (I think). Joseph L. Wolfkiel SCM Engineering Lead DISA ID52 Fort Meade DISA Acquisiton Bldg Cube A4A58E Work: (301) 225-8820 Gov Cell: (571) 814-8231 Joseph.L.Wolfkiel.civ@mail.mil -----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Haynes, Dan Sent: Wednesday, December 02, 2015 8:36 AM To: Romascanu, Dan (Dan); Linda Dunbar; opsec@ietf.org; opsawg@ietf.org Cc: sacm@ietf.org Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario Hi Linda, Please let us know if there are any specific questions that we can answer for you, to help clarify the document, after considering it in the context of the SACM charter as Dan mentioned. Thanks, Danny From: OPSEC [Caution-mailto:opsec-bounces@ietf.org] On Behalf OfRomascanu, Dan (Dan) Sent: Sunday, November 22, 2015 9:48 AM To: Linda Dunbar ; opsec@ietf.org; opsawg@ietf.org Cc: sacm@ietf.org Subject: Re: [OPSEC] [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario Hi Linda, Thanks for answering the call for review and having a look at this work. Concerning your 'little disappointment': This I-D needs to be read in the context of the current charter of the SACM WG. The WG charter focus for this phase is on the 'endpoint posture' and on the 'enterprise use case'. Maybe this makes things somehow more clear. Regards, Dan From: sacm [Caution-mailto:sacm-bounces@ietf.org < Caution-mailto:sacm-bounces@ietf.org > ]On Behalf Of Linda Dunbar Sent: Thursday, November 19, 2015 10:36 PM To: Romascanu, Dan (Dan); opsec@ietf.org < Caution-mailto:opsec@ietf.org > ;opsawg@ietf.org < Caution-mailto:opsawg@ietf.org > Cc: sacm@ietf.org < Caution-mailto:sacm@ietf.org > Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario Reading through the document has made me feel that the Title of the draft is misleading. Based on the title I was expecting to see the Vulnerability Assessment of various network scenarios, which will be very useful information for enterprise and service provider network administrators to put in adequate tools to protect those vulnerability. But the document only describes the procedure in authenticating a end user/points and states that you need to compare with the Vulnerability report (almost like a common sense ) without saying how and what. I guess I had too high the expectation, but a little disappointed of not finding the information I was looking for. Linda Dunbar From: OPSAWG [Caution-mailto:opsawg-bounces@ietf.org < Caution-mailto:opsawg-bounces@ietf.org > ]On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, November 19, 2015 7:51 AM To: opsec@ietf.org < Caution-mailto:opsec@ietf.org > ; opsawg@ietf.org < Caution-mailto:opsawg@ietf.org > Cc: sacm@ietf.org < Caution-mailto:sacm@ietf.org > Subject: [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario Hi, I am reiterating a request that I made at IETF 94 in the OPSAWG meeting, and also sent to the mail lists of opsec and opsawg. The SACM WG is considering a documentCaution-https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/ < Caution-https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dcoffin-2Dsacm-2Dvuln-2Dscenario_&d=BQMFAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=DXOABUhWgQkWYGVviFzuEvwgbivmgrBaeyHQ3_W-Hyg&s=S_CieVlne2x4XqE2cNL0Y_mb0dcPAGm4cN6hKa5k-6Q&e= > that describes the operational practice of vulnerability reports, which we believe is an important use case in the security assessment life cycle. We are requiring feedback from operators about the scenario describe in this document - does it make sense? Is it similar with what you do in operational real life? Are you using similar or different methods for vulnerability assessment in your networks? A quick reading and short feedback would be greatly appreciated. Thanks and Regards, Dan ------=_NextPart_000_0026_01D12CDE.DA1FBD10 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISlTCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEvDCCA6SgAwIBAgIDScrmMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzAwHhcNMTMxMDIzMDAwMDAwWhcN MTYwOTI1MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTENMAsGA1UECxMERElTQTElMCMGA1UEAxMcV09MRktJ RUwuSk9TRVBILkwuMTE3ODkyNDA0MDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsw st9Q8C7pW1taRPZ+xHaNeI3CdIn4F7IJikOSr27UnwmyXZzXdVnJqeEk9KrSKbDAGEqvwK/G/fjT IVcN+2oIqllCY6XpziPmEtnnrej2JRe0wgAckH50lLhfUIwABW8QXU0i6csvryNUtC3eOg1E+hWM N8Gkx+HdMaFuYxfYTB2LysZRRUu6xXjSNc/SIHmRGtPimbEgtrpwOpytdh5ojFVW/yrIJmZ1Ej1L IFIsdSMXxblnD/opeT9sCdFHXpy02sAgTH0ciH7zxKtYtllYMSMac8YGld1GOt9GbFjgAPfJy50Z GhgJ2dEE3zsWEYQynQK47nkZi09JXhxRMK0CAwEAAaOCAWcwggFjMB8GA1UdIwQYMBaAFDVhZigJ vFYlW4vMv4FeYSwwOdMhMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMzAuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFJtzaaaG5JC35TsiFQ4qK5xS5mQCMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMzAu Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDApBgNVHREEIjAggR5KT1NFUEgu TC5XT0xGS0lFTC5DSVZATUFJTC5NSUwwGwYDVR0JBBQwEjAQBggrBgEFBQcJBDEEEwJVUzANBgkq hkiG9w0BAQUFAAOCAQEArgEbQvltVDKnlZ7eoFEjhn6DViXxCZBfiI5Q74uif1fzd2fWdNrhbLx9 cFe4ZP3HjvLNCatEaLt3+qNaRXcnyJejsDCrHAQm+Oy+vsxdquTV8eicXbkC77lTtpZWVgliv5XL GvaPsiNmlJIl9MM9diAPkMgWBGgEfgJyQGf9/wkyNmQK3K+l9qOVC+Cu/fbiSnhX/uIICFO9ZjoL n7vdZO9CzRkZhRlniZhZ6efJnzISQjEaJdm+ntMUuudUW5686Sgk1QdF7DLzDODvjwrzUlbGhoiH nvqDzYCWXjkQfQJ6Q9t9rcZSh/1Xcc7SgRXJYJSEKOs1whOzryAkGpKG7zCCBQcwggPvoAMCAQIC A0nK4zANBgkqhkiG9w0BAQUFADBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5t ZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTMw MB4XDTEzMTAyMzAwMDAwMFoXDTE2MDkyNTIzNTk1OVoweTELMAkGA1UEBhMCVVMxGDAWBgNVBAoT D1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxDTALBgNVBAsTBERJ U0ExJTAjBgNVBAMTHFdPTEZLSUVMLkpPU0VQSC5MLjExNzg5MjQwNDAwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDM+TqEi7DJXmz9FlNoHo2w6BlfZsRONlZtJZBXIasbug6W7TEJktKW gZ71LjY8+e8V7e3hZxrdIsxOM7v6R31dHkBRGYJ/u/2++sP7TmdlJAXc8emgutFkwYXTX93EdlV2 XQcQmcSoPlycrKY8/mqMpJT7cGRUyXgQ5s3MhlWPq8XHJ93FDWOcZ8tb0/fw3HXqZDUgMjwP5riS pjiqL5DJlqosXA0DxzChoWm/MMIpiUmwaTgW3XqqgWZmNmJeRikPnVU1ejhnW9LiXG89dM7S2FOf /mx4CpGdPutbw1/8ChX4FIfl5XHYX8CzXw5nTtHgsi4hZ0ESFcb8AQgOhXdvAgMBAAGjggGyMIIB rjAfBgNVHSMEGDAWgBQ1YWYoCbxWJVuLzL+BXmEsMDnTITA6BgNVHR8EMzAxMC+gLaArhilodHRw Oi8vY3JsLmRpc2EubWlsL2NybC9ET0RFTUFJTENBXzMwLmNybDAOBgNVHQ8BAf8EBAMCBsAwIwYD VR0gBBwwGjALBglghkgBZQIBCwkwCwYJYIZIAWUCAQsTMB0GA1UdDgQWBBQtAm6O4aVQIUriZsl9 BVyz9FLdhTBoBggrBgEFBQcBAQRcMFowNgYIKwYBBQUHMAKGKmh0dHA6Ly9jcmwuZGlzYS5taWwv c2lnbi9ET0RFTUFJTENBXzMwLmNlcjAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWww SQYDVR0RBEIwQIEeSk9TRVBILkwuV09MRktJRUwuQ0lWQE1BSUwuTUlMoB4GCisGAQQBgjcUAgOg EAwOMTE3ODkyNDA0MEBtaWwwGwYDVR0JBBQwEjAQBggrBgEFBQcJBDEEEwJVUzApBgNVHSUEIjAg BgorBgEEAYI3FAICBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQEFBQADggEBAHX5rn+y 0CYm8aMq3ZHpzk2gWrCQCXjFOfSSVwc//+uSMDe1PkyPOVynnR6NT3KuAhDLWlRBV4S66diG8UzB rSReu7N3BrH+BQ2UpBsq+cgbwdse6mJnm7/s1Rkw9OuyKkWlBWZeJzLspccsMaDPdgDz+DwyQLMJ e7DgzJYJjB6BaPcsSHZ0XZrJTG3+/MBIBR8P4PCaO+aWaSA7hGLq30epFxU3OYitJLaZo+jgWxkY jWufowrprFCCoxtaNnagvQ9Gy9XLGpNIyZQNUnqH+b1UOUKkPUVsklT9/8T+7j1ODqwZ3S92w7yP XICXUw9KcwRIqdzBwYmJ9QoOj/h8GEEwggVSMIIEOqADAgECAgIBuTANBgkqhkiG9w0BAQUFADBb MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAK BgNVBAsTA1BLSTEWMBQGA1UEAxMNRG9EIFJvb3QgQ0EgMjAeFw0xMTA5MDgxNjAzMDhaFw0xNzA5 MDgxNjAzMDhaMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNV BAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzAwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDmKSLUFCbRmBpSXsWEg3N+wWCzs9CUvv0clFW/9oQsm8nA dHPvzMKZ8pnJbcoU03T/vhDy9y2/y7sGo+6YUEFlAeFXLLbL5MocrH5SNA6xjgcmPjI1r6NhCsXl CLYSeYxUwXrp8VAfXYM6ZzCzKdsdOkw5IVDYGCyNBnXuY3J4aK1inHWklAbTMmsSrwYHKb4ToMCn 8CVPt/4ft1fgGBKNIWoVuVpU+3dl2Ew/9bo8wDfhBn7Cvp4jjCjRmtfGZzjXc8m9Bx2Fb9WVCprc 2jpOKPCl6wnf5dsLzUevis27b5RA41mcUJ/JDqlxArnc6WmAOok7RQUiGAWEtRLwPMCBAgMBAAGj ggIcMIICGDAOBgNVHQ8BAf8EBAMCAYYwHwYDVR0jBBgwFoAUSXS7DF66ev4CVO97oMaVxgmAcJYw HQYDVR0OBBYEFDVhZigJvFYlW4vMv4FeYSwwOdMhMBIGA1UdEwEB/wQIMAYBAf8CAQAwDAYDVR0k BAUwA4ABADBmBgNVHSAEXzBdMAsGCWCGSAFlAgELBTALBglghkgBZQIBCwkwCwYJYIZIAWUCAQsR MAsGCWCGSAFlAgELEjALBglghkgBZQIBCxMwDAYKYIZIAWUDAgEDGjAMBgpghkgBZQMCAQMbMDcG A1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly9jcmwuZGlzYS5taWwvY3JsL0RPRFJPT1RDQTIuY3JsMIIB AQYIKwYBBQUHAQEEgfQwgfEwOgYIKwYBBQUHMAKGLmh0dHA6Ly9jcmwuZGlzYS5taWwvaXNzdWVk dG8vRE9EUk9PVENBMl9JVC5wN2MwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMIGQ BggrBgEFBQcwAoaBg2xkYXA6Ly9jcmwuZ2RzLmRpc2EubWlsL2NuJTNkRG9EJTIwUm9vdCUyMENB JTIwMiUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5TLiUyMEdvdmVybm1lbnQlMmNjJTNk VVM/Y3Jvc3NDZXJ0aWZpY2F0ZVBhaXI7YmluYXJ5MA0GCSqGSIb3DQEBBQUAA4IBAQAKiFYcpVcm WmLLddDdhsVS4i/zvBFkP4wvPhH8mGBA8oANKIKaaP7gSEsn0zoKe5X2AwyBFJFCOmBs4itTLezf Ea71VBfwAfmXB6ebqwvbrJeJCcbv+Qc0FgCofhFTnnwvoTiimXk5NEFufbhYMFaInuSqZEXZoERi OrflMdORgPEbELJncNVbq1m0WkgWQsQCTNpsaMpQHTG+N5nHz1PMQilWw50XygPnEFrxOTwczPsb lwom8zHf4KtcJJ2e3jh9AlFnRvmTcIXtClXC9MFoWp8IyR17m3bcVO85jBjlDETu9wayH/XL5g69 1KH/1PmRByJSebfA/eyy+IX0RPtcMYIDMjCCAy4CAQEwZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UE ChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMP RE9EIEVNQUlMIENBLTMwAgNJyuMwCQYFKw4DAhoFAKCCAaMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUxMjAyMTM1MzAyWjAjBgkqhkiG9w0BCQQxFgQUYWJ8AdV1 MVOn2PO6RjOMqOJ4XVswWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwcwYJKwYBBAGC NxAEMWYwZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQL EwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTMwAgNJyuYwdQYLKoZI hvcNAQkQAgsxZqBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAK BgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzACA0nK5jAN BgkqhkiG9w0BAQEFAASCAQC+oYN8Zu1SfKOzaStqlY2sAQTtAoT8JIz2oIcqrOvmQCImdh4i5gVJ oId2z2XO7L1fYJKQZKQHvUYqs/damcUPSL1Zf7IsbVpj0UFRsZGN9CUs16Vf3Vu4Iqbr/o1sbEyC 5sMWSBglbbP1vHmdwtbi5OAKSo6IZO2VmMHiL8yWXNxnBlc5C/E+vvJEWCo7cRfcUIwNL/RPrb0V IvnGInSQthf2wYXJ34fAE7Cd5uLYLQcqwEFBz94FtYM+wUVmbOQMhFdmKSWCY/ZqPqK2KenmASGu yv1MuBwoMLqU4gyNbvLG9OrkRDyGaWMF3t8a6AgTAS8bZg3g4p0z96cLNsLyAAAAAAAA ------=_NextPart_000_0026_01D12CDE.DA1FBD10-- From nobody Wed Dec 2 06:34:40 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8481A9075; Wed, 2 Dec 2015 06:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziRKYcIyK1dT; Wed, 2 Dec 2015 06:30:56 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E42B1A9040; Wed, 2 Dec 2015 06:30:56 -0800 (PST) Received: by wmvv187 with SMTP id v187so257695307wmv.1; Wed, 02 Dec 2015 06:30:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=39cjDg4TOAfOK/VXRoQNFL1K96Hsow8HJTuzIS6iokQ=; b=RTC0c0PKq7KBKKZfJxLfYzRrkVApsf49QOTOeQHj9CeTiNIEgltA8rQMiYci2z3ovN YLfWScNeO4oRVeOkjaQDVkz4ZfrK5lduu/bgiYg+qXAyDfLwqT4Zle2p5cNpVCrdclTw TqbRJpwFJx4nbazl5bWuJnnj7voy7bwUGvvK5HXBRJ+7L6Ldz3s5BxoYSEBv/UgFHcg7 Ii4k+6u2bWcBJSbnLqjNGJzP4t1gQexEZtAjvoqetUqtk8wcUyB7AFY1DQ9X1EPNFAed goc5QGgUKBYYU/i7Rjs+5ji3Tv8yPux7IX6wbaTmgayzUSgp+hX+IJ5+y1UNjOpZlCY4 YmwQ== MIME-Version: 1.0 X-Received: by 10.28.144.139 with SMTP id s133mr45625991wmd.90.1449066654917; Wed, 02 Dec 2015 06:30:54 -0800 (PST) Received: by 10.28.52.130 with HTTP; Wed, 2 Dec 2015 06:30:54 -0800 (PST) In-Reply-To: <9F61CC8E6ED7BC4DBA90C13F25D29C006325E379@umechpao0.easf.csd.disa.mil> References: <9F61CC8E6ED7BC4DBA90C13F25D29C006325E379@umechpao0.easf.csd.disa.mil> Date: Wed, 2 Dec 2015 09:30:54 -0500 Message-ID: From: Kathleen Moriarty To: "Wolfkiel, Joseph L CIV DISA ID (US)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Wed, 02 Dec 2015 06:34:40 -0800 Cc: "sacm@ietf.org" , Linda Dunbar , "opsec@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSEC] [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 14:30:59 -0000 Hello, I also took the time to read the draft and it currently reads like a scenario or an expanded use case draft, not a solution draft. Does SACM need this or is there plans to merge it with solution work into one draft? I could see the value in the latter, but I don't see how a scenario draft on it's own will help speed up progress for the WG. Thanks, Kathleen On Wed, Dec 2, 2015 at 8:53 AM, Wolfkiel, Joseph L CIV DISA ID (US) wrote: > I think the disappointment may have been headed off if the document was m= ore explicit, right at the beginning, about what a "vulnerability report" i= s. I got 2/3 of the way through the document before I understood that "vul= nerability report" and "vulnerability definition" are effectively the same = construct. A vulnerability report apparently is an announcement that a vul= nerability has been discovered and defined to the point where endpoint mana= gers can run assessments on their endpoints to determine if their endpoints= have the vulnerability or not. > > This concept is confusing because generally, with existing vulnerability = scanners, new vulnerability "reports" are a subset of updated vulnerability= definitions that automatically propagated to the tools and aren't delivere= d as stand-alone "reports". So a vulnerability "report" would look somethi= ng like the report at https://web.nvd.nist.gov/view/vuln/detail?vulnId=3DCV= E-2015-8395 (I think). > > Joseph L. Wolfkiel > SCM Engineering Lead > DISA ID52 > Fort Meade DISA Acquisiton Bldg Cube A4A58E > Work: (301) 225-8820 > Gov Cell: (571) 814-8231 > Joseph.L.Wolfkiel.civ@mail.mil > > > > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Haynes, Dan > Sent: Wednesday, December 02, 2015 8:36 AM > To: Romascanu, Dan (Dan); Linda Dunbar; opsec@ietf.org; opsawg@ietf.org > Cc: sacm@ietf.org > Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessmen= t Scenario > > > Hi Linda, > > > Please let us know if there are any specific questions that we can answer= for you, to help clarify the document, after considering it in the context= of the SACM charter as Dan mentioned. > > > > Thanks, > > Danny > > > > From: OPSEC [Caution-mailto:opsec-bounces@ietf.org] On Behalf OfRomascanu= , Dan (Dan) > Sent: Sunday, November 22, 2015 9:48 AM > To: Linda Dunbar ; opsec@ietf.org; opsawg@ietf.o= rg > Cc: sacm@ietf.org > Subject: Re: [OPSEC] [sacm] [OPSAWG] Feedback on the SACM Vulnerability A= ssessment Scenario > > > > Hi Linda, > > > > Thanks for answering the call for review and having a look at this work. > > > > Concerning your 'little disappointment': This I-D needs to be read in the= context of the current charter of the SACM WG. The WG charter focus for th= is phase is on the 'endpoint posture' and on the 'enterprise use case'. May= be this makes things somehow more clear. > > > > Regards, > > > > Dan > > > > > > From: sacm [Caution-mailto:sacm-bounces@ietf.org < Caution-mailto:sacm-bo= unces@ietf.org > ]On Behalf Of Linda Dunbar > Sent: Thursday, November 19, 2015 10:36 PM > To: Romascanu, Dan (Dan); opsec@ietf.org < Caution-mailto:opsec@ietf.org = > ;opsawg@ietf.org < Caution-mailto:opsawg@ietf.org > > Cc: sacm@ietf.org < Caution-mailto:sacm@ietf.org > > Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessmen= t Scenario > > > > Reading through the document has made me feel that the Title of the draft= is misleading. > > Based on the title I was expecting to see the Vulnerability Assessment of= various network scenarios, which will be very useful information for enter= prise and service provider network administrators to put in adequate tools = to protect those vulnerability. > > > > But the document only describes the procedure in authenticating a end use= r/points and states that you need to compare with the Vulnerability report = (almost like a common sense ) without saying how and what. I guess I had t= oo high the expectation, but a little disappointed of not finding the infor= mation I was looking for. > > > > Linda Dunbar > > > > > > > > From: OPSAWG [Caution-mailto:opsawg-bounces@ietf.org < Caution-mailto:ops= awg-bounces@ietf.org > ]On Behalf Of Romascanu, Dan (Dan) > Sent: Thursday, November 19, 2015 7:51 AM > To: opsec@ietf.org < Caution-mailto:opsec@ietf.org > ; opsawg@ietf.org < = Caution-mailto:opsawg@ietf.org > > Cc: sacm@ietf.org < Caution-mailto:sacm@ietf.org > > Subject: [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario > > > > Hi, > > > > I am reiterating a request that I made at IETF 94 in the OPSAWG meeting, = and also sent to the mail lists of opsec and opsawg. The SACM WG is conside= ring a documentCaution-https://datatracker.ietf.org/doc/draft-coffin-sacm-v= uln-scenario/ < Caution-https://urldefense.proofpoint.com/v2/url?u=3Dhttps-= 3A__datatracker.ietf.org_doc_draft-2Dcoffin-2Dsacm-2Dvuln-2Dscenario_&d=3DB= QMFAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrph= pBsFA&m=3DDXOABUhWgQkWYGVviFzuEvwgbivmgrBaeyHQ3_W-Hyg&s=3DS_CieVlne2x4XqE2c= NL0Y_mb0dcPAGm4cN6hKa5k-6Q&e=3D > that describes the operational practice = of vulnerability reports, which we believe is an important use case in the = security assessment life cycle. We are requiring feedback from operators ab= out the scenario describe in this document - does it make sense? Is it simi= lar with what you do in operational real life? Are you using similar or dif= ferent methods for vulnerability assessment in your networks? A quick readi= ng and short feedback would be greatly > appreciated. > > > > Thanks and Regards, > > > > Dan > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > --=20 Best regards, Kathleen From nobody Wed Dec 2 06:56:48 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64D31A9126; Wed, 2 Dec 2015 06:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8lTRsMq1-qM; Wed, 2 Dec 2015 06:51:04 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0144.outbound.protection.outlook.com [207.46.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FBC61A9123; Wed, 2 Dec 2015 06:51:03 -0800 (PST) Received: from DM2PR09MB0365.namprd09.prod.outlook.com (10.160.247.18) by DM2PR09MB0366.namprd09.prod.outlook.com (10.160.247.20) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 2 Dec 2015 14:51:01 +0000 Received: from DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) by DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) with mapi id 15.01.0331.023; Wed, 2 Dec 2015 14:51:01 +0000 From: "Waltermire, David A." To: Kathleen Moriarty , "Wolfkiel, Joseph L CIV DISA ID (US)" Thread-Topic: [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario Thread-Index: AdEtB9R3gLrqLzATaUKfZFMlPhYJogABjh0AAAARMvA= Date: Wed, 2 Dec 2015 14:51:01 +0000 Message-ID: References: <9F61CC8E6ED7BC4DBA90C13F25D29C006325E379@umechpao0.easf.csd.disa.mil> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.227.39] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0366; 5:BeitqYE2SWbWGuHl5sqthxq8/kQUhK71QNnetEwaZaFFeVt5ywIVQ5bM9gaiZdKcKWav44t1TXkuMoSq+nI70S4cO/up+S29dUmEicaXuce2bAbp/OaRD8H1zItuFPPQNFbn5sqYCHxTRreDI06r9Q==; 24:urrzZOzcnAJpGnLis4ltOYo1y8mIXLvSvI9lZ9lDEHCDCZL52JksXvFDh+WAsi96PesV/bWc+JkouXMgnZ6TruzeuX/j+8fkXJBcauu3ijA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0366; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001); SRVR:DM2PR09MB0366; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0366; x-forefront-prvs: 077884B8B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(189002)(52604005)(199003)(377454003)(164054003)(24454002)(13464003)(102836003)(33656002)(76576001)(50986999)(10400500002)(106356001)(1096002)(105586002)(3846002)(5004730100002)(6116002)(77096005)(11100500001)(575784001)(5003600100002)(586003)(19580395003)(74316001)(1220700001)(122556002)(5002640100001)(40100003)(76176999)(66066001)(54356999)(87936001)(92566002)(97736004)(101416001)(2950100001)(19580405001)(2900100001)(5001960100002)(81156007)(15975445007)(5001770100001)(189998001)(86362001)(99286002)(5008740100001)(7059030)(19627235001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0366; H:DM2PR09MB0365.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2015 14:51:01.4431 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0366 Archived-At: X-Mailman-Approved-At: Wed, 02 Dec 2015 06:56:46 -0800 Cc: "sacm@ietf.org" , Linda Dunbar , "opsec@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSEC] [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 14:51:08 -0000 Kathleen, There are a number of operational business processes that SACM is working t= o support to include: software asset management, vulnerability management, = configuration management, and others. Considering the totality of these use= cases is too big to tackle all at once. The current SACM use cases help to= inform some of the operations that need to be supported, but they are very= abstract and don't help as much in making clear what protocols and data mo= dels are needed. Definitely not the specifics of these specifications. The = discussion around the vulnerability draft has been about focusing work by i= terating on concrete operational scenarios (such as that draft) that will e= nable SACM to produce useful solutions more quickly in a way that can build= on previous iterations. I believe the vulnerability scenario draft is bein= g proposed as the first iteration of many.=20 IMHO, without such a focus, we will continue to stagnate and make intermitt= ent progress. This draft has stimulated a good amount of feedback and discu= ssion, which makes me think it is accomplishing its intended goal. As you m= entioned, the next steps should be to clarify the vulnerability scenario an= d align extensible solutions that will address the scenario. In doing so th= is work can provide the foundations for the next scenario in the next itera= tion since many of the operational processes have common information needs. Does this help to clear up how the draft may be used? Regards, Dave > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Kathleen Moriarty > Sent: Wednesday, December 02, 2015 9:31 AM > To: Wolfkiel, Joseph L CIV DISA ID (US) > Cc: Haynes, Dan ; sacm@ietf.org; Linda Dunbar > ; Romascanu, Dan (Dan) > ; opsec@ietf.org; opsawg@ietf.org > Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability > Assessment Scenario >=20 > Hello, >=20 > I also took the time to read the draft and it currently reads like a scen= ario or > an expanded use case draft, not a solution draft. Does SACM need this or= is > there plans to merge it with solution work into one draft? I could see t= he > value in the latter, but I don't see how a scenario draft on it's own wil= l help > speed up progress for the WG. >=20 > Thanks, > Kathleen >=20 > On Wed, Dec 2, 2015 at 8:53 AM, Wolfkiel, Joseph L CIV DISA ID (US) > wrote: > > I think the disappointment may have been headed off if the document was > more explicit, right at the beginning, about what a "vulnerability report= " is. I > got 2/3 of the way through the document before I understood that > "vulnerability report" and "vulnerability definition" are effectively the= same > construct. A vulnerability report apparently is an announcement that a > vulnerability has been discovered and defined to the point where endpoint > managers can run assessments on their endpoints to determine if their > endpoints have the vulnerability or not. > > > > This concept is confusing because generally, with existing vulnerabilit= y > scanners, new vulnerability "reports" are a subset of updated vulnerabili= ty > definitions that automatically propagated to the tools and aren't deliver= ed as > stand-alone "reports". So a vulnerability "report" would look something = like > the report at https://web.nvd.nist.gov/view/vuln/detail?vulnId=3DCVE-2015= - > 8395 (I think). > > > > Joseph L. Wolfkiel > > SCM Engineering Lead > > DISA ID52 > > Fort Meade DISA Acquisiton Bldg Cube A4A58E > > Work: (301) 225-8820 > > Gov Cell: (571) 814-8231 > > Joseph.L.Wolfkiel.civ@mail.mil > > > > > > > > -----Original Message----- > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Haynes, Dan > > Sent: Wednesday, December 02, 2015 8:36 AM > > To: Romascanu, Dan (Dan); Linda Dunbar; opsec@ietf.org; > > opsawg@ietf.org > > Cc: sacm@ietf.org > > Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability > > Assessment Scenario > > > > > > Hi Linda, > > > > > > Please let us know if there are any specific questions that we can answ= er > for you, to help clarify the document, after considering it in the contex= t of > the SACM charter as Dan mentioned. > > > > > > > > Thanks, > > > > Danny > > > > > > > > From: OPSEC [Caution-mailto:opsec-bounces@ietf.org] On Behalf > > OfRomascanu, Dan (Dan) > > Sent: Sunday, November 22, 2015 9:48 AM > > To: Linda Dunbar ; opsec@ietf.org; > > opsawg@ietf.org > > Cc: sacm@ietf.org > > Subject: Re: [OPSEC] [sacm] [OPSAWG] Feedback on the SACM > > Vulnerability Assessment Scenario > > > > > > > > Hi Linda, > > > > > > > > Thanks for answering the call for review and having a look at this work= . > > > > > > > > Concerning your 'little disappointment': This I-D needs to be read in t= he > context of the current charter of the SACM WG. The WG charter focus for > this phase is on the 'endpoint posture' and on the 'enterprise use case'. > Maybe this makes things somehow more clear. > > > > > > > > Regards, > > > > > > > > Dan > > > > > > > > > > > > From: sacm [Caution-mailto:sacm-bounces@ietf.org < > > Caution-mailto:sacm-bounces@ietf.org > ]On Behalf Of Linda Dunbar > > Sent: Thursday, November 19, 2015 10:36 PM > > To: Romascanu, Dan (Dan); opsec@ietf.org < > > Caution-mailto:opsec@ietf.org > ;opsawg@ietf.org < > > Caution-mailto:opsawg@ietf.org > > > Cc: sacm@ietf.org < Caution-mailto:sacm@ietf.org > > > Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability > > Assessment Scenario > > > > > > > > Reading through the document has made me feel that the Title of the dra= ft > is misleading. > > > > Based on the title I was expecting to see the Vulnerability Assessment = of > various network scenarios, which will be very useful information for > enterprise and service provider network administrators to put in adequate > tools to protect those vulnerability. > > > > > > > > But the document only describes the procedure in authenticating a end > user/points and states that you need to compare with the Vulnerability > report (almost like a common sense ) without saying how and what. I gues= s I > had too high the expectation, but a little disappointed of not finding th= e > information I was looking for. > > > > > > > > Linda Dunbar > > > > > > > > > > > > > > > > From: OPSAWG [Caution-mailto:opsawg-bounces@ietf.org < > > Caution-mailto:opsawg-bounces@ietf.org > ]On Behalf Of Romascanu, Dan > > (Dan) > > Sent: Thursday, November 19, 2015 7:51 AM > > To: opsec@ietf.org < Caution-mailto:opsec@ietf.org > ; opsawg@ietf.org > > < Caution-mailto:opsawg@ietf.org > > > Cc: sacm@ietf.org < Caution-mailto:sacm@ietf.org > > > Subject: [OPSAWG] Feedback on the SACM Vulnerability Assessment > > Scenario > > > > > > > > Hi, > > > > > > > > I am reiterating a request that I made at IETF 94 in the OPSAWG > > meeting, and also sent to the mail lists of opsec and opsawg. The SACM > > WG is considering a > > documentCaution-https://datatracker.ietf.org/doc/draft-coffin-sacm-vul > > n-scenario/ < > > Caution-https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatrac= k > > er.ietf.org_doc_draft-2Dcoffin-2Dsacm-2Dvuln- > 2Dscenario_&d=3DBQMFAg&c=3DBF > > > pWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBs > FA&m=3DD > > XOABUhWgQkWYGVviFzuEvwgbivmgrBaeyHQ3_W- > Hyg&s=3DS_CieVlne2x4XqE2cNL0Y_mb0 > > dcPAGm4cN6hKa5k-6Q&e=3D > that describes the operational practice of > > vulnerability reports, which we believe is an important use case in > > the security assessment life cycle. We are requiring feedback from > > operators about the scenario describe in this document - does it make > > sense? Is it similar with what you do in operational real life? Are > > you using similar or different methods for vulnerability assessment in > > your networks? A quick reading and short feedback would be greatl > y > > appreciated. > > > > > > > > Thanks and Regards, > > > > > > > > Dan > > > > > > > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > >=20 >=20 >=20 > -- >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From nobody Wed Dec 2 07:07:00 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FFB1ACDCD; Wed, 2 Dec 2015 07:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yb-Cv3qpSx8g; Wed, 2 Dec 2015 07:06:07 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6511ACD8D; Wed, 2 Dec 2015 07:06:07 -0800 (PST) Received: by obbnk6 with SMTP id nk6so34561763obb.2; Wed, 02 Dec 2015 07:06:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=/BAfXp5mCF4I9CBYi6951qGW2zrzOwfZ/JUVHk5CxkE=; b=DJ1nGg/rqx1qF921RXPW9Xk3KvFboVUfETRETgZob4rKK9VB9l8lhrm5+D78B20h0L 7p/D0JhoKpu2C3ZWRrEI7r8rzUMxkFQkVkrtLtUmlYUJYsF5RLYN5ibX1xHqEvneIYFP mkVee0hbv+Z2+Ctg5+W3Uhq0V9nty3L3TQLcLGkIGIia+zjHIsqVkRg91PMz7AQteWT8 AL0NWxtg2cWMZSMkYVo13yDWStLP8xJ5vFm6Q+InXtWZKMnKx/jYU3/W6GiiwQ6yxElx F6WkHmJ2IYthOCgx7K1wr0wo9eNr4D1V0YyNnYoQgXPcS23CY0VV64O6o8ovqZtvS9tD AelQ== X-Received: by 10.60.51.70 with SMTP id i6mr3202298oeo.3.1449068734646; Wed, 02 Dec 2015 07:05:34 -0800 (PST) MIME-Version: 1.0 References: <9F61CC8E6ED7BC4DBA90C13F25D29C006325E379@umechpao0.easf.csd.disa.mil> In-Reply-To: From: Jessica Fitzgerald-McKay Date: Wed, 02 Dec 2015 15:05:24 +0000 Message-ID: To: "Waltermire, David A." , Kathleen Moriarty , "Wolfkiel, Joseph L CIV DISA ID (US)" Content-Type: multipart/alternative; boundary=001a11c301cc2f12220525eb9bf3 Archived-At: X-Mailman-Approved-At: Wed, 02 Dec 2015 07:06:57 -0800 Cc: "sacm@ietf.org" , Linda Dunbar , "opsec@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSEC] [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 15:06:10 -0000 --001a11c301cc2f12220525eb9bf3 Content-Type: text/plain; charset=UTF-8 Dave, that is a very accurate capture of how the vulnerability assessment draft can be used to move SACM work forward. The SACM charter is broad; making progress on solutions drafts that address the goals laid out in the SACM charter necessitates focusing on a smaller scale scenario to collect the right data, over the right protocols, that enable security automation. The vulnerability assessment scenario does just that. It allows us to make progress on a manageable subset of our goals while keeping an eye to the bigger security automation landscape. Such a scenario is of great value to SACM, and is the only way we will be able to make real progress. On Wed, Dec 2, 2015, 9:51 AM Waltermire, David A. wrote: > > Kathleen, > > There are a number of operational business processes that SACM is working > to support to include: software asset management, vulnerability management, > configuration management, and others. Considering the totality of these use > cases is too big to tackle all at once. The current SACM use cases help to > inform some of the operations that need to be supported, but they are very > abstract and don't help as much in making clear what protocols and data > models are needed. Definitely not the specifics of these specifications. > The discussion around the vulnerability draft has been about focusing work > by iterating on concrete operational scenarios (such as that draft) that > will enable SACM to produce useful solutions more quickly in a way that can > build on previous iterations. I believe the vulnerability scenario draft is > being proposed as the first iteration of many. > > IMHO, without such a focus, we will continue to stagnate and make > intermittent progress. This draft has stimulated a good amount of feedback > and discussion, which makes me think it is accomplishing its intended goal. > As you mentioned, the next steps should be to clarify the vulnerability > scenario and align extensible solutions that will address the scenario. In > doing so this work can provide the foundations for the next scenario in the > next iteration since many of the operational processes have common > information needs. > > Does this help to clear up how the draft may be used? > > Regards, > Dave > > > -----Original Message----- > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Kathleen Moriarty > > Sent: Wednesday, December 02, 2015 9:31 AM > > To: Wolfkiel, Joseph L CIV DISA ID (US) > > Cc: Haynes, Dan ; sacm@ietf.org; Linda Dunbar > > ; Romascanu, Dan (Dan) > > ; opsec@ietf.org; opsawg@ietf.org > > Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability > > Assessment Scenario > > > > Hello, > > > > I also took the time to read the draft and it currently reads like a > scenario or > > an expanded use case draft, not a solution draft. Does SACM need this > or is > > there plans to merge it with solution work into one draft? I could see > the > > value in the latter, but I don't see how a scenario draft on it's own > will help > > speed up progress for the WG. > > > > Thanks, > > Kathleen > > > > On Wed, Dec 2, 2015 at 8:53 AM, Wolfkiel, Joseph L CIV DISA ID (US) > > wrote: > > > I think the disappointment may have been headed off if the document was > > more explicit, right at the beginning, about what a "vulnerability > report" is. I > > got 2/3 of the way through the document before I understood that > > "vulnerability report" and "vulnerability definition" are effectively > the same > > construct. A vulnerability report apparently is an announcement that a > > vulnerability has been discovered and defined to the point where endpoint > > managers can run assessments on their endpoints to determine if their > > endpoints have the vulnerability or not. > > > > > > This concept is confusing because generally, with existing > vulnerability > > scanners, new vulnerability "reports" are a subset of updated > vulnerability > > definitions that automatically propagated to the tools and aren't > delivered as > > stand-alone "reports". So a vulnerability "report" would look something > like > > the report at https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015- > > 8395 (I think). > > > > > > Joseph L. Wolfkiel > > > SCM Engineering Lead > > > DISA ID52 > > > Fort Meade DISA Acquisiton Bldg Cube A4A58E > > > Work: (301) 225-8820 > > > Gov Cell: (571) 814-8231 > > > Joseph.L.Wolfkiel.civ@mail.mil > > > > > > > > > > > > -----Original Message----- > > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Haynes, Dan > > > Sent: Wednesday, December 02, 2015 8:36 AM > > > To: Romascanu, Dan (Dan); Linda Dunbar; opsec@ietf.org; > > > opsawg@ietf.org > > > Cc: sacm@ietf.org > > > Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability > > > Assessment Scenario > > > > > > > > > Hi Linda, > > > > > > > > > Please let us know if there are any specific questions that we can > answer > > for you, to help clarify the document, after considering it in the > context of > > the SACM charter as Dan mentioned. > > > > > > > > > > > > Thanks, > > > > > > Danny > > > > > > > > > > > > From: OPSEC [Caution-mailto:opsec-bounces@ietf.org] On Behalf > > > OfRomascanu, Dan (Dan) > > > Sent: Sunday, November 22, 2015 9:48 AM > > > To: Linda Dunbar ; opsec@ietf.org; > > > opsawg@ietf.org > > > Cc: sacm@ietf.org > > > Subject: Re: [OPSEC] [sacm] [OPSAWG] Feedback on the SACM > > > Vulnerability Assessment Scenario > > > > > > > > > > > > Hi Linda, > > > > > > > > > > > > Thanks for answering the call for review and having a look at this > work. > > > > > > > > > > > > Concerning your 'little disappointment': This I-D needs to be read in > the > > context of the current charter of the SACM WG. The WG charter focus for > > this phase is on the 'endpoint posture' and on the 'enterprise use case'. > > Maybe this makes things somehow more clear. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > From: sacm [Caution-mailto:sacm-bounces@ietf.org < > > > Caution-mailto:sacm-bounces@ietf.org > ]On Behalf Of Linda Dunbar > > > Sent: Thursday, November 19, 2015 10:36 PM > > > To: Romascanu, Dan (Dan); opsec@ietf.org < > > > Caution-mailto:opsec@ietf.org > ;opsawg@ietf.org < > > > Caution-mailto:opsawg@ietf.org > > > > Cc: sacm@ietf.org < Caution-mailto:sacm@ietf.org > > > > Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability > > > Assessment Scenario > > > > > > > > > > > > Reading through the document has made me feel that the Title of the > draft > > is misleading. > > > > > > Based on the title I was expecting to see the Vulnerability Assessment > of > > various network scenarios, which will be very useful information for > > enterprise and service provider network administrators to put in adequate > > tools to protect those vulnerability. > > > > > > > > > > > > But the document only describes the procedure in authenticating a end > > user/points and states that you need to compare with the Vulnerability > > report (almost like a common sense ) without saying how and what. I > guess I > > had too high the expectation, but a little disappointed of not finding > the > > information I was looking for. > > > > > > > > > > > > Linda Dunbar > > > > > > > > > > > > > > > > > > > > > > > > From: OPSAWG [Caution-mailto:opsawg-bounces@ietf.org < > > > Caution-mailto:opsawg-bounces@ietf.org > ]On Behalf Of Romascanu, Dan > > > (Dan) > > > Sent: Thursday, November 19, 2015 7:51 AM > > > To: opsec@ietf.org < Caution-mailto:opsec@ietf.org > ; opsawg@ietf.org > > > < Caution-mailto:opsawg@ietf.org > > > > Cc: sacm@ietf.org < Caution-mailto:sacm@ietf.org > > > > Subject: [OPSAWG] Feedback on the SACM Vulnerability Assessment > > > Scenario > > > > > > > > > > > > Hi, > > > > > > > > > > > > I am reiterating a request that I made at IETF 94 in the OPSAWG > > > meeting, and also sent to the mail lists of opsec and opsawg. The SACM > > > WG is considering a > > > documentCaution-https://datatracker.ietf.org/doc/draft-coffin-sacm-vul > > > n-scenario/ < > > > Caution-https://urldefense.proofpoint.com/v2/url?u=https-3A__datatrack > > > er.ietf.org_doc_draft-2Dcoffin-2Dsacm-2Dvuln- > > 2Dscenario_&d=BQMFAg&c=BF > > > > > pWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBs > > FA&m=D > > > XOABUhWgQkWYGVviFzuEvwgbivmgrBaeyHQ3_W- > > Hyg&s=S_CieVlne2x4XqE2cNL0Y_mb0 > > > dcPAGm4cN6hKa5k-6Q&e= > that describes the operational practice of > > > vulnerability reports, which we believe is an important use case in > > > the security assessment life cycle. We are requiring feedback from > > > operators about the scenario describe in this document - does it make > > > sense? Is it similar with what you do in operational real life? Are > > > you using similar or different methods for vulnerability assessment in > > > your networks? A quick reading and short feedback would be greatl > > y > > > appreciated. > > > > > > > > > > > > Thanks and Regards, > > > > > > > > > > > > Dan > > > > > > > > > > > > > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > > > > > -- > > > > Best regards, > > Kathleen > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > --001a11c301cc2f12220525eb9bf3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dave, that is a very accurate capture of how the vulnerabili= ty assessment draft can be used to move SACM work forward. The SACM charter= is broad; making progress on solutions drafts that address the goals laid = out in the SACM charter necessitates focusing on a smaller scale scenario t= o collect the right data, over the right protocols, that enable security au= tomation. The vulnerability assessment scenario does just that. It allows u= s to make progress on a manageable subset of our goals while keeping an eye= to the bigger security automation landscape. Such a scenario is of great v= alue to SACM, and is the only way we will be able to make real progress.

On Wed, Dec 2, 2015, 9:51 A= M=C2=A0Waltermire, David A. <david.waltermire@nist.gov> wrote:

Kathleen,

There are a number of operational business processes that SACM is working t= o support to include: software asset management, vulnerability management, = configuration management, and others. Considering the totality of these use= cases is too big to tackle all at once. The current SACM use cases help to= inform some of the operations that need to be supported, but they are very= abstract and don't help as much in making clear what protocols and dat= a models are needed. Definitely not the specifics of these specifications. = The discussion around the vulnerability draft has been about focusing work = by iterating on concrete operational scenarios (such as that draft) that wi= ll enable SACM to produce useful solutions more quickly in a way that can b= uild on previous iterations. I believe the vulnerability scenario draft is = being proposed as the first iteration of many.

IMHO, without such a focus, we will continue to stagnate and make intermitt= ent progress. This draft has stimulated a good amount of feedback and discu= ssion, which makes me think it is accomplishing its intended goal. As you m= entioned, the next steps should be to clarify the vulnerability scenario an= d align extensible solutions that will address the scenario. In doing so th= is work can provide the foundations for the next scenario in the next itera= tion since many of the operational processes have common information needs.=

Does this help to clear up how the draft may be used?

Regards,
Dave

> -----Original Message-----
> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Kathleen Moriarty
> Sent: Wednesday, December 02, 2015 9:31 AM
> To: Wolfkiel, Joseph L CIV DISA ID (US) <joseph.l.wolfkiel.civ@mail.mil>
> Cc: Haynes, Dan <dhaynes@mitre.org>; sacm@ietf.org; Linda Dunbar
> <linda= .dunbar@huawei.com>; Romascanu, Dan (Dan)
> <dromasca@a= vaya.com>; opsec= @ietf.org; opsawg@= ietf.org
> Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability
> Assessment Scenario
>
> Hello,
>
> I also took the time to read the draft and it currently reads like a s= cenario or
> an expanded use case draft, not a solution draft.=C2=A0 Does SACM need= this or is
> there plans to merge it with solution work into one draft?=C2=A0 I cou= ld see the
> value in the latter, but I don't see how a scenario draft on it= 9;s own will help
> speed up progress for the WG.
>
> Thanks,
> Kathleen
>
> On Wed, Dec 2, 2015 at 8:53 AM, Wolfkiel, Joseph L CIV DISA ID (US) > <joseph.l.wolfkiel.civ@mail.mil> wrote:
> > I think the disappointment may have been headed off if the docume= nt was
> more explicit, right at the beginning, about what a "vulnerabilit= y report" is.=C2=A0 I
> got 2/3 of the way through the document before I understood that
> "vulnerability report" and "vulnerability definition&qu= ot; are effectively the same
> construct.=C2=A0 A vulnerability report apparently is an announcement = that a
> vulnerability has been discovered and defined to the point where endpo= int
> managers can run assessments on their endpoints to determine if their<= br> > endpoints have the vulnerability or not.
> >
> > This concept is confusing because generally, with existing vulner= ability
> scanners, new vulnerability "reports" are a subset of update= d vulnerability
> definitions that automatically propagated to the tools and aren't = delivered as
> stand-alone "reports".=C2=A0 So a vulnerability "report= " would look something like
> the report at https://web.nvd.nist.= gov/view/vuln/detail?vulnId=3DCVE-2015-
> 8395 (I think).
> >
> > Joseph L. Wolfkiel
> > SCM Engineering Lead
> > DISA ID52
> > Fort Meade DISA Acquisiton Bldg Cube A4A58E
> > Work: (301) 225-8820
> > Gov Cell: (571) 814-8231
> > Joseph.L.Wolfkiel.civ@mail.mil
> >
> >
> >
> > -----Original Message-----
> > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Haynes, Dan
> > Sent: Wednesday, December 02, 2015 8:36 AM
> > To: Romascanu, Dan (Dan); Linda Dunbar; opsec@ietf.org;
> > opsawg@ietf.= org
> > Cc: sacm@ietf.= org
> > Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability > > Assessment Scenario
> >
> >
> > Hi Linda,
> >
> >
> > Please let us know if there are any specific questions that we ca= n answer
> for you, to help clarify the document, after considering it in the con= text of
> the SACM charter as Dan mentioned.
> >
> >
> >
> > Thanks,
> >
> > Danny
> >
> >
> >
> > From: OPSEC [Caution-mailto:opsec-bounces@ietf.org] On Behalf
> > OfRomascanu, Dan (Dan)
> > Sent: Sunday, November 22, 2015 9:48 AM
> > To: Linda Dunbar <linda.dunbar@huawei.com>; opsec@ietf.org;
> > opsawg@ietf.= org
> > Cc: sacm@ietf.= org
> > Subject: Re: [OPSEC] [sacm] [OPSAWG] Feedback on the SACM
> > Vulnerability Assessment Scenario
> >
> >
> >
> > Hi Linda,
> >
> >
> >
> > Thanks for answering the call for review and having a look at thi= s work.
> >
> >
> >
> > Concerning your 'little disappointment': This I-D needs t= o be read in the
> context of the current charter of the SACM WG. The WG charter focus fo= r
> this phase is on the 'endpoint posture' and on the 'enterp= rise use case'.
> Maybe this makes things somehow more clear.
> >
> >
> >
> > Regards,
> >
> >
> >
> > Dan
> >
> >
> >
> >
> >
> > From: sacm [Caution-mailto:sacm-bounces@ietf.org <
> > Caution-mailto:sacm-bounces@ietf.org > ]On Behalf Of Linda Dunbar
> > Sent: Thursday, November 19, 2015 10:36 PM
> > To: Romascanu, Dan (Dan); opsec@ietf.org <
> > Caution-mailto:opsec@ietf.org > ;opsawg@ietf.org <
> > Caution-mailto:opsawg@ietf.org >
> > Cc: sacm@ietf.= org < Caution-mailto:sacm@ietf.org >
> > Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability > > Assessment Scenario
> >
> >
> >
> > Reading through the document has made me feel that the Title of t= he draft
> is misleading.
> >
> > Based on the title I was expecting to see the Vulnerability Asses= sment of
> various network scenarios, which will be very useful information for > enterprise and service provider network administrators to put in adequ= ate
> tools to protect those vulnerability.
> >
> >
> >
> > But the document only describes the procedure in authenticating a= end
> user/points and states that you need to compare with the Vulnerability=
> report (almost like a common sense ) without saying how and what.=C2= =A0 I guess I
> had too high the expectation, but a little disappointed of not finding= the
> information I was looking for.
> >
> >
> >
> > Linda Dunbar
> >
> >
> >
> >
> >
> >
> >
> > From: OPSAWG [Caution-mailto:opsawg-bounces@ietf.org <
> > Caution-mailto:opsawg-bounces@ietf.org > ]On Behalf Of Romascanu, Dan > > (Dan)
> > Sent: Thursday, November 19, 2015 7:51 AM
> > To: opsec@iet= f.org < Caution-mailto:opsec@ietf.org > ; opsawg@ietf.org
> > < Caution-mailto:opsawg@ietf.org >
> > Cc: sacm@ietf.= org < Caution-mailto:sacm@ietf.org >
> > Subject: [OPSAWG] Feedback on the SACM Vulnerability Assessment > > Scenario
> >
> >
> >
> > Hi,
> >
> >
> >
> > I am reiterating a request that I made at IETF 94 in the OPSAWG > > meeting, and also sent to the mail lists of opsec and opsawg. The= SACM
> > WG is considering a
> > documentCaution-https://datatracker.= ietf.org/doc/draft-coffin-sacm-vul
> > n-scenario/ <
> > Caution-https://urldefense= .proofpoint.com/v2/url?u=3Dhttps-3A__datatrack
> > er.ietf.org_doc_draft-2Dcoffin-2Dsacm-2Dvuln-
> 2Dscenario_&d=3DBQMFAg&c=3DBF
> >
> pWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBs=
> FA&m=3DD
> > XOABUhWgQkWYGVviFzuEvwgbivmgrBaeyHQ3_W-
> Hyg&s=3DS_CieVlne2x4XqE2cNL0Y_mb0
> > dcPAGm4cN6hKa5k-6Q&e=3D >=C2=A0 that describes the operati= onal practice of
> > vulnerability reports, which we believe is an important use case = in
> > the security assessment life cycle. We are requiring feedback fro= m
> > operators about the scenario describe in this document - does it = make
> > sense? Is it similar with what you do in operational real life? A= re
> > you using similar or different methods for vulnerability assessme= nt in
> > your networks? A quick reading and short feedback would be greatl=
>=C2=A0 y
> >=C2=A0 appreciated.
> >
> >
> >
> > Thanks and Regards,
> >
> >
> >
> > Dan
> >
> >
> >
> >
> > _______________________________________________
> > sacm mailing list
> > sacm@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/sacm > >
>
>
>
> --
>
> Best regards,
> Kathleen
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm

_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm
--001a11c301cc2f12220525eb9bf3-- From nobody Wed Dec 2 09:21:59 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A77E1AC39D; Wed, 2 Dec 2015 09:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXJUCtbPM8xJ; Wed, 2 Dec 2015 09:21:49 -0800 (PST) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id B2E2C1AC3B7; Wed, 2 Dec 2015 09:21:48 -0800 (PST) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1DA886C06F0; Wed, 2 Dec 2015 12:21:48 -0500 (EST) Received: from imshyb01.MITRE.ORG (imshyb01.mitre.org [129.83.29.2]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 0414C6C06E0; Wed, 2 Dec 2015 12:21:48 -0500 (EST) Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 2 Dec 2015 12:21:47 -0500 Received: from na01-by2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1130.7 via Frontend Transport; Wed, 2 Dec 2015 12:21:47 -0500 Received: from BLUPR09MB104.namprd09.prod.outlook.com (10.255.212.24) by BLUPR09MB103.namprd09.prod.outlook.com (10.255.212.23) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 2 Dec 2015 17:21:44 +0000 Received: from BLUPR09MB104.namprd09.prod.outlook.com ([10.255.212.24]) by BLUPR09MB104.namprd09.prod.outlook.com ([10.255.212.24]) with mapi id 15.01.0331.023; Wed, 2 Dec 2015 17:21:45 +0000 From: "Haynes, Dan" To: "Stevens, Josh (Cyber Security)" , "Romascanu, Dan (Dan)" , "opsec@ietf.org" , "opsawg@ietf.org" Thread-Topic: [sacm] Feedback on the SACM Vulnerability Assessment Scenario Thread-Index: AQHRI2NWmQN+3gXiPEufFosvmpEfzp63xh8A Date: Wed, 2 Dec 2015 17:21:44 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA6BE9F6C7@AZ-FFEXMB04.global.avaya.com> <9DDB58C939D0974CAEB9F2A0A0FC15C109DD9470@G2W2529.americas.hpqcorp.net> In-Reply-To: <9DDB58C939D0974CAEB9F2A0A0FC15C109DD9470@G2W2529.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dhaynes@mitre.org; x-originating-ip: [192.160.51.88] x-microsoft-exchange-diagnostics: 1; BLUPR09MB103; 5:tUI0B5SjzNLbGtRxD4midWuBBN1UOo3WEQkAZ/8YZAp3FuDfMm+irh6jYVnA+CR5iUHyDQXgeSDqykivSwZ8VmG3fasZBdUGopf9fOiQ1BtHwDQkdtB1xPwujBbqbljLYz0pZKpy/PC/4wwk3gv28A==; 24:YsstyYbMztYgd8QSsMKKFrZc2zrKsXTgRJOm+0MzVe7K+CB3QBblPH31VZwbNTYof6SNsnORgyQRtts0+GzdczmIPvRzg9rA7kUCxlSw5VU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR09MB103; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:BLUPR09MB103; BCL:0; PCL:0; RULEID:; SRVR:BLUPR09MB103; x-forefront-prvs: 077884B8B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(129404003)(478694002)(164054003)(51444003)(51914003)(189002)(199003)(377454003)(19580405001)(33656002)(15975445007)(2900100001)(99286002)(77096005)(19609705001)(50986999)(92566002)(19580395003)(19300405004)(5008740100001)(5003600100002)(189998001)(106116001)(2501003)(2201001)(1096002)(40100003)(5001960100002)(106356001)(66066001)(5004730100002)(54356999)(76176999)(105586002)(87936001)(16236675004)(19617315012)(2950100001)(97736004)(102836003)(86362001)(81156007)(586003)(74316001)(6116002)(1220700001)(10400500002)(101416001)(122556002)(790700001)(3846002)(76576001)(5002640100001)(5001770100001)(19625215002)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB103; H:BLUPR09MB104.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR09MB1041DE7F32907953E7C61B8A50E0BLUPR09MB104namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2015 17:21:44.9917 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR09MB103 X-OriginatorOrg: mitre.org Archived-At: Cc: "sacm@ietf.org" Subject: Re: [OPSEC] [sacm] Feedback on the SACM Vulnerability Assessment Scenario X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 17:21:56 -0000 --_000_BLUPR09MB1041DE7F32907953E7C61B8A50E0BLUPR09MB104namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Josh, Thanks for the feedback! Comments inline below. Please let me know if I am misunderstanding anythin= g. Thanks, Danny From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Stevens, Josh (Cyber= Security) Sent: Thursday, November 19, 2015 10:37 PM To: Romascanu, Dan (Dan) ; opsec@ietf.org; opsawg@ietf.= org Cc: sacm@ietf.org Subject: Re: [sacm] Feedback on the SACM Vulnerability Assessment Scenario Hi Dan, Agreed, this does help focus the work for this SACM Working Group. After r= eading the draft-coffin-sacm-vuln-scenario, I had some initial feedback fro= m an enterprise defense perspective that might be incorporated. Here are m= y contributions: 1. In the abstract, a vulnerability report is referenced, however it'= s not clear whether an authenticated or unauthenticated vulnerability scan = report (or both) is being referred to. If it can consume both, I would cal= l that out. If what's being referred to is actually a recurring industry st= andard vulnerability report from a vendor, that could also clear up the abs= tract prior to the scope statement where the vulnerability report is define= d. [danny]: the intent is a vulnerability report is that it is published by a = vendor (e.g. security advisory) in some un-prescribed format from which the= relevant data can be extracted from it in some un-prescribed way. That is= , the vulnerability report is not necessarily an industry standard (at leas= t not in the context of this document). We can try to clarify this a bit. 2. In the abstract, there isn't a reference to the endpoint based app= roach that is detailed in the next section. Ideally, instead of "It begins = with an enterprise ingesting a vulnerability report and ends at the point o= f identifying affected endpoints", this could be better summarized as "End= point data is pushed to a central point for comparison with vulnerability c= riteria to enable posture assessment." [danny]: we can try to clarify this. 3. 3.3 A few comments on page 7, paragraph 4 "The attributes could b= e manually entered into a CMDB by a human, This would include any attribute= s that cannot be collected programmatically." I believe the intent here is = to leave fields open for the user to define and leverage as needed, however= I'm not sure we want to advocate manual entry? Ideally, if we can use a co= mmon set of algorithms that can be *manually* adjusted to provide exception= based rules to the overall effort. If we give a user the chance to mangle= data sets, they probably will - I'm in favor of providing additional field= s that can be interfaced with other security API's where automation is the = default workflow choice. Here are some alternatives to manual entry for t= hese three categories: a. Location - for a global organization consider the DNS sub domain i= nfrastructure, for a smaller organization consider SIEM events that stamp t= he closest proximity security infrastructure into an event (zone based), ot= hers might be ARP cache, DNS cache, etc. b. Role - compare with external maps to identify external facing endpo= ints, fingerprint web server packages with a local agent, scrape local proc= ess table to gauge TCP connections to the web server (is it really a web se= rver), etc. c. Criticality - analytics on logins, active sessions, user account c= ounts and net flow will provide a strong enterprise criticality score [danny]: I don't think allowing users to manually enter attributes into the= CMDB necessarily means mangled data sets. For example, an organization co= uld define a schema that defines what the information should look like. Wh= ile it wouldn't likely be standardized, I think that is ok given this type = of information would most likely be organization-specific anyways. What do= others think? With that said, I think this other information and the algorithms to proces= s this information would be useful as well. Does anyone have any thoughts = on this approach? 4. 5.1 If the authenticated or unauthenticated data sets do get merge= d or compared, a decision tree will have to be pre-established - does the a= uthenticated/agent based score override a more recent but unauthenticated = scan finding? [danny]: I don't think I know the answer at this time. It depends on how = the WG ends up defining the assessment logic. Maybe it is something that c= an be configured in the evaluation guidance or maybe authenticated data alw= ays takes precedence over unauthenticated data. With that said, authentica= ted/unauthenticated sounds like it would be a good piece of information to = capture about an attribute in the information model (e.g. similar how we wa= nt to capture if an attribute can be used for designation/identification or= if it is has privacy concerns). Do others have thoughts on authenticated = vs. unauthenticated attributes impacting assessments? 5. For Appendix B: Priority should include cyber intelligence and cam= paign based vulnerability scores. For example, in 2013 - CVE's leveraged by= the "Red October Advanced Cyber Espionage Campaign targeting Diplomatic of= ficials" should be prioritized well above the CVE's used in Conficker , etc= . How can this standard be directed or modified to accept industry standard= Indicator of Compromise (IOC)'s and provide intel driven posture assessmen= ts? [danny]: agree, it probably makes sense to say something about cyber intell= igence information in determining scores and priorities. What do others th= ink? When you say "standard" are you referring to the vulnerability assessment s= cenario draft? SACM in general? Or, something else? 6. Other general comments: o Are mutex string acquisition, DLL fingerprinting, IOC processing and au= to remediation out of the scope for the current Working Group? In addition= , to Vulnerability assessment, these would all go nicely together as part o= f a standard endpoint spec for vendors to communicate through. I've seen e= mail traffic from the group on several of these related topics. [danny]: Remediation is currently out-of-scope for SACM. Regarding mutex s= tring acquisition, DLL fingerprinting, and IOC processing, I think it depen= ds on what is required to collect the data. If we can collect the data by = looking at something on the endpoint (e.g. file hashes, registry keys, etc.= ), I suspect it would be in scope. If we have to do more detailed analysis= (e.g. dynamic malware analysis) that require specialized tools and sandbox= es, I suspect that would be out-of-scope. With that said, the output of th= is more detailed analysis could produce information that would serve as inp= ut into creating guidance to assess endpoints for IOCs at which point I thi= nk it would fall within the scope of SACM. o Section 3. The multiple references to CMDB make some potential assumpti= ons about managed vs. unmanaged endpoints ? It's possible that unmanaged endpoints won't be found in a CMDB, does th= is model account in any way for those? ? An alternative is to consider continuous netflow analytics updating a re= pository / data lake [danny]: We didn't really think of CMDB at that level. We simply used CMDB= to mean a place to store guidance, data, results, etc. Basically, anythin= g that is input or output with respect to an assessment. With that said, a= s SACM begins to define what it needs in a repository (and its data stores)= , these are definitely questions that need to be asked. o Is Rogue Device Detection under consideration as a data point or even a= n Endpoint Type? o Discovering neighboring endpoints o ARP as sensor data o Once a rogue device has been detected, a detailed (or secondary) vulner= ability assessment should begin automatically. [danny]: in previous discussions, there was mention of managed vs. unmanag= ed endpoints, on the network, in the context of BYOD. Managed endpoints ar= e those owned/controlled by the organization whereas unmanaged would be end= points that are not owned nor controlled by the organization (i.e. personal= laptop, etc.). Would your definition of a rogue endpoint align with an un= managed endpoint? Hope this helps. Josh Stevens Hewlett Packard Enterprise From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, November 19, 2015 7:51 AM To: opsec@ietf.org; opsawg@ietf.org Cc: sacm@ietf.org Subject: [sacm] Feedback on the SACM Vulnerability Assessment Scenario Hi, I am reiterating a request that I made at IETF 94 in the OPSAWG meeting, an= d also sent to the mail lists of opsec and opsawg. The SACM WG is consideri= ng a document https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scena= rio/ that describes the operational practice of vulnerability reports, whic= h we believe is an important use case in the security assessment life cycle= . We are requiring feedback from operators about the scenario describe in t= his document - does it make sense? Is it similar with what you do in operat= ional real life? Are you using similar or different methods for vulnerabili= ty assessment in your networks? A quick reading and short feedback would be= greatly appreciated. Thanks and Regards, Dan --_000_BLUPR09MB1041DE7F32907953E7C61B8A50E0BLUPR09MB104namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Josh,

Thanks for the feedback! 

 

Comments inline below.=   Please let me know if I am misunderstanding anything.

 

Thanks,

 

Danny

 

 

From: sacm [mailto:sacm-bounces@ietf.org] = On Behalf Of Stevens, Josh (Cyber Security)
Sent: Thursday, November 19, 2015 10:37 PM
To: Romascanu, Dan (Dan) <dromasca@avaya.com>; opsec@ietf.org;= opsawg@ietf.org
Cc: sacm@ietf.org
Subject: Re: [sacm] Feedback on the SACM Vulnerability Assessment Sc= enario

 

Hi Dan,

 

Agreed, this does help focus the work for this SACM = Working Group.  After reading the draft-coffin-sacm-vuln-scenario, I h= ad some initial feedback from an enterprise defense perspective that might = be incorporated.  Here are my contributions:

 

1.       In the abstract, a vulnerability report is referenc= ed, however it’s not clear whether an authenticated or unauthenticate= d vulnerability scan report (or both) is being referred to.  If it can= consume both, I would call that out. If what’s being referred to is actually a recurring industry standard vulnerability = report from a vendor, that could also clear up the abstract prior to the sc= ope statement where the vulnerability report is defined.

 

[danny]: the intent= is a vulnerability report is that it is published by a vendor (e.g. securi= ty advisory) in some un-prescribed format from which the relevant data can = be extracted from it in some un-prescribed way.  That is, the vulnerability report is not necessarily an industr= y standard (at least not in the context of this document).  We can try= to clarify this a bit.

 

2.       In the abstract, there isn’t a reference to t= he endpoint based approach that is detailed in the next section. Ideally, i= nstead of “It begins with an enterprise ingesting a vulnerability rep= ort and ends at the point of identifying affected endpoints”,  this could be better summarized as “Endpoint= data is pushed to a central point for comparison with vulnerability criter= ia to enable posture assessment.”  

 

[danny]: we can try to clarify this.    &nbs= p;       

 

3.       3.3 A few comments on page 7, paragraph 4  = 220;The attributes cou= ld be manually entered into a CMDB by a human, This would include any attri= butes that cannot be collected programmatically.” I believe the intent here is to leave fields open for the user to define a= nd leverage as needed, however I'm not sure we want to advocate manual entr= y? Ideally, if we can use a common set of algorithms that can be *manually*= adjusted to provide exception based rules to the overall effort.  If we give a user the chance to mangle = data sets, they probably will - I'm in favor of providing additional fields= that can be interfaced with other security API's where automation is the d= efault workflow choice.   Here are some alternatives to manual entry for these three categories:

a.       Location - for a global organization consider the D= NS sub domain infrastructure, for a smaller organization consider SIEM even= ts that stamp the closest proximity security infrastructure into an event (= zone based), others might be ARP cache, DNS cache, etc.

b.      Role - compare with external maps to identify exter= nal facing endpoints, fingerprint web server packages with a local agent, s= crape local process table to gauge TCP connections to the web server (is it= really a web server), etc.

c.       Criticality - analytics on logins, active sessions,= user account counts and net flow will provide a strong enterprise critical= ity score

 

[danny]: I don’t think allowing users to manually enter at= tributes into the CMDB necessarily means mangled data sets.  For examp= le, an organization could define a schema that defines what the information should look like.  While it wouldn’t likel= y be standardized, I think that is ok given this type of information would = most likely be organization-specific anyways.  What do others think?

 

With that said, I think this other information and the algorithm= s to process this information would be useful as well.  Does anyone ha= ve any thoughts on this approach?

 

4.       5.1 If the authenticated or unauthenticated data se= ts do get merged or compared, a decision tree will have to be pre-establish= ed - does the authenticated/agent based score override a more recent  = but unauthenticated scan finding?

 

[danny]:  I don’t think I know the answer at this tim= e.  It depends on how the WG ends up defining the assessment logic.&nb= sp; Maybe it is something that can be configured in the evaluation guidance or maybe authenticated data always takes precedence over unauthen= ticated data.  With that said, authenticated/unauthenticated sounds li= ke it would be a good piece of information to capture about an attribute in= the information model (e.g. similar how we want to capture if an attribute can be used for designation/identif= ication or if it is has privacy concerns).  Do others have thoughts on= authenticated vs. unauthenticated attributes impacting assessments?

 

5.       For Appendix B: Priority should include cyber intel= ligence and campaign based vulnerability scores. For example, in 2013 - CVE= 's leveraged by the "Red October Advanced Cyber Espionage Campaign tar= geting Diplomatic officials" should be prioritized well above the CVE's used in Conficker , etc. How can this sta= ndard be directed or modified to accept industry standard Indicator of Comp= romise (IOC)’s and provide intel driven posture assessments?

 

[danny]: agree, it probably makes sense to say something about c= yber intelligence information in determining scores and priorities.  W= hat do others think? 

 

When you say “standard” are you referring to the vul= nerability assessment scenario draft?  SACM in general?  Or, some= thing else?          &nbs= p;            

 

6.       Other general comments:

 

o   Are mutex string acquisition, DLL fingerprin= ting, IOC processing and auto remediation out of the scope for the current = Working Group?  In addition, to Vulnerability assessment, these would = all go nicely together as part of a standard endpoint spec for vendors to communicate through.  I’ve seen em= ail traffic from the group on several of these related topics.

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

[danny]: Remediation is currently out-of-scope for SACM.  R= egarding mutex string acquisition, DLL fingerprinting, and IOC processing, = I think it depends on what is required to collect the data.  If we can collect the data by looking at something on the = endpoint (e.g. file hashes, registry keys, etc.), I suspect it would be in = scope.  If we have to do more detailed analysis (e.g. dynamic malware = analysis) that require specialized tools and sandboxes, I suspect that would be out-of-scope.  With that said, the= output of this more detailed analysis could produce information that would= serve as input into creating guidance to assess endpoints for IOCs at whic= h point I think it would fall within the scope of SACM. 

 

o   Section 3. The multiple references to CMDB m= ake some potential assumptions about managed vs. unmanaged endpoints

§ § 

[danny]: We didn’t really think of CMDB at that level.&nbs= p; We simply used CMDB to mean a place to store guidance, data, results, et= c.  Basically, anything that is input or output with respect to an assessment.  With that said, as SACM begins to define w= hat it needs in a repository (and its data stores), these are definitely qu= estions that need to be asked.

 

o   Is Rogue Device Detection under consideratio= n as a data point or even an Endpoint Type?

o   Discovering neighboring endpoints=

o   ARP as sensor data 

o   Once a rogue device has been detected, a det= ailed (or secondary) vulnerability assessment should begin automatically.

 

[danny]:  in previous discussions, there was mention of man= aged vs. unmanaged endpoints, on the network, in the context of BYOD. = Managed endpoints are those owned/controlled by the organization whereas unmanaged would be endpoints that are not owned n= or controlled by the organization (i.e. personal laptop, etc.).  Would= your definition of a rogue endpoint align with an unmanaged endpoint? = ;       

 

Hope this helps.

 

Josh Stevens

Hewlett Packard Enterprise

 

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, November 19, 2015 7:51 AM
To: opsec@ietf.org; opsawg@ietf.org
Cc: sacm@ietf.org
Subject: [sacm] Feedback on the SACM Vulnerability Assessment Scenar= io

 

Hi,

 

I am reiterating a request that I made at IETF 94 in= the OPSAWG meeting, and also sent to the mail lists of opsec and opsawg. T= he SACM WG is considering a document https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/ th= at describes the operational practice of vulnerability reports, which we be= lieve is an important use case in the security assessment life cycle. We are requiring feedback from operato= rs about the scenario describe in this document – does it make sense?= Is it similar with what you do in operational real life? Are you using sim= ilar or different methods for vulnerability assessment in your networks? A quick reading and short feedback would be g= reatly appreciated.

 

Thanks and Regards,

 

Dan

 

--_000_BLUPR09MB1041DE7F32907953E7C61B8A50E0BLUPR09MB104namprd_-- From nobody Wed Dec 2 09:32:11 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9221AC442; Wed, 2 Dec 2015 09:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljMM0986G4Om; Wed, 2 Dec 2015 09:29:29 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAE071AC419; Wed, 2 Dec 2015 09:29:28 -0800 (PST) Received: by wmuu63 with SMTP id u63so224683885wmu.0; Wed, 02 Dec 2015 09:29:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FTyNLKLIXnldmvCiQCCYuyggtaWrYXixkW66JGOZI8Q=; b=Ii5H55GqsaYeTKyUP1nTAWz4/8gPsSnQiHfQIKUfXRFtX/smSVWJuEFHpYBEMmzuiy XtVcdJJaK//GTQmAsBExV9yaIU6ZyB811UBhDkvI24I76b9O6CB1gVD8XYyQCq2leNKF yhNcLEM1ubjN5JRWQOSSwyMTmW7ztOK6TyWWlG0l8It38fcTmIOKfAB+PxUF1podbjJa 2Sz68+IQqBjvGSgEMv0k/X1b6V8+vus/cLBdnzypNt3t+NvyzFn/T2hkH5nORK71VY4l Vo+orZo0pjyYnfWbN1g7mveYiOQ8+5eKJwFdVMQVfLbqly+/ANCNwD5baJ3wUwWNUVSq ZYXQ== MIME-Version: 1.0 X-Received: by 10.28.144.139 with SMTP id s133mr46670788wmd.90.1449077367394; Wed, 02 Dec 2015 09:29:27 -0800 (PST) Received: by 10.28.52.130 with HTTP; Wed, 2 Dec 2015 09:29:27 -0800 (PST) In-Reply-To: References: <9F61CC8E6ED7BC4DBA90C13F25D29C006325E379@umechpao0.easf.csd.disa.mil> Date: Wed, 2 Dec 2015 12:29:27 -0500 Message-ID: From: Kathleen Moriarty To: Jessica Fitzgerald-McKay Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Wed, 02 Dec 2015 09:32:09 -0800 Cc: "sacm@ietf.org" , Linda Dunbar , "opsec@ietf.org" , "Wolfkiel, Joseph L CIV DISA ID \(US\)" , "Waltermire, David A." , "opsawg@ietf.org" Subject: Re: [OPSEC] [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 17:29:32 -0000 Hi Dave and Jessica, While I do see the work that went into this draft and think it is helpful, I'd prefer to see it merged with a solution draft, accomplishing both in one draft. It's very unusual for a WG to publish multiple use case case drafts and many don't even publish use case drafts. Is there solution work that could build directly off of this work and be combined into one draft to cover the vulnerability space? Thank you, Kathleen On Wed, Dec 2, 2015 at 10:05 AM, Jessica Fitzgerald-McKay wrote: > Dave, that is a very accurate capture of how the vulnerability assessment > draft can be used to move SACM work forward. The SACM charter is broad; > making progress on solutions drafts that address the goals laid out in the > SACM charter necessitates focusing on a smaller scale scenario to collect > the right data, over the right protocols, that enable security automation. > The vulnerability assessment scenario does just that. It allows us to make > progress on a manageable subset of our goals while keeping an eye to the > bigger security automation landscape. Such a scenario is of great value to > SACM, and is the only way we will be able to make real progress. > > > On Wed, Dec 2, 2015, 9:51 AM Waltermire, David A. > wrote: >> >> >> Kathleen, >> >> There are a number of operational business processes that SACM is working >> to support to include: software asset management, vulnerability management, >> configuration management, and others. Considering the totality of these use >> cases is too big to tackle all at once. The current SACM use cases help to >> inform some of the operations that need to be supported, but they are very >> abstract and don't help as much in making clear what protocols and data >> models are needed. Definitely not the specifics of these specifications. The >> discussion around the vulnerability draft has been about focusing work by >> iterating on concrete operational scenarios (such as that draft) that will >> enable SACM to produce useful solutions more quickly in a way that can build >> on previous iterations. I believe the vulnerability scenario draft is being >> proposed as the first iteration of many. >> >> IMHO, without such a focus, we will continue to stagnate and make >> intermittent progress. This draft has stimulated a good amount of feedback >> and discussion, which makes me think it is accomplishing its intended goal. >> As you mentioned, the next steps should be to clarify the vulnerability >> scenario and align extensible solutions that will address the scenario. In >> doing so this work can provide the foundations for the next scenario in the >> next iteration since many of the operational processes have common >> information needs. >> >> Does this help to clear up how the draft may be used? >> >> Regards, >> Dave >> >> > -----Original Message----- >> > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Kathleen Moriarty >> > Sent: Wednesday, December 02, 2015 9:31 AM >> > To: Wolfkiel, Joseph L CIV DISA ID (US) >> > Cc: Haynes, Dan ; sacm@ietf.org; Linda Dunbar >> > ; Romascanu, Dan (Dan) >> > ; opsec@ietf.org; opsawg@ietf.org >> > Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability >> > Assessment Scenario >> > >> > Hello, >> > >> > I also took the time to read the draft and it currently reads like a >> > scenario or >> > an expanded use case draft, not a solution draft. Does SACM need this >> > or is >> > there plans to merge it with solution work into one draft? I could see >> > the >> > value in the latter, but I don't see how a scenario draft on it's own >> > will help >> > speed up progress for the WG. >> > >> > Thanks, >> > Kathleen >> > >> > On Wed, Dec 2, 2015 at 8:53 AM, Wolfkiel, Joseph L CIV DISA ID (US) >> > wrote: >> > > I think the disappointment may have been headed off if the document >> > > was >> > more explicit, right at the beginning, about what a "vulnerability >> > report" is. I >> > got 2/3 of the way through the document before I understood that >> > "vulnerability report" and "vulnerability definition" are effectively >> > the same >> > construct. A vulnerability report apparently is an announcement that a >> > vulnerability has been discovered and defined to the point where >> > endpoint >> > managers can run assessments on their endpoints to determine if their >> > endpoints have the vulnerability or not. >> > > >> > > This concept is confusing because generally, with existing >> > > vulnerability >> > scanners, new vulnerability "reports" are a subset of updated >> > vulnerability >> > definitions that automatically propagated to the tools and aren't >> > delivered as >> > stand-alone "reports". So a vulnerability "report" would look something >> > like >> > the report at https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015- >> > 8395 (I think). >> > > >> > > Joseph L. Wolfkiel >> > > SCM Engineering Lead >> > > DISA ID52 >> > > Fort Meade DISA Acquisiton Bldg Cube A4A58E >> > > Work: (301) 225-8820 >> > > Gov Cell: (571) 814-8231 >> > > Joseph.L.Wolfkiel.civ@mail.mil >> > > >> > > >> > > >> > > -----Original Message----- >> > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Haynes, Dan >> > > Sent: Wednesday, December 02, 2015 8:36 AM >> > > To: Romascanu, Dan (Dan); Linda Dunbar; opsec@ietf.org; >> > > opsawg@ietf.org >> > > Cc: sacm@ietf.org >> > > Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability >> > > Assessment Scenario >> > > >> > > >> > > Hi Linda, >> > > >> > > >> > > Please let us know if there are any specific questions that we can >> > > answer >> > for you, to help clarify the document, after considering it in the >> > context of >> > the SACM charter as Dan mentioned. >> > > >> > > >> > > >> > > Thanks, >> > > >> > > Danny >> > > >> > > >> > > >> > > From: OPSEC [Caution-mailto:opsec-bounces@ietf.org] On Behalf >> > > OfRomascanu, Dan (Dan) >> > > Sent: Sunday, November 22, 2015 9:48 AM >> > > To: Linda Dunbar ; opsec@ietf.org; >> > > opsawg@ietf.org >> > > Cc: sacm@ietf.org >> > > Subject: Re: [OPSEC] [sacm] [OPSAWG] Feedback on the SACM >> > > Vulnerability Assessment Scenario >> > > >> > > >> > > >> > > Hi Linda, >> > > >> > > >> > > >> > > Thanks for answering the call for review and having a look at this >> > > work. >> > > >> > > >> > > >> > > Concerning your 'little disappointment': This I-D needs to be read in >> > > the >> > context of the current charter of the SACM WG. The WG charter focus for >> > this phase is on the 'endpoint posture' and on the 'enterprise use >> > case'. >> > Maybe this makes things somehow more clear. >> > > >> > > >> > > >> > > Regards, >> > > >> > > >> > > >> > > Dan >> > > >> > > >> > > >> > > >> > > >> > > From: sacm [Caution-mailto:sacm-bounces@ietf.org < >> > > Caution-mailto:sacm-bounces@ietf.org > ]On Behalf Of Linda Dunbar >> > > Sent: Thursday, November 19, 2015 10:36 PM >> > > To: Romascanu, Dan (Dan); opsec@ietf.org < >> > > Caution-mailto:opsec@ietf.org > ;opsawg@ietf.org < >> > > Caution-mailto:opsawg@ietf.org > >> > > Cc: sacm@ietf.org < Caution-mailto:sacm@ietf.org > >> > > Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability >> > > Assessment Scenario >> > > >> > > >> > > >> > > Reading through the document has made me feel that the Title of the >> > > draft >> > is misleading. >> > > >> > > Based on the title I was expecting to see the Vulnerability Assessment >> > > of >> > various network scenarios, which will be very useful information for >> > enterprise and service provider network administrators to put in >> > adequate >> > tools to protect those vulnerability. >> > > >> > > >> > > >> > > But the document only describes the procedure in authenticating a end >> > user/points and states that you need to compare with the Vulnerability >> > report (almost like a common sense ) without saying how and what. I >> > guess I >> > had too high the expectation, but a little disappointed of not finding >> > the >> > information I was looking for. >> > > >> > > >> > > >> > > Linda Dunbar >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > From: OPSAWG [Caution-mailto:opsawg-bounces@ietf.org < >> > > Caution-mailto:opsawg-bounces@ietf.org > ]On Behalf Of Romascanu, Dan >> > > (Dan) >> > > Sent: Thursday, November 19, 2015 7:51 AM >> > > To: opsec@ietf.org < Caution-mailto:opsec@ietf.org > ; opsawg@ietf.org >> > > < Caution-mailto:opsawg@ietf.org > >> > > Cc: sacm@ietf.org < Caution-mailto:sacm@ietf.org > >> > > Subject: [OPSAWG] Feedback on the SACM Vulnerability Assessment >> > > Scenario >> > > >> > > >> > > >> > > Hi, >> > > >> > > >> > > >> > > I am reiterating a request that I made at IETF 94 in the OPSAWG >> > > meeting, and also sent to the mail lists of opsec and opsawg. The SACM >> > > WG is considering a >> > > documentCaution-https://datatracker.ietf.org/doc/draft-coffin-sacm-vul >> > > n-scenario/ < >> > > Caution-https://urldefense.proofpoint.com/v2/url?u=https-3A__datatrack >> > > er.ietf.org_doc_draft-2Dcoffin-2Dsacm-2Dvuln- >> > 2Dscenario_&d=BQMFAg&c=BF >> > > >> > pWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBs >> > FA&m=D >> > > XOABUhWgQkWYGVviFzuEvwgbivmgrBaeyHQ3_W- >> > Hyg&s=S_CieVlne2x4XqE2cNL0Y_mb0 >> > > dcPAGm4cN6hKa5k-6Q&e= > that describes the operational practice of >> > > vulnerability reports, which we believe is an important use case in >> > > the security assessment life cycle. We are requiring feedback from >> > > operators about the scenario describe in this document - does it make >> > > sense? Is it similar with what you do in operational real life? Are >> > > you using similar or different methods for vulnerability assessment in >> > > your networks? A quick reading and short feedback would be greatl >> > y >> > > appreciated. >> > > >> > > >> > > >> > > Thanks and Regards, >> > > >> > > >> > > >> > > Dan >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > sacm mailing list >> > > sacm@ietf.org >> > > https://www.ietf.org/mailman/listinfo/sacm >> > > >> > >> > >> > >> > -- >> > >> > Best regards, >> > Kathleen >> > >> > _______________________________________________ >> > sacm mailing list >> > sacm@ietf.org >> > https://www.ietf.org/mailman/listinfo/sacm >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > -- Best regards, Kathleen From nobody Wed Dec 2 09:41:02 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75EBA1ACD23; Wed, 2 Dec 2015 09:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hAlWpKG2kHw; Wed, 2 Dec 2015 09:40:58 -0800 (PST) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id EE2B31ACD37; Wed, 2 Dec 2015 09:40:57 -0800 (PST) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A7DA36C06EA; Wed, 2 Dec 2015 12:40:57 -0500 (EST) Received: from imshyb02.MITRE.ORG (imshyb02.mitre.org [129.83.29.3]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 8F80E6C03A2; Wed, 2 Dec 2015 12:40:57 -0500 (EST) Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 2 Dec 2015 12:40:57 -0500 Received: from na01-bn1-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1130.7 via Frontend Transport; Wed, 2 Dec 2015 12:40:57 -0500 Received: from BLUPR09MB104.namprd09.prod.outlook.com (10.255.212.24) by BLUPR09MB101.namprd09.prod.outlook.com (10.255.212.140) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 2 Dec 2015 17:40:55 +0000 Received: from BLUPR09MB104.namprd09.prod.outlook.com ([10.255.212.24]) by BLUPR09MB104.namprd09.prod.outlook.com ([10.255.212.24]) with mapi id 15.01.0331.023; Wed, 2 Dec 2015 17:40:55 +0000 From: "Haynes, Dan" To: "Wolfkiel, Joseph L CIV DISA ID (US)" , "Romascanu, Dan (Dan)" , Linda Dunbar , "opsec@ietf.org" , "opsawg@ietf.org" Thread-Topic: [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario Thread-Index: AdEtB9R3zVSGd0+Bu0KNrmLDTqBEuQAH0kQQ Date: Wed, 2 Dec 2015 17:40:55 +0000 Message-ID: References: <9F61CC8E6ED7BC4DBA90C13F25D29C006325E379@umechpao0.easf.csd.disa.mil> In-Reply-To: <9F61CC8E6ED7BC4DBA90C13F25D29C006325E379@umechpao0.easf.csd.disa.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dhaynes@mitre.org; x-originating-ip: [192.160.51.88] x-microsoft-exchange-diagnostics: 1; BLUPR09MB101; 5:d/TeUIQqzZJLiE8LB1d+8+rw3oYjTB95EJFvcBaZvDXOZelslgjkLKIPUQKuBb9TlfRkQXmc1aKkyXbHf7UZuXDSGTDpeT2ee6Z2YPZS8U9JZ+t3YppXGu37iq0tQ8fcKxjEsEqayqs1VqS9N6btYQ==; 24:mnpVrEpOm9NMsDQ2u1FudQiGhqBApSR2VrGpRm6CEWT7ZdG7NfRs/2u9w79lWiQgAPaJ11xDZEidMIA2JY7Ith4iTEZRD/sa5kfFYohQitA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR09MB101; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR09MB101; BCL:0; PCL:0; RULEID:; SRVR:BLUPR09MB101; x-forefront-prvs: 077884B8B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(52604005)(189002)(13464003)(199003)(164054003)(377454003)(586003)(11100500001)(5002640100001)(1096002)(101416001)(99286002)(76576001)(3846002)(5001770100001)(6116002)(97736004)(99936001)(575784001)(10400500002)(19580395003)(189998001)(50986999)(1220700001)(5001960100002)(102836003)(76176999)(92566002)(2900100001)(106356001)(86362001)(66066001)(15975445007)(5004730100002)(81156007)(5003600100002)(87936001)(2501003)(40100003)(33656002)(105586002)(5008740100001)(2950100001)(74316001)(19580405001)(122556002)(54356999)(77096005)(2201001)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB101; H:BLUPR09MB104.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0129_01D12CFE.AD1EB080" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2015 17:40:55.6383 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR09MB101 X-OriginatorOrg: mitre.org Archived-At: Cc: "sacm@ietf.org" Subject: Re: [OPSEC] [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 17:41:00 -0000 ------=_NextPart_000_0129_01D12CFE.AD1EB080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit That's a good point Joe. We will see what we can do to clarify this up front and improve the readability and expectations of the document. Yes, I think a vulnerability report could look like the one you referenced although the scenario document does not prescribe any format/representation/etc. for a vulnerability report. Thanks, Danny -----Original Message----- From: Wolfkiel, Joseph L CIV DISA ID (US) [mailto:joseph.l.wolfkiel.civ@mail.mil] Sent: Wednesday, December 02, 2015 8:53 AM To: Haynes, Dan ; Romascanu, Dan (Dan) ; Linda Dunbar ; opsec@ietf.org; opsawg@ietf.org Cc: sacm@ietf.org Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario I think the disappointment may have been headed off if the document was more explicit, right at the beginning, about what a "vulnerability report" is. I got 2/3 of the way through the document before I understood that "vulnerability report" and "vulnerability definition" are effectively the same construct. A vulnerability report apparently is an announcement that a vulnerability has been discovered and defined to the point where endpoint managers can run assessments on their endpoints to determine if their endpoints have the vulnerability or not. This concept is confusing because generally, with existing vulnerability scanners, new vulnerability "reports" are a subset of updated vulnerability definitions that automatically propagated to the tools and aren't delivered as stand-alone "reports". So a vulnerability "report" would look something like the report at https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-8395 (I think). Joseph L. Wolfkiel SCM Engineering Lead DISA ID52 Fort Meade DISA Acquisiton Bldg Cube A4A58E Work: (301) 225-8820 Gov Cell: (571) 814-8231 Joseph.L.Wolfkiel.civ@mail.mil -----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Haynes, Dan Sent: Wednesday, December 02, 2015 8:36 AM To: Romascanu, Dan (Dan); Linda Dunbar; opsec@ietf.org; opsawg@ietf.org Cc: sacm@ietf.org Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario Hi Linda, Please let us know if there are any specific questions that we can answer for you, to help clarify the document, after considering it in the context of the SACM charter as Dan mentioned. Thanks, Danny From: OPSEC [Caution-mailto:opsec-bounces@ietf.org] On Behalf OfRomascanu, Dan (Dan) Sent: Sunday, November 22, 2015 9:48 AM To: Linda Dunbar ; opsec@ietf.org; opsawg@ietf.org Cc: sacm@ietf.org Subject: Re: [OPSEC] [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario Hi Linda, Thanks for answering the call for review and having a look at this work. Concerning your 'little disappointment': This I-D needs to be read in the context of the current charter of the SACM WG. The WG charter focus for this phase is on the 'endpoint posture' and on the 'enterprise use case'. Maybe this makes things somehow more clear. Regards, Dan From: sacm [Caution-mailto:sacm-bounces@ietf.org < Caution-mailto:sacm-bounces@ietf.org > ]On Behalf Of Linda Dunbar Sent: Thursday, November 19, 2015 10:36 PM To: Romascanu, Dan (Dan); opsec@ietf.org < Caution-mailto:opsec@ietf.org > ;opsawg@ietf.org < Caution-mailto:opsawg@ietf.org > Cc: sacm@ietf.org < Caution-mailto:sacm@ietf.org > Subject: Re: [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario Reading through the document has made me feel that the Title of the draft is misleading. Based on the title I was expecting to see the Vulnerability Assessment of various network scenarios, which will be very useful information for enterprise and service provider network administrators to put in adequate tools to protect those vulnerability. But the document only describes the procedure in authenticating a end user/points and states that you need to compare with the Vulnerability report (almost like a common sense ) without saying how and what. I guess I had too high the expectation, but a little disappointed of not finding the information I was looking for. Linda Dunbar From: OPSAWG [Caution-mailto:opsawg-bounces@ietf.org < Caution-mailto:opsawg-bounces@ietf.org > ]On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, November 19, 2015 7:51 AM To: opsec@ietf.org < Caution-mailto:opsec@ietf.org > ; opsawg@ietf.org < Caution-mailto:opsawg@ietf.org > Cc: sacm@ietf.org < Caution-mailto:sacm@ietf.org > Subject: [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario Hi, I am reiterating a request that I made at IETF 94 in the OPSAWG meeting, and also sent to the mail lists of opsec and opsawg. The SACM WG is considering a documentCaution-https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scen ario/ < Caution-https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.iet f.org_doc_draft-2Dcoffin-2Dsacm-2Dvuln-2Dscenario_&d=BQMFAg&c=BFpWQw8bsuKpl1 SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=DXOABUhWgQkWYGVviFz uEvwgbivmgrBaeyHQ3_W-Hyg&s=S_CieVlne2x4XqE2cNL0Y_mb0dcPAGm4cN6hKa5k-6Q&e= > that describes the operational practice of vulnerability reports, which we believe is an important use case in the security assessment life cycle. We are requiring feedback from operators about the scenario describe in this document - does it make sense? Is it similar with what you do in operational real life? Are you using similar or different methods for vulnerability assessment in your networks? A quick reading and short feedback would be greatly appreciated. Thanks and Regards, Dan ------=_NextPart_000_0129_01D12CFE.AD1EB080 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVDzCCBQMw ggProAMCAQICCiXN7WEAAQAALkowDQYJKoZIhvcNAQELBQAwUDETMBEGCgmSJomT8ixkARkWA09S RzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBD QS0yMB4XDTE1MDMwMjE0MTAwMFoXDTE4MDMwMTE0MTAwMFowTDELMAkGA1UEBhMCVVMxDjAMBgNV BAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxHDAaBgNVBAMTE0hheW5lcy5EYW5pZWwuMzE4NTMw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHL7mKMKCE9V8h6nKAQN5RMV+84g9dsIWH k8Yi2WX8zOrfyfsVUT+B9rExhmHBb9Z133yLwa51N6atldujJiERaIKgPoB6fQilvZOvvBa7m6fy d5kp7ArdCiaFSrwlHtZhfk+87uPKiPl/yjoef7kfmID7c1hve2AAQqjmhV6RGblTQXmG01vY3VB1 FOEQVVlQ7g4rZimxkWR+mSoRKeUsUwfJ0/W8NYfg5sGAkPn5tz5jS/+M90yXbTfXhcgJmsyIuCQt Zh8xLAMPvUZiAtNxT88uYJluLrcauz+rbTCjIK3mUQ2bJvpCI9np7CkNH2ROkhfRFq79KMmASBxf Tv2hAgMBAAGjggHhMIIB3TAoBgNVHSUEITAfBggrBgEFBQcDBAYJKwYBBAFzAgEHBggrBgEFBQcD AjAdBgNVHQ4EFgQUuHZLEx54an49/MHQKi0MEq/nMo8wDgYDVR0PAQH/BAQDAgbAMBwGA1UdEQQV MBOBEWRoYXluZXNAbWl0cmUub3JnMB8GA1UdIwQYMBaAFAzGa+4CRrXZj9ujzOy8PuEFvaUnMEwG A1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24l MjBQRSUyMENBLTIoMSkuY3JsMH8GCCsGAQUFBwEBBHMwcTBHBggrBgEFBQcwAoY7aHR0cDovL3Br aS5taXRyZS5vcmcvTUlUUkUlMjBDb3Jwb3JhdGlvbiUyMFBFJTIwQ0EtMigxKS5jcnQwJgYIKwYB BQUHMAGGGmh0dHA6Ly9vY3NwLm1pdHJlLm9yZy9vY3NwMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQB gjcVCIOurCOGjpZXgY2JPYKkqxKFvq4BgTaBl7QQhZn/CgIBZAIBCzA0BgkrBgEEAYI3FQoEJzAl MAoGCCsGAQUFBwMEMAsGCSsGAQQBcwIBBzAKBggrBgEFBQcDAjANBgkqhkiG9w0BAQsFAAOCAQEA j5xb2BBWSdWE7uBfRe2uT6KF+7vBFdNXQO49Mu6/s05Ownf9NmeCK32hsBHgVUeYZufxobeXr9BV YXbah3zwWCHXHjNpi3Kp9syIwXVT+WV+Zso58TCT0sRyuO5ux2gl+mxlf54QmsSn1RzehMkjR2ij H0PpDKWUddLSjpvwTM9kCyuB7kYNIiPDcd8zP251e/ki1ZyHQU9nm/sBy422fg4ierpnEgBYaogk xrDn5UfRHS2hKJamuvWxyt/ibGhAdp8bL366dX6RGbpIz4r3IfrGt+PlRuT4xQRpWKuVxVn1TO9D ygh/wNmveWjwLXP2tbmXDdt3fXIfzuSyrG4eSzCCBS0wggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ +1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBD QS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgyMlowKTEnMCUGA1UEAxMeTUlUUkUgQ29y cG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8h R0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b68lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QD gOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXsy8QnOHal1bKf0Pa9KXib58qUuwfaZSCT W5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVMhYLWy3KRuU/gue0bVEi+qdg+hENh1NSN XpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHHzD6cXKJozuFXriswlE8rdna7VaxyZrfg C0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjai WUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09 oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3CmzASlOwtTFiLYgpPW/MSmgYOt9JrwHAz k97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX/MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9 csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEA AaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPg KTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8 /uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBsL+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhl v0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI8HGPjUBdLADgOmG99uffm5uarSkjtIX/ /Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8XH6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZ vYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKvnDH2yB66zTwfaDpnjILnrC2O7ANRVZc0 KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMibTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL 55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vhkSg65FFCMhaSkn7vY2Il+R8HouWJN8wT audeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMzDw5eFhT/J6QrABCxfgLkVFHurMcQD4Jk mXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Ybvxg+elFtsad+Ix8owW372xynIADh9q1b Hm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED393Jb0YbzrcElFv6ZDCCBWQwggNMoAMC AQICCmELE3AAAAAAAAgwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRp b24gUEUgUm9vdCBDQS0xMB4XDTE0MDkyMzE0MTEwOVoXDTIwMDkyMzE0MjEwOVowUDETMBEGCgmS JomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jw b3JhdGlvbiBQRSBDQS0yMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkLB9183FVdnr 8mkt4KxZXxW9U9ECIji56Y3cLKfzWAr/S4LQolFf9YnVceZ/N4t6zIXjrLEKB3R97qa1oN8VA1Z+ eDMxVqIcdPuc3JFw6jlMT5mbMN7uLgKn5J3vJJLJqPlZMtXKW/o+YXG0pib/a0jji0QuEZEOzD8n uuHCLT/2MS6PGNekvriXvZtysRoOPylIWDUs08sUR7hLaMj3LFzmTRkpAm2oaEFU+04ZKJmAjxrG tWR2eOvUPCvQzVRPtCZ7Gn6vRa8wrXrzvtVoCk4afTnrR4q0uAFhvyPvYHspTAUYUy24ztl0IIdh uLAtWdq44Vs8rqrGEr/V9AGFnQIDAQABo4IBZTCCAWEwEgYJKwYBBAGCNxUBBAUCAwEAATAjBgkr BgEEAYI3FQIEFgQUrdlLujsvzg78DPvalzPvigG4mU0wHQYDVR0OBBYEFAzGa+4CRrXZj9ujzOy8 PuEFvaUnMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8E BTADAQH/MB8GA1UdIwQYMBaAFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMFAGA1UdHwRJMEcwRaBDoEGG P2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMFJvb3QlMjBD QS0xLmNybDBbBggrBgEFBQcBAQRPME0wSwYIKwYBBQUHMAKGP2h0dHA6Ly9wa2kubWl0cmUub3Jn L01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMFJvb3QlMjBDQS0xLmNydDANBgkqhkiG9w0BAQsF AAOCAgEAPTpof/vEguiXZxJBVxvkhQ46YzuylPtgZEOEYiiwgUpstKi+3w22ZXAljQj/b9j2tIPm FFDaN1VafLdtoBZG6HGOD8OMmBnfAfJ/yHlS3NxQQh+ayXE6UM2V8WKEpowNTKoPjJwsRdZHtUYy MVAfnjvS9A95t2ChOAcGF1Ees6u1RvT9fVTg9SJHZN44zi5DDRzQq6nE2obbwV/8SyidvZ8lezeL qELyR72CzKwbwiyyBjXEPyE+Sp0lYERxlhCPOSogTIz5nmnvrjR9fx4U9iIheEevZkt/7xzfcVoh kQcOJDt4VzExDejGjRi8kovDCtMa6Cd7ek81R3YOLNs0/m7dhw98wpIuCSYioc6WyEGr+ROdrxu1 //+vAKyl1NgaAIK0utzRNvbpGPico3xoQ8nTxBh8UiAm/0PB6MILiSblsmHWLFzMatouopuDxYme D19GiNhBxYpt/o24mNa7DG53g1IPBwdyhM4N3un7d72joOt8fQ4HM86B334QUoj52DqluBiJlPwx RJQwDt0rFXKxusyvH9A4ZV5irsrNL6eKnS6wHiwIYgZl/IZkuRuP2uG1jcSch0PyIpyAK1QJkcMN vdLMfsilcgI7OEgZGnzL2pIJ6Z6+EEnxpeBxlwG9g8ZsZwHirMNyUkqIMILyt9RN6m13M6d3GJvI aoxJhEowggVrMIIEU6ADAgECAgolze8WAAEAAC5LMA0GCSqGSIb3DQEBCwUAMFAxEzARBgoJkiaJ k/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29ycG9y YXRpb24gUEUgQ0EtMjAeFw0xNTAzMDIxNDEwMDBaFw0xODAzMDExNDEwMDBaMEwxCzAJBgNVBAYT AlVTMQ4wDAYDVQQKEwVNSVRSRTEPMA0GA1UECxMGUGVvcGxlMRwwGgYDVQQDExNIYXluZXMuRGFu aWVsLjMxODUzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArjwt/Q+ZHYLra5oUBc4J 6cM7WafX67q+0OxQEnr8kwKRPL/AgW8cji7w/IZE9zXtPboc2HjidnbAkCgbFr2hO/ff9UUjUVJK UMHVc4nmAQY7fWsQqbBytSm1eWWvbbKu120FsGixncVutYgtQm9Z+gJlUkqnYPiwKjP4odrrfh1e 75M3ma9j919DjyRjo7cd6kJooaljhv9N2VCQ22vHkauoqPp+sltIXk8QPMR0y70ZDS7lGoUSkf2u vo5bO+f8HH/iBkWES2cam2H2dpBa55nW423hdm214+sgPvp1RQ2DEmU7n3b+CcQKtTGd1FWFNTMg kQigmHrQEwvgIHDfnwIDAQABo4ICSTCCAkUwEwYDVR0lBAwwCgYIKwYBBQUHAwQwgZQGCSqGSIb3 DQEJDwSBhjCBgzAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqG SIb3DQMHMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAS0wCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQB GTALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEFMB0GA1UdDgQWBBQWPtrn5gqag79f5ZMgQZ6vHgkO EDAOBgNVHQ8BAf8EBAMCBSAwHAYDVR0RBBUwE4ERZGhheW5lc0BtaXRyZS5vcmcwHwYDVR0jBBgw FoAUDMZr7gJGtdmP26PM7Lw+4QW9pScwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL3BraS5taXRy ZS5vcmcvTUlUUkUlMjBDb3Jwb3JhdGlvbiUyMFBFJTIwQ0EtMigxKS5jcmwwfwYIKwYBBQUHAQEE czBxMEcGCCsGAQUFBzAChjtodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9u JTIwUEUlMjBDQS0yKDEpLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AubWl0cmUub3JnL29j c3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg66sI4aOlleBjYk9gqSrEoW+rgGBNtGBZ4aY kz4CAWQCARMwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEA Nkvt0FpOOMhGE9Yk9mhRXF8NMQq8yi8N2G4DvgW9tZIXKO27No3aKOyBs7aX8FK3rAXvVV4XeqrR LX1c44tL9YTPEnbwvnDSmBMkLmmNVxi+f2NzAmOPz5wLTxc88TPiFCXufQtrMX73Xtn2HL1ctiaY MKleK3+dKR52+IBO6eYHLsUN8aQ+xnClKY/Et0AmaPSCimvvmQjWvmTdd6zIS9JoMPUVkfA31Eod gQ0QZf4WBANRx2nN60Xx5r13Q/j3kHnMAD4L2cxoYmGbulTI30mCKobY0F4eOcihzmC4YK1duCZL UP26fSCw19CFhq4nnZ0kDgp4OVN8H+5NES2ORTGCA1wwggNYAgEBMF4wUDETMBEGCgmSJomT8ixk ARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlv biBQRSBDQS0yAgolze1hAAEAAC5KMAkGBSsOAwIaBQCgggHTMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTIwMjE3NDA1MFowIwYJKoZIhvcNAQkEMRYEFI8/pTGb l1phXdyD/z8b8BAWJtp9MG0GCSsGAQQBgjcQBDFgMF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEV MBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0y Agolze8WAAEAAC5LMG8GCyqGSIb3DQEJEAILMWCgXjBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUw EwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTIC CiXN7xYAAQAALkswgZMGCSqGSIb3DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEW MAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcN AQEBBQAEggEATDJlS7ibrQVmziF1oqaoOS0SHOkFOeOooQScJJ0HM/Rd+PECMciFma9o3CtX6/OA uNLAYogQQ9TEm8QSmbvmRbordUmSd/KnsQQJVg2GZxcGkuYA7wypvcrmy0wBaSItJP5kwAuJ3r9/ Kw16673MA0iLvrtaTDO+3+ww1NMY/kLSGKVldG4wKzpLVEPfcUHoQOZtR64aAASasfw/Wm/1/pOq vwtejV5C+YBKkYFD/BOM4BYWcVSgyipC0NEn8YgER2a+fF0cWM1X9IWM4L55ql8ctsuI3chM0tXP aqfoKHUwbZf1m/pCectXPa7dlWGVZKO4YZZN/H0zdB5GgKIO3wAAAAAAAA== ------=_NextPart_000_0129_01D12CFE.AD1EB080-- From nobody Thu Dec 3 23:09:55 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2EF1A0204; Thu, 3 Dec 2015 15:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.674 X-Spam-Level: X-Spam-Status: No, score=0.674 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZawiCpdh3Bc0; Thu, 3 Dec 2015 15:09:48 -0800 (PST) Received: from sc9-admin1.yaanatech.net (63-128-177-34-static.dzbja.com [63.128.177.34]) by ietfa.amsl.com (Postfix) with ESMTP id 07B961A0370; Thu, 3 Dec 2015 15:09:46 -0800 (PST) Received: from extmail1.yaanatech.com (extmail1.yaanatech.com [63.128.177.51]) by sc9-admin1.yaanatech.net (Postfix) with ESMTP id 97D7136; Thu, 3 Dec 2015 23:09:46 +0000 (UTC) Received: from [192.168.1.51] (pool-70-106-195-113.clppva.fios.verizon.net [70.106.195.113]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by extmail1.yaanatech.com (Postfix) with ESMTP id B309C5808E; Thu, 3 Dec 2015 23:08:57 +0000 (UTC) References: <9F61CC8E6ED7BC4DBA90C13F25D29C006325E379@umechpao0.easf.csd.disa.mil> To: Kathleen Moriarty , Jessica Fitzgerald-McKay From: Tony Rutkowski Organization: Yaana Technologies Message-ID: <5660CBB8.1020905@yaanatech.com> Date: Thu, 3 Dec 2015 18:09:44 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Thu, 03 Dec 2015 23:09:54 -0800 Cc: "sacm@ietf.org" , Linda Dunbar , "opsec@ietf.org" , "Wolfkiel, Joseph L CIV DISA ID \(US\)" , "Waltermire, David A." , "opsawg@ietf.org" Subject: Re: [OPSEC] [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tony@yaanatech.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 23:09:48 -0000 Hi Kathleen, Given the broad scope of the charter and the fact that a set of authors here have produced a product that that everyone agrees is useful, it seems needlessly inflexible to insist that the two be bundled together. Jess' objective seems spot on. > The vulnerability assessment scenario does just that. It allows us to m= ake > progress on a manageable subset of our goals while keeping an eye to th= e > bigger security automation landscape. --tony On 2015-12-02 12:29 PM, Kathleen Moriarty wrote: > Hi Dave and Jessica, > > While I do see the work that went into this draft and think it is > helpful, I'd prefer to see it merged with a solution draft, > accomplishing both in one draft. It's very unusual for a WG to > publish multiple use case case drafts and many don't even publish use > case drafts. > > Is there solution work that could build directly off of this work and > be combined into one draft to cover the vulnerability space? > > Thank you, > Kathleen