From nobody Sun Nov 1 19:49:06 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 09E0B1ACE1B for ; Sun, 1 Nov 2015 19:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 kVIqeM8jD5Md for ; Sun, 1 Nov 2015 19:49:02 -0800 (PST) Received: from st13p11im-asmtp004.me.com (st13p11im-asmtp004.me.com [17.164.40.219]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFCA1ACE15 for ; Sun, 1 Nov 2015 19:49:02 -0800 (PST) Received: from dhcp-25-118.meeting.ietf94.jp (dhcp-25-118.meeting.ietf94.jp [133.93.25.118]) by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NX600IV159GOL40@st13p11im-asmtp004.me.com> for opsec@ietf.org; Mon, 02 Nov 2015 03:48:55 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-11-01_12:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510090000 definitions=main-1511020069 Content-type: multipart/alternative; boundary="Apple-Mail=_C9FBB906-08B5-432A-A604-23AFF8C37A2F" MIME-version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Gunter Van De Velde In-reply-to: Date: Mon, 02 Nov 2015 12:48:51 +0900 Message-id: References: To: "opsec@ietf.org" X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: Re: [OPSEC] OPSEC IETF 94 - Call for Agenda Items 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: Mon, 02 Nov 2015 03:49:04 -0000 --Apple-Mail=_C9FBB906-08B5-432A-A604-23AFF8C37A2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, Please be aware that we decided to cancel the IETF94 OPSEC WG slot = original planned Friday 6 November. Motivation is lack of sufficient agenda items. See you all at IETF95. Brgds, Gunter & Eric > On 20 Oct 2015, at 18:49, VAN DE VELDE, Gunter (Gunter) = wrote: >=20 > Dear All, >=20 > If you have a draft you would like to discuss during IETF 94, please = send your request for agenda time to the opsec chairs. Please include in = the request, the title and file name of the draft, the speaker's name, = and how much time you would need. We have 2.5 hours allocated to OPSEC = session. >=20 > We will prioritise drafts that are WG items, drafts that have been = actively discussed on the list, and other individual submissions in that = order. >=20 > Regards, > Gunter, Eric > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec --Apple-Mail=_C9FBB906-08B5-432A-A604-23AFF8C37A2F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi All,

Please be aware that we decided to cancel the IETF94 OPSEC WG slot original planned Friday 6 November.
Motivation is lack of sufficient agenda items. See you all at IETF95.

Brgds,
Gunter & Eric

On 20 Oct 2015, at 18:49, VAN DE VELDE, Gunter (Gunter) <gunter.van_de_velde@alcatel-lucent.com> wrote:

Dear All,

If you have a draft you would like to discuss during IETF 94, please send your request for agenda time to the opsec chairs. Please include in the request, the title and file name of the draft, the speaker's name, and how much time you would need. We have 2.5 hours allocated to OPSEC session.

We will prioritise drafts that are WG items, drafts that have been actively discussed on the list, and other individual submissions in that order.

Regards,
Gunter, Eric
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

--Apple-Mail=_C9FBB906-08B5-432A-A604-23AFF8C37A2F-- From nobody Thu Nov 5 17:10: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 601191A8BB2; Thu, 5 Nov 2015 17:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 j---do4IpjJw; Thu, 5 Nov 2015 17:09:54 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4D81A8AAA; Thu, 5 Nov 2015 17:09:54 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2C0BgA3Q8ZV/yYyC4dbGQGCNCEsVGoFqW4Gg0qPQioJggSFeQKBJjgUAQEBAQEBAYEKhCUBAQMSG0wSAQwJFVYmAQQBDQ0MDogMAQysaaA6AQEBAQEFAQEBAQEBHIYfigoxgx+BFAWVCwGFAYlwhmqRBBEGD4N9gjeBBAEBAQ X-IPAS-Result: A2C0BgA3Q8ZV/yYyC4dbGQGCNCEsVGoFqW4Gg0qPQioJggSFeQKBJjgUAQEBAQEBAYEKhCUBAQMSG0wSAQwJFVYmAQQBDQ0MDogMAQysaaA6AQEBAQEFAQEBAQEBHIYfigoxgx+BFAWVCwGFAYlwhmqRBBEGD4N9gjeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208,217";a="150070018" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 05 Nov 2015 20:09:53 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 05 Nov 2015 20:09:52 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Fri, 6 Nov 2015 02:09:51 +0100 From: "Romascanu, Dan (Dan)" To: "opsec@ietf.org" , "opsawg@ietf.org" Thread-Topic: SACM Vulnerability assessment scenario Thread-Index: AdEYL9WBvXS9CXrQRpiQvzpjTMwSWQ== Date: Fri, 6 Nov 2015 01:09:50 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BE85BAA@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA6BE85BAAAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "Haynes, Dan" , Adam Montville Subject: [OPSEC] 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: Fri, 06 Nov 2015 01:09:56 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BE85BAAAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Following my short info in the OPSAWG/OPSAREA meeting yesterday - the I-D t= hat I was mentioning is http://datatracker.ietf.org/doc/draft-coffin-sacm-v= uln-scenario/. It describes the vulnerability assessment scenario and the c= oncept of vulnerability reports which the SACM WG is considering as useful = to baseline requirements and use as a reference use case for the work in th= e current (first) phase of the SACM work. We would appreciate one or even more review from the OPSEC and OPSAWG commu= nity. We are interested especially whether the use case and process describ= ed in this I-D fits the way vulnerability assessment and reports are being = seen by operators in their daily activities. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA6BE85BAAAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Following my short info in the OPSAWG/OPSAREA meetin= g yesterday – the I-D that I was mentioning is http://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/. It = describes the vulnerability assessment scenario and the concept of vulnerab= ility reports which the SACM WG is considering as useful to baseline requirements and use as a reference use = case for the work in the current (first) phase of the SACM work.

 

We would appreciate one or even more review from the= OPSEC and OPSAWG community. We are interested especially whether the use c= ase and process described in this I-D fits the way vulnerability assessment= and reports are being seen by operators in their daily activities.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA6BE85BAAAZFFEXMB04globa_-- From nobody Thu Nov 19 05:51:56 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 94D801B29C0; Thu, 19 Nov 2015 05:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.484 X-Spam-Level: X-Spam-Status: No, score=-7.484 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585] 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 mAehLqOy1SLu; Thu, 19 Nov 2015 05:51:26 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18EC1AD4A1; Thu, 19 Nov 2015 05:51:25 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AeAwBBP8ZV/xUHmMZbGQGCNCEsVG+pbgaTNgmCBIV5AoEmOBQBAQEBAQEBgQqEJQEBAxIbTBIBDAkVViYBBAENDREJiAwBDKxsoD4BAQEBAQEBAwEBAQEBAQEBARUEhh+JaQEBHy0Egx+BFAWVCwFthBSJKocwjR6DZhcPg32BfTqBBAEBAQ X-IPAS-Result: A2AeAwBBP8ZV/xUHmMZbGQGCNCEsVG+pbgaTNgmCBIV5AoEmOBQBAQEBAQEBgQqEJQEBAxIbTBIBDAkVViYBBAENDREJiAwBDKxsoD4BAQEBAQEBAwEBAQEBAQEBARUEhh+JaQEBHy0Egx+BFAWVCwFthBSJKocwjR6DZhcPg32BfTqBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208,217";a="129370299" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Nov 2015 08:51:22 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 19 Nov 2015 08:51:21 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Thu, 19 Nov 2015 08:51:20 -0500 From: "Romascanu, Dan (Dan)" To: "opsec@ietf.org" , "opsawg@ietf.org" Thread-Topic: Feedback on the SACM Vulnerability Assessment Scenario Thread-Index: AdEi0VjikxFfTlxYT32xzoHq98yx8w== Date: Thu, 19 Nov 2015 13:51:20 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BE9F6C7@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA6BE9F6C7AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "sacm@ietf.org" Subject: [OPSEC] 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: Thu, 19 Nov 2015 13:51:30 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BE9F6C7AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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_9904FB1B0159DA42B0B887B7FA8119CA6BE9F6C7AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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_9904FB1B0159DA42B0B887B7FA8119CA6BE9F6C7AZFFEXMB04globa_-- From nobody Thu Nov 19 15:36: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 99A601B3516; Thu, 19 Nov 2015 12:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 3CRn2C19IclA; Thu, 19 Nov 2015 12:36:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E41931B3514; Thu, 19 Nov 2015 12:36:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAO45380; Thu, 19 Nov 2015 20:36:23 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 19 Nov 2015 20:36:22 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Thu, 19 Nov 2015 12:36:20 -0800 From: Linda Dunbar To: "Romascanu, Dan (Dan)" , "opsec@ietf.org" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario Thread-Index: AdEi0VjikxFfTlxYT32xzoHq98yx8wANziBQ Date: Thu, 19 Nov 2015 20:36:19 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657DA3D4B@dfweml701-chm> References: <9904FB1B0159DA42B0B887B7FA8119CA6BE9F6C7@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BE9F6C7@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.213] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657DA3D4Bdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.564E32C7.0286, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6f2a590b28fdc288726fb11171ac287a Archived-At: X-Mailman-Approved-At: Thu, 19 Nov 2015 15:36:57 -0800 Cc: "sacm@ietf.org" Subject: Re: [OPSEC] [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: Thu, 19 Nov 2015 20:36:29 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657DA3D4Bdfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 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_4A95BA014132FF49AE685FAB4B9F17F657DA3D4Bdfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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/ 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_4A95BA014132FF49AE685FAB4B9F17F657DA3D4Bdfweml701chm_-- From joshua.stevens@hpe.com Thu Nov 19 19:39:52 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 6BFAC1A89C4; Thu, 19 Nov 2015 19:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 vS3T3UuUojX7; Thu, 19 Nov 2015 19:39:47 -0800 (PST) Received: from g2t2354.austin.hp.com (g2t2354.austin.hp.com [15.217.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236091A8A3D; Thu, 19 Nov 2015 19:39:41 -0800 (PST) Received: from G2W4316.americas.hpqcorp.net (g2w4316.austin.hp.com [16.197.9.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g2t2354.austin.hp.com (Postfix) with ESMTPS id 8228E79; Fri, 20 Nov 2015 03:39:40 +0000 (UTC) Received: from G2W4313.americas.hpqcorp.net (16.197.24.255) by G2W4316.americas.hpqcorp.net (16.197.9.73) with Microsoft SMTP Server (TLS) id 14.3.169.1; Fri, 20 Nov 2015 03:37:30 +0000 Received: from G2W2529.americas.hpqcorp.net ([169.254.1.101]) by G2W4313.americas.hpqcorp.net ([16.197.24.255]) with mapi id 14.03.0169.001; Fri, 20 Nov 2015 03:37:30 +0000 From: "Stevens, Josh (Cyber Security)" To: "Romascanu, Dan (Dan)" , "opsec@ietf.org" , "opsawg@ietf.org" Thread-Topic: [sacm] Feedback on the SACM Vulnerability Assessment Scenario Thread-Index: AdEi0VjikxFfTlxYT32xzoHq98yx8wAN8l+Q Date: Fri, 20 Nov 2015 03:37:29 +0000 Message-ID: <9DDB58C939D0974CAEB9F2A0A0FC15C109DD9470@G2W2529.americas.hpqcorp.net> References: <9904FB1B0159DA42B0B887B7FA8119CA6BE9F6C7@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BE9F6C7@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.193.232.24] Content-Type: multipart/alternative; boundary="_000_9DDB58C939D0974CAEB9F2A0A0FC15C109DD9470G2W2529americas_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 20 Nov 2015 01:16:07 -0800 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: Fri, 20 Nov 2015 03:44:33 -0000 --_000_9DDB58C939D0974CAEB9F2A0A0FC15C109DD9470G2W2529americas_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. 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." 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 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? 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? 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. 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 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. 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_9DDB58C939D0974CAEB9F2A0A0FC15C109DD9470G2W2529americas_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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.

 

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

 

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

 

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?

 

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?

 

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.

 

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

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

 

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_9DDB58C939D0974CAEB9F2A0A0FC15C109DD9470G2W2529americas_-- From nobody Sun Nov 22 06:48: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 B7A4B1A8981; Sun, 22 Nov 2015 06:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.095 X-Spam-Level: X-Spam-Status: No, score=-4.095 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585] 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 bJ_hC93N9ELs; Sun, 22 Nov 2015 06:48:11 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958871A8993; Sun, 22 Nov 2015 06:48:11 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AWAgBA1VFW/xUHmMZeGQEBAQEPAQEBAYI+ISxTbwaEI4EPtz+CGgENgWUghW8CgSI4FAEBAQEBAQGBCoQ0AQEBAQMSCxBMEAIBCA0EBAEBCx0HMhQJCAIEAQ0FCBEJiAwBDKNxmiYBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZWhHyEOwEBHi0JgxOBFQWWUAGFI4loh1kMjxmDch8BAUKBYCyBeHIBAYNoOgGBBgEBAQ X-IPAS-Result: A2AWAgBA1VFW/xUHmMZeGQEBAQEPAQEBAYI+ISxTbwaEI4EPtz+CGgENgWUghW8CgSI4FAEBAQEBAQGBCoQ0AQEBAQMSCxBMEAIBCA0EBAEBCx0HMhQJCAIEAQ0FCBEJiAwBDKNxmiYBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZWhHyEOwEBHi0JgxOBFQWWUAGFI4loh1kMjxmDch8BAUKBYCyBeHIBAYNoOgGBBgEBAQ X-IronPort-AV: E=Sophos;i="5.20,332,1444708800"; d="scan'208,217";a="147177792" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Nov 2015 09:48:10 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 22 Nov 2015 09:48:09 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Sun, 22 Nov 2015 09:48:08 -0500 From: "Romascanu, Dan (Dan)" To: Linda Dunbar , "opsec@ietf.org" , "opsawg@ietf.org" Thread-Topic: [sacm] [OPSAWG] Feedback on the SACM Vulnerability Assessment Scenario Thread-Index: AQHRIwn8vCnc3ktnmEWoJx2rPsfBeZ6n9pzA Date: Sun, 22 Nov 2015 14:48:07 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BEA384A@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA6BE9F6C7@AZ-FFEXMB04.global.avaya.com> <4A95BA014132FF49AE685FAB4B9F17F657DA3D4B@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657DA3D4B@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA6BEA384AAZFFEXMB04globa_" MIME-Version: 1.0 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: Sun, 22 Nov 2015 14:48:14 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BEA384AAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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@ietf.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_9904FB1B0159DA42B0B887B7FA8119CA6BEA384AAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 [ma= ilto: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@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

 

 

 

 

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_9904FB1B0159DA42B0B887B7FA8119CA6BEA384AAZFFEXMB04globa_--