From kathleen.moriarty@emc.com Mon Dec 2 07:18:43 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8148B1A1F4C for ; Mon, 2 Dec 2013 07:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 S-5TRU9oWXzn for ; Mon, 2 Dec 2013 07:18:41 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id C09E81A1F06 for ; Mon, 2 Dec 2013 07:18:40 -0800 (PST) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB2FHnjR002465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Dec 2013 10:17:51 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com rB2FHnjR002465 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1385997471; bh=Yz0UnppnAw9B/Enw+0HNZKjnWsQ=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=l+A+USAlVvbYVzl1qj2Mhn9vlA/CaBQCr8JDRdR4R1bA0Pyy5ufii8KJ7UV4dsLsZ TuLwTgY8eMxYRD7LxSPhxN5vcOwEQwekFClc8h+3LRTLvJmN4lK7R3R8znLwdl6tOi dHU0TsS0KR0j4RS+eaOl/hvs1XYjkLGVcUGEb4Xc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com rB2FHnjR002465 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd55.lss.emc.com (RSA Interceptor); Mon, 2 Dec 2013 10:17:37 -0500 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB2FHaCH004521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 10:17:36 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Mon, 2 Dec 2013 10:17:36 -0500 From: "Moriarty, Kathleen" To: Romain Bourgue , "mile@ietf.org" Date: Mon, 2 Dec 2013 10:17:34 -0500 Thread-Topic: New ENISA report: Detect, SHARE, Protect Thread-Index: Ac7qvrOAh7wDQ3BkTkGQnJdIs5J5MQEsquZQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F2406540957F5MX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 15:18:43 -0000 --_000_F5063677821E3B4F81ACFB7905573F2406540957F5MX15Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Romain, Thank you for posting the review conducted by ENISA. Your report points ou= t several challenges and it would be good to hear thoughts from working gro= up members on how we can address those challenges for MILE work. This is a valuable external review and I appreciate all the efforts of ENIS= A to help focus and progress this work to make a positive difference for th= e CSIRT community! Best regards, Kathleen From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Romain Bourgue Sent: Tuesday, November 26, 2013 11:23 AM To: mile@ietf.org Subject: [mile] New ENISA report: Detect, SHARE, Protect Dear all, ENISA has released a new report on solutions for improving threat data exch= ange among CERTs. This report analyses the current practices and challenges CERTs are facing = in the area of threat data exchange and take stock of related standards and= technical solutions. IODEF and RID (and STIX and TAXII) are part of the analysed standards. The = report also covers emerging technical solutions like CIF and MISP that coul= d help CERTs in sharing data more efficiently. We also made some recommenda= tions for better data exchange practices among CERTs. This report is the re= sult of a cooperative work involving CERTs teams (mainly EU National and Go= vernmental teams). I hope you'll find it interesting and helpful. Feel free to disseminate it! https://www.enisa.europa.eu/media/press-releases/enisa-calls-for-better-dat= a-sharing-and-interoperability-among-certs-to-mitigate-cyberattacks Best regards, Romain Bourgue Operational Security - CERT Relations ENISA - Securing Europe's Information Society Tel: +30 281 440 96 62 Mob: +30 695 178 22 71 --_000_F5063677821E3B4F81ACFB7905573F2406540957F5MX15Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Romain,

 

Thank you for posting the review conducted by = ENISA.  Your report points out several challenges and it would be good= to hear thoughts from working group members on how we can address those ch= allenges for MILE work.

 

This is a valuable ex= ternal review and I appreciate all the efforts of ENISA to help focus and p= rogress this work to make a positive difference for the CSIRT community!

 

=

Best regards,

Kathleen

<= o:p> 

From: mile [mai= lto:mile-bounces@ietf.org] On Behalf Of Romain Bourgue
Sent: Tuesday, November 26, 2013 11:23 AM
To: mile@ietf.org
Su= bject: [mile] New ENISA report: Detect, SHARE, Protect

 

Dear all,

 

ENISA has released a new report on sol= utions for improving threat data exchange among CERTs.

This report analyses the current practices and ch= allenges CERTs are facing in the area of threat data exchange and take stoc= k of related standards and technical solutions.

=

IODEF and RID (and STIX and TAXII) are part of the analy= sed standards. The report also covers emerging technical solutions like CIF= and MISP that could help CERTs in sharing data more efficiently. We also m= ade some recommendations for better data exchange practices among CERTs. Th= is report is the result of a cooperative work involving CERTs teams (mainly= EU National and Governmental teams).

 

I hope you&#= 8217;ll find it interesting and helpful. Feel free to disseminate it!<= /o:p>

 

=

 

 

Best regards,

 

Romain Bourgue

Operational Security – CERT Rela= tions

ENISA = 211; Securing Europe’s Information Society

Tel: +30 281 440 96 62 Mob: +30 695 178 2= 2 71

 =

 

 

= --_000_F5063677821E3B4F81ACFB7905573F2406540957F5MX15Acorpemcc_-- From Thomas.Millar@us-cert.gov Mon Dec 2 10:18:32 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68F71AD9AB for ; Mon, 2 Dec 2013 10:18:32 -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, RP_MATCHES_RCVD=-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 uDUCjgSE5wTA for ; Mon, 2 Dec 2013 10:18:30 -0800 (PST) Received: from daphne.brass.us-cert.gov (daphne.brass.us-cert.gov [IPv6:2620:112:5000:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id A316F1AD9A9 for ; Mon, 2 Dec 2013 10:18:29 -0800 (PST) Received: from daphne.brass.us-cert.gov (daphne.brass.us-cert.gov [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 64D3BC5D2; Mon, 2 Dec 2013 18:18:26 +0000 (UTC) Received: from yabba.bronze.us-cert.gov (yabba.bronze.us-cert.gov [192.168.2.22]) by daphne.brass.us-cert.gov (Postfix) with ESMTP id 4CD60C5D1; Mon, 2 Dec 2013 18:18:26 +0000 (UTC) Received: from rubicon.bronze.us-cert.gov (rubicon.bronze.us-cert.gov [192.168.2.160]) by yabba.bronze.us-cert.gov (Postfix) with ESMTP id 2041B30077; Mon, 2 Dec 2013 18:18:26 +0000 (UTC) Received: from bobcat.bronze.us-cert.gov ([10.24.6.82]) by rubicon.bronze.us-cert.gov with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Dec 2013 13:18:26 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 2 Dec 2013 12:18:25 -0600 Message-ID: <01FDD0EDFF2BFC47A89029A6B409322E9154EF@bobcat.bronze.us-cert.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New ENISA report: Detect, SHARE, Protect Thread-Index: Ac7qvrOAh7wDQ3BkTkGQnJdIs5J5MQEyLJjQ From: To: , X-OriginalArrivalTime: 02 Dec 2013 18:18:26.0601 (UTC) FILETIME=[E4F37990:01CEEF8A] Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 18:18:33 -0000 Romain, The survey research and findings (sections 2-3) are quite good and I really appreciate the effort that went into it. The findings in particular do a great job of summarizing the challenges facing CERT-to-CERT info sharing without glossing over important technical details.=20 However, I don't see a similar explanation of methodology for section 4, and in fact section 4 seems a bit confusing overall. It's not especially clear which efforts are currently in operational use, which are proposed for future use, and the relationship between 4.1 efforts and 4.2 examples is also not clear. Perhaps it is because this section is offered as background material rather than in direct support of the survey research and recommendations - in which case, it may have best been included as an Appendix or Annex to the report.=20 I note that in the acknowledgements you thank active participants and architects from at least four of the named efforts listed in section 4 - were reviewers sought from the other listed efforts? I doubt that the STIX community would agree with the representation in Figure 6. =A0- Tom Millar thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870=20 -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Romain Bourgue Sent: Tuesday, November 26, 2013 11:23 AM To: mile@ietf.org Subject: [mile] New ENISA report: Detect, SHARE, Protect Dear all, =20 ENISA has released a new report on solutions for improving threat data exchange among CERTs. This report analyses the current practices and challenges CERTs are facing in the area of threat data exchange and take stock of related standards and technical solutions. IODEF and RID (and STIX and TAXII) are part of the analysed standards. The report also covers emerging technical solutions like CIF and MISP that could help CERTs in sharing data more efficiently. We also made some recommendations for better data exchange practices among CERTs. This report is the result of a cooperative work involving CERTs teams (mainly EU National and Governmental teams).=20 =20 I hope you'll find it interesting and helpful. Feel free to disseminate it! =20 https://www.enisa.europa.eu/media/press-releases/enisa-calls-for-better- data-sharing-and-interoperability-among-certs-to-mitigate-cyberattacks =20 =20 Best regards, =20 Romain Bourgue Operational Security - CERT Relations ENISA - Securing Europe's Information Society Tel: +30 281 440 96 62 Mob: +30 695 178 22 71 =20 =20 =20 From Romain.Bourgue@enisa.europa.eu Tue Dec 3 00:10:17 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A864A1AE094 for ; Tue, 3 Dec 2013 00:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 zfX8wyT88OzO for ; Tue, 3 Dec 2013 00:10:14 -0800 (PST) Received: from maia.net1.enisa.europa.eu (maia.net1.enisa.europa.eu [139.91.222.11]) by ietfa.amsl.com (Postfix) with ESMTP id BE32B1AE06F for ; Tue, 3 Dec 2013 00:10:12 -0800 (PST) Received: from HERMES.net1.enisa.europa.eu (172.16.0.142) by maia.net1.enisa.europa.eu (139.91.222.11) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Dec 2013 10:10:03 +0200 Received: from HERMES.net1.enisa.europa.eu ([::1]) by Hermes.net1.enisa.europa.eu ([::1]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 10:10:07 +0200 From: Romain Bourgue To: "Thomas.Millar@us-cert.gov" , "mile@ietf.org" Thread-Topic: [mile] New ENISA report: Detect, SHARE, Protect Thread-Index: Ac7qvrOAh7wDQ3BkTkGQnJdIs5J5MQEyLJjQABz7h6A= Date: Tue, 3 Dec 2013 08:10:06 +0000 Message-ID: References: <01FDD0EDFF2BFC47A89029A6B409322E9154EF@bobcat.bronze.us-cert.gov> In-Reply-To: <01FDD0EDFF2BFC47A89029A6B409322E9154EF@bobcat.bronze.us-cert.gov> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.13.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 08:10:18 -0000 Hello Tom, Thank you very much for your comments and your interest in our report. I'm glad that you liked the analysis of the current situation and challenge= s in the data sharing practices of CERT. I understand your point regarding section 4. If you felt like this section = was missing explained reasoning and methodology it's because of a deliberat= e choice of a factual-only approach so that technical teams could identify = by themselves their own interest for a particular standard or tool. A large number of CERT teams, at least in Europe, just don't know about the= se standards, tools and projects but they all have specific expectations wh= en it comes to sharing data. We thought that basing this section on an anal= ytic approach would have excluded some specific reasoning and therefore, it= could have limited their adoptions.=20 We were driven by simplification and vulgarisation, I hope it was not at a = too big expense of accuracy. But you're right, our approach should have bee= n explained more clearly in this section. Still, lately, a team involved in the development of an incident messaging = tool was about to create a new common data model, after reading the report,= they got in touch with the STIX community and decided to implement a gener= ic event mapping using STIX/Cybox. Our motivation is precisely that. If more teams get to know these standards= , tools and projects, we believe that sharing communities would grow and in= formation would flow more easily. Thanks again for your comments! -Romain > -----Original Message----- > From: Thomas.Millar@us-cert.gov [mailto:Thomas.Millar@us-cert.gov] > Sent: 02 December 2013 20:19 > To: Romain Bourgue; mile@ietf.org > Subject: RE: [mile] New ENISA report: Detect, SHARE, Protect >=20 > Romain, >=20 > The survey research and findings (sections 2-3) are quite good and I real= ly > appreciate the effort that went into it. The findings in particular do a = great > job of summarizing the challenges facing CERT-to-CERT info sharing withou= t > glossing over important technical details. >=20 > However, I don't see a similar explanation of methodology for section 4, = and > in fact section 4 seems a bit confusing overall. It's not especially clea= r which > efforts are currently in operational use, which are proposed for future u= se, > and the relationship between 4.1 efforts and 4.2 examples is also not cle= ar. > Perhaps it is because this section is offered as background material rath= er > than in direct support of the survey research and recommendations - in > which case, it may have best been included as an Appendix or Annex to the > report. >=20 > I note that in the acknowledgements you thank active participants and > architects from at least four of the named efforts listed in section 4 - = were > reviewers sought from the other listed efforts? I doubt that the STIX > community would agree with the representation in Figure 6. >=20 > =A0- Tom Millar >=20 > thomas.millar@us-cert.gov > BB: thomas.millar@dhs.gov / 202-631-1915 > 24x7: soc@us-cert.gov / 888-282-0870 >=20 >=20 > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Romain Bourgue > Sent: Tuesday, November 26, 2013 11:23 AM > To: mile@ietf.org > Subject: [mile] New ENISA report: Detect, SHARE, Protect >=20 > Dear all, >=20 > ENISA has released a new report on solutions for improving threat data > exchange among CERTs. > This report analyses the current practices and challenges CERTs are facin= g in > the area of threat data exchange and take stock of related standards and > technical solutions. > IODEF and RID (and STIX and TAXII) are part of the analysed standards. > The report also covers emerging technical solutions like CIF and MISP tha= t > could help CERTs in sharing data more efficiently. We also made some > recommendations for better data exchange practices among CERTs. > This report is the result of a cooperative work involving CERTs teams (ma= inly > EU National and Governmental teams). >=20 > I hope you'll find it interesting and helpful. Feel free to disseminate i= t! >=20 > https://www.enisa.europa.eu/media/press-releases/enisa-calls-for-better- > data-sharing-and-interoperability-among-certs-to-mitigate-cyberattacks > -data-sharing-and-interoperability-among-certs-to-mitigate-cyberattacks> >=20 >=20 >=20 > Best regards, >=20 > Romain Bourgue > Operational Security - CERT Relations > ENISA - Securing Europe's Information Society > Tel: +30 281 440 96 62 Mob: +30 695 178 22 71 >=20 >=20 >=20 From tony@yaanatech.com Tue Dec 3 01:58:46 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5890D1AE0EC for ; Tue, 3 Dec 2013 01:58:46 -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, RP_MATCHES_RCVD=-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 i8uLbFci4pRT for ; Tue, 3 Dec 2013 01:58:44 -0800 (PST) Received: from extmail1.yaanatech.com (extmail1.yaanatech.com [63.128.177.51]) by ietfa.amsl.com (Postfix) with SMTP id 0A6F51AE0EE for ; Tue, 3 Dec 2013 01:58:44 -0800 (PST) Received: from [10.184.77.149] (unknown [203.121.55.249]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by extmail1.yaanatech.com (Postfix) with ESMTP id 4C15258095; Tue, 3 Dec 2013 09:59:56 +0000 (UTC) Date: Tue, 03 Dec 2013 17:58:31 +0800 From: tony@yaanatech.com To: Romain Bourgue MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Message-Id: <20131203095956.4C15258095@extmail1.yaanatech.com> Cc: "mile@ietf.org " Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 09:58:46 -0000 VGhlIHJhbXBpbmcgdXAgb2YgdGhlIG5ldyBFVFNJIEN5YmVyc2VjdXJpdHkgVGVjaG5pY2FsIENv bW1pdHRlZSBsZWQgYnkgQ2hhcmxlcyBCcm9va3NvbsKgIHNob3VsZCBoZWxwIGZhY2lsaXRhdGUg ZWZmZWN0aXZlIGNvbGxhYm9yYXRpb24gaGVyZS4KCi0tdG9ueQoKT24gRGVjIDMsIDIwMTMgNDox MCBQTSwgUm9tYWluIEJvdXJndWUgPFJvbWFpbi5Cb3VyZ3VlQGVuaXNhLmV1cm9wYS5ldT4gd3Jv dGU6Cj4KPiBIZWxsbyBUb20sIAo+Cj4gVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBjb21t ZW50cyBhbmQgeW91ciBpbnRlcmVzdCBpbiBvdXIgcmVwb3J0LiAKPiBJJ20gZ2xhZCB0aGF0IHlv dSBsaWtlZCB0aGUgYW5hbHlzaXMgb2YgdGhlIGN1cnJlbnQgc2l0dWF0aW9uIGFuZCBjaGFsbGVu Z2VzIGluIHRoZSBkYXRhIHNoYXJpbmcgcHJhY3RpY2VzIG9mIENFUlQuIAo+Cj4gSSB1bmRlcnN0 YW5kIHlvdXIgcG9pbnQgcmVnYXJkaW5nIHNlY3Rpb24gNC4gSWYgeW91IGZlbHQgbGlrZSB0aGlz IHNlY3Rpb24gd2FzIG1pc3NpbmcgZXhwbGFpbmVkIHJlYXNvbmluZyBhbmQgbWV0aG9kb2xvZ3kg aXQncyBiZWNhdXNlIG9mIGEgZGVsaWJlcmF0ZSBjaG9pY2Ugb2YgYSBmYWN0dWFsLW9ubHkgYXBw cm9hY2ggc28gdGhhdCB0ZWNobmljYWwgdGVhbXMgY291bGQgaWRlbnRpZnkgYnkgdGhlbXNlbHZl cyB0aGVpciBvd24gaW50ZXJlc3QgZm9yIGEgcGFydGljdWxhciBzdGFuZGFyZCBvciB0b29sLiAK Pgo+IEEgbGFyZ2UgbnVtYmVyIG9mIENFUlQgdGVhbXMsIGF0IGxlYXN0IGluIEV1cm9wZSwganVz dCBkb24ndCBrbm93IGFib3V0IHRoZXNlIHN0YW5kYXJkcywgdG9vbHMgYW5kIHByb2plY3RzIGJ1 dCB0aGV5IGFsbCBoYXZlIHNwZWNpZmljIGV4cGVjdGF0aW9ucyB3aGVuIGl0IGNvbWVzIHRvIHNo YXJpbmcgZGF0YS4gV2UgdGhvdWdodCB0aGF0IGJhc2luZyB0aGlzIHNlY3Rpb24gb24gYW4gYW5h bHl0aWMgYXBwcm9hY2ggd291bGQgaGF2ZSBleGNsdWRlZCBzb21lIHNwZWNpZmljIHJlYXNvbmlu ZyBhbmQgdGhlcmVmb3JlLCBpdCBjb3VsZCBoYXZlIGxpbWl0ZWQgdGhlaXIgYWRvcHRpb25zLiAK PiBXZSB3ZXJlIGRyaXZlbiBieSBzaW1wbGlmaWNhdGlvbiBhbmQgdnVsZ2FyaXNhdGlvbiwgSSBo b3BlIGl0IHdhcyBub3QgYXQgYSB0b28gYmlnIGV4cGVuc2Ugb2YgYWNjdXJhY3kuIEJ1dCB5b3Un cmUgcmlnaHQsIG91ciBhcHByb2FjaCBzaG91bGQgaGF2ZSBiZWVuIGV4cGxhaW5lZCBtb3JlIGNs ZWFybHkgaW4gdGhpcyBzZWN0aW9uLiAKPgo+IFN0aWxsLCBsYXRlbHksIGEgdGVhbSBpbnZvbHZl ZCBpbiB0aGUgZGV2ZWxvcG1lbnQgb2YgYW4gaW5jaWRlbnQgbWVzc2FnaW5nIHRvb2wgd2FzIGFi b3V0IHRvIGNyZWF0ZSBhIG5ldyBjb21tb24gZGF0YSBtb2RlbCwgYWZ0ZXIgcmVhZGluZyB0aGUg cmVwb3J0LCB0aGV5IGdvdCBpbiB0b3VjaCB3aXRoIHRoZSBTVElYIGNvbW11bml0eSBhbmQgZGVj aWRlZCB0byBpbXBsZW1lbnQgYSBnZW5lcmljIGV2ZW50IG1hcHBpbmcgdXNpbmcgU1RJWC9DeWJv eC4gCj4gT3VyIG1vdGl2YXRpb24gaXMgcHJlY2lzZWx5IHRoYXQuIElmIG1vcmUgdGVhbXMgZ2V0 IHRvIGtub3cgdGhlc2Ugc3RhbmRhcmRzLCB0b29scyBhbmQgcHJvamVjdHMsIHdlIGJlbGlldmUg dGhhdCBzaGFyaW5nIGNvbW11bml0aWVzIHdvdWxkIGdyb3cgYW5kIGluZm9ybWF0aW9uIHdvdWxk IGZsb3cgbW9yZSBlYXNpbHkuIAo+Cj4KPiBUaGFua3MgYWdhaW4gZm9yIHlvdXIgY29tbWVudHMh IAo+Cj4gLVJvbWFpbiAKPgo+Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSAKPiA+IEZy b206IFRob21hcy5NaWxsYXJAdXMtY2VydC5nb3YgW21haWx0bzpUaG9tYXMuTWlsbGFyQHVzLWNl cnQuZ292XSAKPiA+IFNlbnQ6IDAyIERlY2VtYmVyIDIwMTMgMjA6MTkgCj4gPiBUbzogUm9tYWlu IEJvdXJndWU7IG1pbGVAaWV0Zi5vcmcgCj4gPiBTdWJqZWN0OiBSRTogW21pbGVdIE5ldyBFTklT QSByZXBvcnQ6IERldGVjdCwgU0hBUkUsIFByb3RlY3QgCj4gPiAKPiA+IFJvbWFpbiwgCj4gPiAK PiA+IFRoZSBzdXJ2ZXkgcmVzZWFyY2ggYW5kIGZpbmRpbmdzIChzZWN0aW9ucyAyLTMpIGFyZSBx dWl0ZSBnb29kIGFuZCBJIHJlYWxseSAKPiA+IGFwcHJlY2lhdGUgdGhlIGVmZm9ydCB0aGF0IHdl bnQgaW50byBpdC4gVGhlIGZpbmRpbmdzIGluIHBhcnRpY3VsYXIgZG8gYSBncmVhdCAKPiA+IGpv YiBvZiBzdW1tYXJpemluZyB0aGUgY2hhbGxlbmdlcyBmYWNpbmcgQ0VSVC10by1DRVJUIGluZm8g c2hhcmluZyB3aXRob3V0IAo+ID4gZ2xvc3Npbmcgb3ZlciBpbXBvcnRhbnQgdGVjaG5pY2FsIGRl dGFpbHMuIAo+ID4gCj4gPiBIb3dldmVyLCBJIGRvbid0IHNlZSBhIHNpbWlsYXIgZXhwbGFuYXRp b24gb2YgbWV0aG9kb2xvZ3kgZm9yIHNlY3Rpb24gNCwgYW5kIAo+ID4gaW4gZmFjdCBzZWN0aW9u IDQgc2VlbXMgYSBiaXQgY29uZnVzaW5nIG92ZXJhbGwuIEl0J3Mgbm90IGVzcGVjaWFsbHkgY2xl YXIgd2hpY2ggCj4gPiBlZmZvcnRzIGFyZSBjdXJyZW50bHkgaW4gb3BlcmF0aW9uYWwgdXNlLCB3 aGljaCBhcmUgcHJvcG9zZWQgZm9yIGZ1dHVyZSB1c2UsIAo+ID4gYW5kIHRoZSByZWxhdGlvbnNo aXAgYmV0d2VlbiA0LjEgZWZmb3J0cyBhbmQgNC4yIGV4YW1wbGVzIGlzIGFsc28gbm90IGNsZWFy LiAKPiA+IFBlcmhhcHMgaXQgaXMgYmVjYXVzZSB0aGlzIHNlY3Rpb24gaXMgb2ZmZXJlZCBhcyBi YWNrZ3JvdW5kIG1hdGVyaWFsIHJhdGhlciAKPiA+IHRoYW4gaW4gZGlyZWN0IHN1cHBvcnQgb2Yg dGhlIHN1cnZleSByZXNlYXJjaCBhbmQgcmVjb21tZW5kYXRpb25zIC0gaW4gCj4gPiB3aGljaCBj YXNlLCBpdCBtYXkgaGF2ZSBiZXN0IGJlZW4gaW5jbHVkZWQgYXMgYW4gQXBwZW5kaXggb3IgQW5u ZXggdG8gdGhlIAo+ID4gcmVwb3J0LiAKPiA+IAo+ID4gSSBub3RlIHRoYXQgaW4gdGhlIGFja25v d2xlZGdlbWVudHMgeW91IHRoYW5rIGFjdGl2ZSBwYXJ0aWNpcGFudHMgYW5kIAo+ID4gYXJjaGl0 ZWN0cyBmcm9tIGF0IGxlYXN0IGZvdXIgb2YgdGhlIG5hbWVkIGVmZm9ydHMgbGlzdGVkIGluIHNl Y3Rpb24gNCAtIHdlcmUgCj4gPiByZXZpZXdlcnMgc291Z2h0IGZyb20gdGhlIG90aGVyIGxpc3Rl ZCBlZmZvcnRzPyBJIGRvdWJ0IHRoYXQgdGhlIFNUSVggCj4gPiBjb21tdW5pdHkgd291bGQgYWdy ZWUgd2l0aCB0aGUgcmVwcmVzZW50YXRpb24gaW4gRmlndXJlIDYuIAo+ID4gCj4gPiDCoC0gVG9t IE1pbGxhciAKPiA+IAo+ID4gdGhvbWFzLm1pbGxhckB1cy1jZXJ0LmdvdiAKPiA+IEJCOiB0aG9t YXMubWlsbGFyQGRocy5nb3YgLyAyMDItNjMxLTE5MTUgCj4gPiAyNHg3OiBzb2NAdXMtY2VydC5n b3YgLyA4ODgtMjgyLTA4NzAgCj4gPiAKPiA+IAo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0gCj4gPiBGcm9tOiBtaWxlIFttYWlsdG86bWlsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgUm9tYWluIEJvdXJndWUgCj4gPiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyNiwgMjAx MyAxMToyMyBBTSAKPiA+IFRvOiBtaWxlQGlldGYub3JnIAo+ID4gU3ViamVjdDogW21pbGVdIE5l dyBFTklTQSByZXBvcnQ6IERldGVjdCwgU0hBUkUsIFByb3RlY3QgCj4gPiAKPiA+IERlYXIgYWxs LCAKPiA+IAo+ID4gRU5JU0EgaGFzIHJlbGVhc2VkIGEgbmV3IHJlcG9ydCBvbiBzb2x1dGlvbnMg Zm9yIGltcHJvdmluZyB0aHJlYXQgZGF0YSAKPiA+IGV4Y2hhbmdlIGFtb25nIENFUlRzLiAKPiA+ IFRoaXMgcmVwb3J0IGFuYWx5c2VzIHRoZSBjdXJyZW50IHByYWN0aWNlcyBhbmQgY2hhbGxlbmdl cyBDRVJUcyBhcmUgZmFjaW5nIGluIAo+ID4gdGhlIGFyZWEgb2YgdGhyZWF0IGRhdGEgZXhjaGFu Z2UgYW5kIHRha2Ugc3RvY2sgb2YgcmVsYXRlZCBzdGFuZGFyZHMgYW5kIAo+ID4gdGVjaG5pY2Fs IHNvbHV0aW9ucy4gCj4gPiBJT0RFRiBhbmQgUklEIChhbmQgU1RJWCBhbmQgVEFYSUkpIGFyZSBw YXJ0IG9mIHRoZSBhbmFseXNlZCBzdGFuZGFyZHMuIAo+ID4gVGhlIHJlcG9ydCBhbHNvIGNvdmVy cyBlbWVyZ2luZyB0ZWNobmljYWwgc29sdXRpb25zIGxpa2UgQ0lGIGFuZCBNSVNQIHRoYXQgCj4g PiBjb3VsZCBoZWxwIENFUlRzIGluIHNoYXJpbmcgZGF0YSBtb3JlIGVmZmljaWVudGx5LiBXZSBh bHNvIG1hZGUgc29tZSAKPiA+IHJlY29tbWVuZGF0aW9ucyBmb3IgYmV0dGVyIGRhdGEgZXhjaGFu Z2UgcHJhY3RpY2VzIGFtb25nIENFUlRzLiAKPiA+IFRoaXMgcmVwb3J0IGlzIHRoZSByZXN1bHQg b2YgYSBjb29wZXJhdGl2ZSB3b3JrIGludm9sdmluZyBDRVJUcyB0ZWFtcyAobWFpbmx5IAo+ID4g RVUgTmF0aW9uYWwgYW5kIEdvdmVybm1lbnRhbCB0ZWFtcykuIAo+ID4gCj4gPiBJIGhvcGUgeW91 J2xsIGZpbmQgaXQgaW50ZXJlc3RpbmcgYW5kIGhlbHBmdWwuIEZlZWwgZnJlZSB0byBkaXNzZW1p bmF0ZSBpdCEgCj4gPiAKPiA+IGh0dHBzOi8vd3d3LmVuaXNhLmV1cm9wYS5ldS9tZWRpYS9wcmVz cy1yZWxlYXNlcy9lbmlzYS1jYWxscy1mb3ItYmV0dGVyLSAKPiA+IGRhdGEtc2hhcmluZy1hbmQt aW50ZXJvcGVyYWJpbGl0eS1hbW9uZy1jZXJ0cy10by1taXRpZ2F0ZS1jeWJlcmF0dGFja3MgCj4g PiA8aHR0cHM6Ly93d3cuZW5pc2EuZXVyb3BhLmV1L21lZGlhL3ByZXNzLXJlbGVhc2VzL2VuaXNh LWNhbGxzLWZvci1iZXR0ZXIgCj4gPiAtZGF0YS1zaGFyaW5nLWFuZC1pbnRlcm9wZXJhYmlsaXR5 LWFtb25nLWNlcnRzLXRvLW1pdGlnYXRlLWN5YmVyYXR0YWNrcz4gCj4gPiAKPiA+IAo+ID4gCj4g PiBCZXN0IHJlZ2FyZHMsIAo+ID4gCj4gPiBSb21haW4gQm91cmd1ZSAKPiA+IE9wZXJhdGlvbmFs IFNlY3VyaXR5IC0gQ0VSVCBSZWxhdGlvbnMgCj4gPiBFTklTQSAtIFNlY3VyaW5nIEV1cm9wZSdz IEluZm9ybWF0aW9uIFNvY2lldHkgCj4gPiBUZWw6ICszMCAyODEgNDQwIDk2IDYyIE1vYjogKzMw IDY5NSAxNzggMjIgNzEgCj4gPiAKPiA+IAo+ID4gCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18gCj4gbWlsZSBtYWlsaW5nIGxpc3QgCj4gbWlsZUBpZXRm Lm9yZyAKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGUgCg== From mchernin@dtcc.com Wed Dec 4 13:58:02 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847151AD8F5 for ; Wed, 4 Dec 2013 13:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 s7i_IxI1lWk1 for ; Wed, 4 Dec 2013 13:57:58 -0800 (PST) Received: from sxinet05.dtcc.com (sxinet05.dtcc.com [207.45.45.43]) by ietfa.amsl.com (Postfix) with ESMTP id 51F551AD9B8 for ; Wed, 4 Dec 2013 13:57:58 -0800 (PST) From: "Chernin, Michael A." To: "mile@ietf.org" Thread-Topic: Re: [mile] New ENISA report: Detect, SHARE, Protect Thread-Index: Ac7xNskhr6bWWDMfTuWlQflrDAB0qQ== Date: Wed, 4 Dec 2013 21:57:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.113.13] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_E3EFB6C0D90F82478AF227AA85ECF38077FBEF86SXEMBP01corpdtc_" Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 21:58:03 -0000 --_000_E3EFB6C0D90F82478AF227AA85ECF38077FBEF86SXEMBP01corpdtc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the report Romain=2E I will second Mr=2E Millar that sections 1-= 3 provide valuable information regards to the barriers to sharing=2E=0D=0A= =0D=0AMy concerns start in section 4, where the Data Exchange formats are c= ompared=2E At our current sharing maturity level, people are doing a lot of= research on specification selection, and during this time specification pe= rception holds a lot of value=2E I am concerned about the primary image (Fi= gure 6) used to open section 4=2E My input is below:=0D=0A=0D=0A=0D=0A=0D= =0A* It's easy to imagine a standard/specification that can do ever= ything=2E While there is an asterisk next to MACCSA stating that it's in th= e definition phase, the way it spans the entire chart gives it a superior p= erception to other more defined specifications like IODEF and STIX=2E=0D=0A= =0D=0A* I am unable to locate a definition for Network and File obs= ervable columns on the chart=2E All the specifications compared have key co= verage differences in these areas=2E=0D=0A=0D=0A* Critical areas th= at both STIX and IODEF excel at, like email, are missing as a column entire= ly=0D=0A=0D=0A* Key observable columns that STIX excels at are miss= ing entirely: Actors, Campaigns, TTP, Targeting, Windows objects, Unix obj= ects, Privileges, Package Manager Data, User Account Data, DNS, etc=2E Thes= e missing columns make STIX appear less capable=2E If you add those columns= in, than a completely different story is told and STIX appears the most ca= pable=2E=0D=0A=0D=0AThanks=0D=0AAharon=0D=0A=0D=0ADTCC Non-Confidential (Wh= ite)=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
_____________________________________= ________________________=0D=0A
=0D=0ADTCC DISCLAIMER: Thi= s email and any files transmitted with it are=0D=0Aconfidential and intende= d solely for the use of the individual or=0D=0Aentity to whom they are addr= essed=2E If you have received this email=0D=0Ain error, please notify us im= mediately and delete the email and any=0D=0Aattachments from your system=2E= The recipient should check this email=0D=0Aand any attachments for the pre= sence of viruses=2E The company=0D=0Aaccepts no liability for any damage c= aused by any virus transmitted=0D=0Aby this email=2E --_000_E3EFB6C0D90F82478AF227AA85ECF38077FBEF86SXEMBP01corpdtc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A

Thanks for the report Romain=2E I will= second Mr=2E Millar that sections 1-3 provide valuable information regards= to the barriers to sharing=2E

=0D=0A

<= o:p> 

=0D=0A

My concerns start in secti= on 4, where the Data Exchange formats are compared=2E At our current sharin= g maturity level, people are doing a lot of research on specification selec= tion, and during this time specification perception holds a lot=0D=0A of va= lue=2E I am concerned about the primary image (Figure 6) used to open secti= on 4=2E My input is below:

=0D=0A

 

=0D=0A

·     &nb= sp;  =0D=0AIt’s easy to imag= ine a standard/specification that can do everything=2E While there is an as= terisk next to MACCSA stating that it’s in the definition phase, the = way it spans the entire chart gives it a superior perception to other=0D=0A= more defined specifications like IODEF and STIX=2E

=0D=0A·        =0D=0AI am unable to locate a definition for Network and Fil= e observable columns on the chart=2E All the specifications compared have k= ey coverage differences in these areas=2E

=0D=0A

·=         =0D=0A= Critical areas that both STIX and IODEF excel at, like email, are= missing as a column entirely

=0D=0A

&m= iddot;  =       =0D=0AKe= y observable columns that STIX excels at are missing entirely:  Actors= , Campaigns, TTP, Targeting, Windows objects, Unix objects, Privileges, Pac= kage Manager Data, User Account Data, DNS, etc=2E These missing columns mak= e STIX=0D=0A appear less capable=2E If you add those columns in, than a com= pletely different story is told and STIX appears the most capable=2E=0D=0A<= o:p>

=0D=0A

 

=0D=0A

Thanks

=0D=0A

Aharon<= o:p>

=0D=0A

 

=0D=0A

DTCC Non-Co= nfidential (White)
=0D=0A
=0D=0A

=0D=0A

 

=0D=0A
=0D=0A=0D=0A= =0D=0A=0D=0A
___________________________________________________________= __=0D=0A
=0D=0ADTCC DISCLAIMER: This email and any files = transmitted with it are confidential and intended solely for the use of the= individual or entity to whom they are addressed=2E If you have received th= is email in error, please notify us immediately and delete the email and an= y attachments from your system=2E The recipient should check this email and= any attachments for the presence of viruses=2E The company accepts no lia= bility for any damage caused by any virus transmitted by this email=2E --_000_E3EFB6C0D90F82478AF227AA85ECF38077FBEF86SXEMBP01corpdtc_-- From kathleen.moriarty@emc.com Wed Dec 4 14:41:19 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48CE1ADF73 for ; Wed, 4 Dec 2013 14:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 8OQGoJ3gSdUe for ; Wed, 4 Dec 2013 14:41:15 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9431AE16F for ; Wed, 4 Dec 2013 14:41:14 -0800 (PST) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB4Mf9m8006679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Dec 2013 17:41:10 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com rB4Mf9m8006679 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1386196870; bh=sZ0MgRaTHdJYqkxSxvRIjgmrUFE=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=H8YPrG14IMF1BfwzyPqSuXWRQCQB4yuQgrOUT8+yOCftk13r5AqqiNSqePgBRlW0R sHjtJuA7p94eQA8coNITwSkb7Yl3D0l9MMSCOsLMZFay59yVdubCPYwXLrwjAePYdS RBadsSvDryM8WSyGGtrdn5CJNPHb9WjI2sE5ofo0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com rB4Mf9m8006679 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd51.lss.emc.com (RSA Interceptor); Wed, 4 Dec 2013 17:41:02 -0500 Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB4Mf2Bb017290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 17:41:02 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub28.corp.emc.com ([10.254.110.184]) with mapi; Wed, 4 Dec 2013 17:41:02 -0500 From: "Moriarty, Kathleen" To: "Chernin, Michael A." , "mile@ietf.org" Date: Wed, 4 Dec 2013 17:41:00 -0500 Thread-Topic: Re: [mile] New ENISA report: Detect, SHARE, Protect Thread-Index: Ac7xNskhr6bWWDMfTuWlQflrDAB0qQABdTpw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F240654095BA5MX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: DLM_1, public Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 22:41:20 -0000 --_000_F5063677821E3B4F81ACFB7905573F240654095BA5MX15Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Tom & Aaron for sharing your feedback. These are helpful discussion= s. I can assist on the MACCSA question for those not familiar as it is not in = itself a format, but rather a framework that references and includes other = efforts. It actually covers quite a bit from identity and access managemen= t through to sharing formats and protocols referencing work from several in= ternational standards bodies as appropriate. This was done to show that st= andards existed and could be combined to provide the necessary coverage wit= hout having to invent anything new. The work that proceeded MACCSA involve= d about 18 nations who had requirements for international standards (IETF, = ISO, ITU, etc.) and the ability to update and evolve referenced standards a= s needed in the future. I think there are over 30 nations involved now. I= n addition to the MILE work, the MITRE work is mentioned and will be includ= ed more directly when it moves to a standards body. It is mentioned and de= scribed in the current version. Last time I looked at the MACCSA framework= , it did not compare the formats as that is not the purpose of the framewor= k. Many large efforts like the NATO CDXI for example, are looking IODEF, S= TIX, as well as OpenIOC to use what they need, where they need it. MACCSA = is putting all of the pieces together. In terms of comparisons, I see the formats as suitable for different use ca= ses and think the report comes at a very good time as Aaron points out. Ev= en within a use case, sharing between different entities could vary greatly= and thus the requirements for exchange could vary. Privacy and informatio= n leakage concerns could limit what is used for sharing with certain partie= s and it may be desirable to just support a minimum baseline of what should= be exchanged in those situations. For other exchanges (even in the same s= haring model), richer data sets and information may be very important (Aaro= n's 4th bullet - I would say STIX is the most robust as capable depends on = your use case and requirements. Not everyone can handle that much informat= ion as they are lacking analyst resources to deal with threat actors, campa= igns, etc.). That's part of the reason I think use cases based sharing mod= els are very important as well as having options to choose formats and prot= ocols that meet your requirements. Thanks again for all of your efforts on this report Romain! Best regards, Kathleen From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Chernin, Michael A. Sent: Wednesday, December 04, 2013 4:58 PM To: mile@ietf.org Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect Thanks for the report Romain. I will second Mr. Millar that sections 1-3 pr= ovide valuable information regards to the barriers to sharing. My concerns start in section 4, where the Data Exchange formats are compare= d. At our current sharing maturity level, people are doing a lot of researc= h on specification selection, and during this time specification perception= holds a lot of value. I am concerned about the primary image (Figure 6) us= ed to open section 4. My input is below: * It's easy to imagine a standard/specification that can do everyth= ing. While there is an asterisk next to MACCSA stating that it's in the def= inition phase, the way it spans the entire chart gives it a superior percep= tion to other more defined specifications like IODEF and STIX. * I am unable to locate a definition for Network and File observabl= e columns on the chart. All the specifications compared have key coverage d= ifferences in these areas. * Critical areas that both STIX and IODEF excel at, like email, are= missing as a column entirely * Key observable columns that STIX excels at are missing entirely: = Actors, Campaigns, TTP, Targeting, Windows objects, Unix objects, Privileg= es, Package Manager Data, User Account Data, DNS, etc. These missing column= s make STIX appear less capable. If you add those columns in, than a comple= tely different story is told and STIX appears the most capable. Thanks Aharon DTCC Non-Confidential (White) _____________________________________________________________ DTCC DISCLAIMER: This email and any files transmitted with it are confident= ial and intended solely for the use of the individual or entity to whom the= y are addressed. If you have received this email in error, please notify us= immediately and delete the email and any attachments from your system. The= recipient should check this email and any attachments for the presence of = viruses. The company accepts no liability for any damage caused by any viru= s transmitted by this email. --_000_F5063677821E3B4F81ACFB7905573F240654095BA5MX15Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Tom & Aaron for sharing your feedback.  These= are helpful discussions.

 

I can assist on the MACCSA question for those no= t familiar as it is not in itself a format, but rather a framework that ref= erences and includes other efforts.  It actually covers quite a bit fr= om identity and access management through to sharing formats and protocols = referencing work from several international standards bodies as appropriate= .  This was done to show that standards existed and could be combined = to provide the necessary coverage without having to invent anything new.&nb= sp; The work that proceeded MACCSA involved about 18 nations who had requir= ements for international standards (IETF, ISO, ITU, etc.) and the ability t= o update and evolve referenced standards as needed in the future.  I t= hink there are over 30 nations involved now.  In addition to the MILE = work, the MITRE work is mentioned and will be included more directly when i= t moves to a standards body.  It is mentioned and described in the cur= rent version.  Last time I looked at the MACCSA framework, it did not = compare the formats as that is not the purpose of the framework.  Many= large efforts like the NATO CDXI for example, are looking IODEF, STIX, as = well as OpenIOC to use what they need, where they need it.  MACCSA is = putting all of the pieces together.

 

In terms of comparisons, I see the for= mats as suitable for different use cases and think the report comes at a ve= ry good time as Aaron points out.  Even within a use case, sharing bet= ween different entities could vary greatly and thus the requirements for ex= change could vary.  Privacy and information leakage concerns could lim= it what is used for sharing with certain parties and it may be desirable to= just support a minimum baseline of what should be exchanged in those situa= tions.  For other exchanges (even in the same sharing model), richer d= ata sets and information may be very important (Aaron’s 4th bullet – I would say STIX is the most robust as capable depends on = your use case and requirements.  Not everyone can handle that much inf= ormation as they are lacking analyst resources to deal with threat actors, = campaigns, etc.).  That’s part of the reason I think use cases b= ased sharing models are very important as well as having options to choose = formats and protocols that meet your requirements.

 

Thanks again for all of= your efforts on this report Romain!

 

Best regards,

Kathleen=

 

From: mile [mailto:mile-bounces@ie= tf.org] On Behalf Of Chernin, Michael A.
Sent: Wednesday, = December 04, 2013 4:58 PM
To: mile@ietf.org
Subject: Re= : [mile] New ENISA report: Detect, SHARE, Protect

 

Than= ks for the report Romain. I will second Mr. Millar that sections 1-3 provid= e valuable information regards to the barriers to sharing.

 

My concerns st= art in section 4, where the Data Exchange formats are compared. At our curr= ent sharing maturity level, people are doing a lot of research on specifica= tion selection, and during this time specification perception holds a lot o= f value. I am concerned about the primary image (Figure 6) used to open sec= tion 4. My input is below:

&= nbsp;

·         = It’s easy to imagine a standard/specification that c= an do everything. While there is an asterisk next to MACCSA stating that it= ’s in the definition phase, the way it spans the entire chart gives i= t a superior perception to other more defined specifications like IODEF and= STIX.

·         = I am unable to locate a definition for Network and = File observable columns on the chart. All the specifications compared have = key coverage differences in these areas.

&= middot;    = ;     Critical areas tha= t both STIX and IODEF excel at, like email, are missing as a column entirel= y

·         Key observable columns that STIX excels at are missing en= tirely:  Actors, Campaigns, TTP, Targeting, Windows objects, Unix obje= cts, Privileges, Package Manager Data, User Account Data, DNS, etc. These m= issing columns make STIX appear less capable. If you add those columns in, = than a completely different story is told and STIX appears the most capable= .

 

Thanks

Aharon

 

DTCC Non-Confidenti= al (White)

 

<= p class=3DMsoNormal>
_______________________________________________________= ______
DTCC DISCLAIMER: This email and any files transmitted with it= are confidential and intended solely for the use of the individual or enti= ty to whom they are addressed. If you have received this email in error, pl= ease notify us immediately and delete the email and any attachments from yo= ur system. The recipient should check this email and any attachments for th= e presence of viruses. The company accepts no liability for any damage caus= ed by any virus transmitted by this email.

= --_000_F5063677821E3B4F81ACFB7905573F240654095BA5MX15Acorpemcc_-- From Thomas.Millar@us-cert.gov Thu Dec 5 07:00:04 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8D71AE030 for ; Thu, 5 Dec 2013 07:00:04 -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, RP_MATCHES_RCVD=-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 GeXDl0vEJNDQ for ; Thu, 5 Dec 2013 07:00:01 -0800 (PST) Received: from daphne.brass.us-cert.gov (daphne.brass.us-cert.gov [IPv6:2620:112:5000:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 652691AC863 for ; Thu, 5 Dec 2013 07:00:01 -0800 (PST) Received: from daphne.brass.us-cert.gov (daphne.brass.us-cert.gov [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 4C178C5D1; Thu, 5 Dec 2013 14:59:57 +0000 (UTC) Received: from yabba.bronze.us-cert.gov (yabba.bronze.us-cert.gov [192.168.2.22]) by daphne.brass.us-cert.gov (Postfix) with ESMTP id 1BF45C5D0; Thu, 5 Dec 2013 14:59:57 +0000 (UTC) Received: from rubicon.bronze.us-cert.gov (rubicon.bronze.us-cert.gov [192.168.2.160]) by yabba.bronze.us-cert.gov (Postfix) with ESMTP id DD6AC30077; Thu, 5 Dec 2013 14:59:56 +0000 (UTC) Received: from bobcat.bronze.us-cert.gov ([10.24.6.82]) by rubicon.bronze.us-cert.gov with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Dec 2013 09:59:55 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 5 Dec 2013 08:59:54 -0600 Message-ID: <01FDD0EDFF2BFC47A89029A6B409322E91555D@bobcat.bronze.us-cert.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [mile] New ENISA report: Detect, SHARE, Protect Thread-Index: Ac7xNskhr6bWWDMfTuWlQflrDAB0qQABdTpwACJvK8A= From: To: , , X-OriginalArrivalTime: 05 Dec 2013 14:59:55.0358 (UTC) FILETIME=[A88947E0:01CEF1CA] Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 15:00:04 -0000 Thank you Kathleen. I think some of the head-scratching stems from the fact that there is very little out there to explain the "framework" efforts like MACCSA and CDXI. That's especially problematic when trying to put them side by side against activities like STIX, TAXII, CybOX, CIF, AbuseHelper, and this WG. To clarify - each of those latter items I just mentioned has a public website with lots of information on the work, links to repositories of running code, major commercial entities involved (several publicly announcing their involvement, like Microsoft with regards to STIX), and most importantly to me, other national CSIRTs actively participating. CDXI and MACCSA, as far as I can tell, have been discussed for years but I have yet to see how they actually work or who is actually using them in an operational environment, or even in a testbed. You could throw NEISAS in the latter category as well, I suppose. I'm concerned that putting white paper frameworks up against actual specifications and working software that people use every day can only lead to more confusion in an arena where - as you and I have noted time and again - there is already more than sufficient bewilderment. I don't understand your second paragraph. It has always been my understanding that all of the sharing models, specifications and working software in this arena have been based on actual use cases. Many of those use cases are documented or even explicit in the names of the efforts themselves. =A0- Tom Millar thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870=20 -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Wednesday, December 04, 2013 5:41 PM To: Chernin, Michael A.; mile@ietf.org Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect Thanks Tom & Aaron for sharing your feedback. These are helpful discussions. =20 I can assist on the MACCSA question for those not familiar as it is not in itself a format, but rather a framework that references and includes other efforts. It actually covers quite a bit from identity and access management through to sharing formats and protocols referencing work from several international standards bodies as appropriate. This was done to show that standards existed and could be combined to provide the necessary coverage without having to invent anything new. The work that proceeded MACCSA involved about 18 nations who had requirements for international standards (IETF, ISO, ITU, etc.) and the ability to update and evolve referenced standards as needed in the future. I think there are over 30 nations involved now. In addition to the MILE work, the MITRE work is mentioned and will be included more directly when it moves to a standards body. It is mentioned and described in the current version. Last time I looked at the MACCSA framework, it did not compare the formats as that is not the purpose of the framework. Many large efforts like the NATO CDXI for example, are looking IODEF, STIX, as well as OpenIOC to use what they need, where they need it. MACCSA is putting all of the pieces together. =20 In terms of comparisons, I see the formats as suitable for different use cases and think the report comes at a very good time as Aaron points out. Even within a use case, sharing between different entities could vary greatly and thus the requirements for exchange could vary. Privacy and information leakage concerns could limit what is used for sharing with certain parties and it may be desirable to just support a minimum baseline of what should be exchanged in those situations. For other exchanges (even in the same sharing model), richer data sets and information may be very important (Aaron's 4th bullet - I would say STIX is the most robust as capable depends on your use case and requirements. Not everyone can handle that much information as they are lacking analyst resources to deal with threat actors, campaigns, etc.). That's part of the reason I think use cases based sharing models are very important as well as having options to choose formats and protocols that meet your requirements. =20 Thanks again for all of your efforts on this report Romain! =20 Best regards, Kathleen =20 From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Chernin, Michael A. Sent: Wednesday, December 04, 2013 4:58 PM To: mile@ietf.org Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect =20 Thanks for the report Romain. I will second Mr. Millar that sections 1-3 provide valuable information regards to the barriers to sharing. =20 My concerns start in section 4, where the Data Exchange formats are compared. At our current sharing maturity level, people are doing a lot of research on specification selection, and during this time specification perception holds a lot of value. I am concerned about the primary image (Figure 6) used to open section 4. My input is below: =20 =B7 It's easy to imagine a standard/specification that can do everything. While there is an asterisk next to MACCSA stating that it's in the definition phase, the way it spans the entire chart gives it a superior perception to other more defined specifications like IODEF and STIX.=20 =B7 I am unable to locate a definition for Network and File observable columns on the chart. All the specifications compared have key coverage differences in these areas. =B7 Critical areas that both STIX and IODEF excel at, like = email, are missing as a column entirely =B7 Key observable columns that STIX excels at are missing entirely: Actors, Campaigns, TTP, Targeting, Windows objects, Unix objects, Privileges, Package Manager Data, User Account Data, DNS, etc. These missing columns make STIX appear less capable. If you add those columns in, than a completely different story is told and STIX appears the most capable.=20 =20 Thanks Aharon =20 DTCC Non-Confidential (White) =20 _____________________________________________________________=20 DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. From kathleen.moriarty@emc.com Thu Dec 5 07:57:24 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCD81ADF0F for ; Thu, 5 Dec 2013 07:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 6Vs4A-vtO4Xx for ; Thu, 5 Dec 2013 07:57:21 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1711AE059 for ; Thu, 5 Dec 2013 07:57:19 -0800 (PST) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB5FvDPR010027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Dec 2013 10:57:14 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com rB5FvDPR010027 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1386259035; bh=Vnazu7BH+ObRFhA1dPJkck9Cixc=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=DyJlvZVR8AveC80MPjU0GOYIWQPFp9ygYP9q9rjMDRAtG50XirRca9TC/Khk43+du i05SRTy0XNE2HdN9Mn0hTIMb26SMgYE5Koc2uYzhUnCcMd3U/Qv0Sf+jWtqZM7UuZ9 SyjwnMZDh1U3/fY3Y4EOlPDVC/JYtokQtm2XjBoM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com rB5FvDPR010027 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Thu, 5 Dec 2013 10:56:54 -0500 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB5FurCg023171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 10:56:53 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Thu, 5 Dec 2013 10:56:53 -0500 From: "Moriarty, Kathleen" To: "Thomas.Millar@us-cert.gov" , "mchernin@dtcc.com" , "mile@ietf.org" Date: Thu, 5 Dec 2013 10:56:51 -0500 Thread-Topic: [mile] New ENISA report: Detect, SHARE, Protect Thread-Index: Ac7xNskhr6bWWDMfTuWlQflrDAB0qQABdTpwACJvK8AAAp8sMA== Message-ID: References: <01FDD0EDFF2BFC47A89029A6B409322E91555D@bobcat.bronze.us-cert.gov> In-Reply-To: <01FDD0EDFF2BFC47A89029A6B409322E91555D@bobcat.bronze.us-cert.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: DLM_1, public Cc: "Dandurand Luc \(Luc.Dandurand@ncia.nato.int\)" Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 15:57:24 -0000 Hi Tom,=20 Thank you, this is a good discussion and your points are well taken! CDXI = and MACCSA could be separated out to show they fit into complimentary bucke= ts. It should not take a PhD to understand this stuff, but when we get it = right (hopefully soon) no one will have to know what any of these acronyms = are, it will just work. A white paper on CDXI was published through IEEE, so it may not have been r= ead as much due to the fee, not sure. CDXI is open in terms of the formats= and protocols used in their framework. Luc has presented on it externally= , I had the opportunity to see him present at RSA Europe in October and the= work is excellent. His presentation was extremely well-received. Maybe h= e can share some of the public information on this list? As for use cases, I agree a lot of the work has been focused on use cases, = but think some efforts have done better at the sharing model development th= an others. I think there are valuable lessons we can all learn as we build= out the space further to increase the success. I spent some time writing = my thoughts on the topic to help in a white paper and several blogs that ar= e intentionally neutral on formats/protocols as I think your sharing model = and requirements should be well-defined prior to any selection. Answers co= uld vary within a sharing model as well. Here are a few links for those th= at are interested in a deeper explanation of my use cases comment: RSA White paper: http://www.emc.com/collateral/emc-perspective/h12175-transf-expect-for-thre= at-intell-sharing.pdf=20 RSA Blogs: https://blogs.rsa.com/information-sharing-done-right-whats-useful-to-share-= and-who-should-get-it/=20 https://blogs.rsa.com/information-sharing-how-do-we-share-data-effectively/= =20 https://blogs.rsa.com/standards-matter-information-sharing/ Thanks, Kathleen -----Original Message----- From: Thomas.Millar@us-cert.gov [mailto:Thomas.Millar@us-cert.gov]=20 Sent: Thursday, December 05, 2013 10:00 AM To: Moriarty, Kathleen; mchernin@dtcc.com; mile@ietf.org Subject: RE: [mile] New ENISA report: Detect, SHARE, Protect Thank you Kathleen. I think some of the head-scratching stems from the fact that there is very = little out there to explain the "framework" efforts like MACCSA and CDXI. T= hat's especially problematic when trying to put them side by side against a= ctivities like STIX, TAXII, CybOX, CIF, AbuseHelper, and this WG. To clarif= y - each of those latter items I just mentioned has a public website with l= ots of information on the work, links to repositories of running code, majo= r commercial entities involved (several publicly announcing their involveme= nt, like Microsoft with regards to STIX), and most importantly to me, other= national CSIRTs actively participating. CDXI and MACCSA, as far as I can t= ell, have been discussed for years but I have yet to see how they actually = work or who is actually using them in an operational environment, or even i= n a testbed. You could throw NEISAS in the latter category as well, I suppo= se. I'm concerned that putting white paper frameworks up against actual specifi= cations and working software that people use every day can only lead to mor= e confusion in an arena where - as you and I have noted time and again - th= ere is already more than sufficient bewilderment. I don't understand your second paragraph. It has always been my understandi= ng that all of the sharing models, specifications and working software in t= his arena have been based on actual use cases. Many of those use cases are = documented or even explicit in the names of the efforts themselves. =A0- Tom Millar thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870=20 -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Wednesday, December 04, 2013 5:41 PM To: Chernin, Michael A.; mile@ietf.org Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect Thanks Tom & Aaron for sharing your feedback. These are helpful discussion= s. =20 I can assist on the MACCSA question for those not familiar as it is not in = itself a format, but rather a framework that references and includes other = efforts. It actually covers quite a bit from identity and access managemen= t through to sharing formats and protocols referencing work from several in= ternational standards bodies as appropriate. This was done to show that st= andards existed and could be combined to provide the necessary coverage wit= hout having to invent anything new. The work that proceeded MACCSA involve= d about 18 nations who had requirements for international standards (IETF, = ISO, ITU, etc.) and the ability to update and evolve referenced standards a= s needed in the future. I think there are over 30 nations involved now. I= n addition to the MILE work, the MITRE work is mentioned and will be includ= ed more directly when it moves to a standards body. It is mentioned and de= scribed in the current version. Last time I looked at the MACCSA framework= , it did not compare the formats as that is not the purpose of the framewor= k. Many large efforts like the NATO CDXI for example, are looking IODEF, S= TIX, as well as OpenIOC to use what they need, where they need it. MACCSA = is putting all of the pieces together. =20 In terms of comparisons, I see the formats as suitable for different use ca= ses and think the report comes at a very good time as Aaron points out. Ev= en within a use case, sharing between different entities could vary greatly= and thus the requirements for exchange could vary. Privacy and informatio= n leakage concerns could limit what is used for sharing with certain partie= s and it may be desirable to just support a minimum baseline of what should= be exchanged in those situations. For other exchanges (even in the same s= haring model), richer data sets and information may be very important (Aaro= n's 4th bullet - I would say STIX is the most robust as capable depends on = your use case and requirements. Not everyone can handle that much information as they are lacking analyst r= esources to deal with threat actors, campaigns, etc.). That's part of the = reason I think use cases based sharing models are very important as well as= having options to choose formats and protocols that meet your requirements= . =20 Thanks again for all of your efforts on this report Romain! =20 Best regards, Kathleen =20 From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Chernin, Michael A. Sent: Wednesday, December 04, 2013 4:58 PM To: mile@ietf.org Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect =20 Thanks for the report Romain. I will second Mr. Millar that sections 1-3 pr= ovide valuable information regards to the barriers to sharing. =20 My concerns start in section 4, where the Data Exchange formats are compare= d. At our current sharing maturity level, people are doing a lot of researc= h on specification selection, and during this time specification perception= holds a lot of value. I am concerned about the primary image (Figure 6) us= ed to open section 4. My input is below: =20 =B7 It's easy to imagine a standard/specification that can do everything. While there is an asterisk next to MACCSA stating that it's in = the definition phase, the way it spans the entire chart gives it a superior= perception to other more defined specifications like IODEF and STIX.=20 =B7 I am unable to locate a definition for Network and File observable columns on the chart. All the specifications compared have key c= overage differences in these areas. =B7 Critical areas that both STIX and IODEF excel at, like email, are missing as a column entirely =B7 Key observable columns that STIX excels at are missing entirely: Actors, Campaigns, TTP, Targeting, Windows objects, Unix objects= , Privileges, Package Manager Data, User Account Data, DNS, etc. These missing columns make STIX appear less capable. If you add those colum= ns in, than a completely different story is told and STIX appears the most = capable.=20 =20 Thanks Aharon =20 DTCC Non-Confidential (White) =20 _____________________________________________________________ DTCC DISCLAIMER: This email and any files transmitted with it are confident= ial and intended solely for the use of the individual or entity to whom the= y are addressed. If you have received this email in error, please notify us= immediately and delete the email and any attachments from your system. The= recipient should check this email and any attachments for the presence of = viruses. The company accepts no liability for any damage caused by any viru= s transmitted by this email. From kathleen.moriarty@emc.com Mon Dec 9 08:04:08 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA921AE341 for ; Mon, 9 Dec 2013 08:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 cSjHk8p5x4GE for ; Mon, 9 Dec 2013 08:04:05 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 579181AE36E for ; Mon, 9 Dec 2013 08:04:05 -0800 (PST) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB9G3xPO017013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Dec 2013 11:04:00 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com rB9G3xPO017013 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1386605040; bh=gGkDfwAA/qdJfzyFc7C3wtek2Kg=; h=From:To:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=gBN6d/aWpSe1jo0baCDQIGQg+r/JF6rLRzUQmOytoM8FvYu8hTQ8cDa+QFn8oj/fd +zFVg/f7NKg9pq1gf68nRyf1jMJiJfyZMI1crnw+aODQDBeYKpDomWXZbEU3VQHQ5Y nMklnrn43ULAlQOIHQa2nzn2hAyOYhvA2RMywLBI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com rB9G3xPO017013 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd53.lss.emc.com (RSA Interceptor) for ; Mon, 9 Dec 2013 11:03:45 -0500 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB9G3i4e030199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Dec 2013 11:03:45 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub14.corp.emc.com ([128.222.70.235]) with mapi; Mon, 9 Dec 2013 11:03:44 -0500 From: "Moriarty, Kathleen" To: "mile@ietf.org" Date: Mon, 9 Dec 2013 11:03:43 -0500 Thread-Topic: comments/review on draft-ietf-mile-iodef-guidance-02.txt Thread-Index: Ac709IO4yNZG2zJPQSanFWkPwBnnXw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: DLM_1, public Subject: [mile] comments/review on draft-ietf-mile-iodef-guidance-02.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:04:08 -0000 Hello Panos, Thank you for taking the time to update the IODEF-Guidance document. I hav= e a few comments and suggestions and encourage others to review and comment= so that we can progress the draft. It looks like several sections need co= ntent, if implementers would like to contribute content especially in secti= ons 3 & 4, that could be helpful. Also, if implementers have worked throug= h use cases and have guidance from lessons learned, that would be very usef= ul to incorporate as well in addition to the use cases Panos has outlined i= n the draft already. Section 4.4 Logic for watchlist of indicators I think adding in examples will be very helpful in this section to clearly = depict what is meant by each of the ways to represent the AND/OR logic. I'm still having trouble reading and understanding this section. We implem= ented the predicate logic based on initial discussions in our open source c= ode and follow different rules. The description we followed is included as= you can see it is different from the current draft and provides more consi= stency across each of the classes as was originally intended: For Node information, a watchlist of Systems means that the information is = ORed with the other information in the Flow section and an AND with rest of= the content in the EventData grouping. As such, we need to replicate this= pattern elsewhere, which is easy to do in the current format. For HashInf= ormation type, a watchlist type was added for each value to accommodate the= same pattern. In the Key class, a type was added with watchlist as an opt= ion as well. If the watchlist is used, the data provided is just that, a = watchlist of separate values. I think the current description that talks a= bout the watchlist-source and watchlist-destination confuse the logic and i= t could be stated more simply and consistently across the schema in terms o= f how the watchlist attribute effects the logic. Instead of the OR being w= ith the full Flow class, the initial intent was for it to be within the wat= chlist with an AND to the other items unless another watchlist was included= leaving you with a mesh of possibilities for the possible combinations one= may detect. In the 5th paragraph, I think this explanations introduces inconsistency in= the logic, I'll explain what I expected... In the Node class, if information is grouped together, it represents the sa= me thing (a single host, but the Node class could include all the informati= on about it - hostname, IP, AS number, etc.). With this pattern, if you se= t the type value for HashInformation to file_hash, the list provided are ju= st alternate representations for the same hash (sha256, sha1, md5, etc.). = For the Key information, it's a little different as the grouping without i= t would just be part of a joined event as opposed to alternate ways to repr= esent the same value. To keep the pattern consistent, I think it would mak= e sense to have the different Keys provided have the tags at the higher lev= el (WindowsRegistryKeyModified tag included), but have them all represented= within the same EventData instance. The included examples are following t= his logic pattern if examples are helpful to weigh in on this Alternatively, we could use separate EventData instances for each value, it= just adds a few more tags around each value, but accomplishes the same log= ic. =20 Once we get this adjusted, examples of each usage with an explanation would= be really helpful to ensure consistency in implementations. For the Appendix, the examples are good, but could you add a text descripti= on to explain the examples providing guidance as to decisions made in the r= epresentation for those use cases to help developers with consistent repres= entation of use cases as it made help reduce coding efforts.=20 If others would like to contribute examples with guidance to increase inte= roperability between implementations for specific use cases, PLEASE DO! Thank you, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Friday, October 18, 2013 2:50 PM To: i-d-announce@ietf.org Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-iodef-guidance-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange Wor= king Group of the IETF. Title : IODEF Usage Guidance Author(s) : Panos Kampanakis Filename : draft-ietf-mile-iodef-guidance-02.txt Pages : 19 Date : 2013-10-18 Abstract: The Incident Object Description Exchange Format [RFC5070] defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for implementers to develop tools that can Leverage IODEF for incident sharing. This document provides guidelines for IODEF implementers. It will also address how common security indicators can be represented in IODEF. The goal of this document is to make IODEF's adoption by vendors easier and encourage faster and wider adoption of the model by Computer Security Incident Response Teams (CSIRTs) around the world. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-iodef-guidance-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-iodef-guidance-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Mon Dec 9 08:19:09 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0201AE2A4 for ; Mon, 9 Dec 2013 08:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 CGh-a7dSh_xX for ; Mon, 9 Dec 2013 08:19:06 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 52E341ADF73 for ; Mon, 9 Dec 2013 08:19:06 -0800 (PST) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB9GIpG9020905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Dec 2013 11:18:54 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com rB9GIpG9020905 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1386605934; bh=ALGFHxn9BREpA23DDEEteywJ7GA=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=RPK4qi2HRKANY0otECpxUPpNHVmiNr4O+YFMlEC+O5f4PLklX4Txthcet6xjND5qG j+p/5abnDlQQP/YN2LNUhT/cGFMMIDD3ziZ0vwPGJyx9dGhJnFJd2gbvN8whxcs+gw IG7IXHxJF9RFBoLc+1Q/mBL+W7zRW+BiYNu8jAfQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com rB9GIpG9020905 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd52.lss.emc.com (RSA Interceptor); Mon, 9 Dec 2013 11:18:38 -0500 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.222.70.134]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB9GIcDT001575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 11:18:38 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub22.corp.emc.com ([128.222.70.134]) with mapi; Mon, 9 Dec 2013 11:18:38 -0500 From: "Moriarty, Kathleen" To: "Roman D. Danyliw" , "Panos Kampanakis (pkampana)" , "mile@ietf.org" Date: Mon, 9 Dec 2013 11:18:36 -0500 Thread-Topic: IODEF predicate logic Thread-Index: Ac6BljICQSOPLvR4RuCRb/L6J7DnMgKmeGjAAKx8x3AAKgYtIBlb+Gdw Message-ID: References: <1C9F17D1873AFA47A969C4DD98F98A753E59AE@xmb-rcd-x10.cisco.com> <359EC4B99E040048A7131E0F4E113AFC13C56E47@marathon> <1C9F17D1873AFA47A969C4DD98F98A750484C404@xmb-rcd-x10.cisco.com> <359EC4B99E040048A7131E0F4E113AFC13C5A1FB@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC13C5A1FB@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Subject: Re: [mile] IODEF predicate logic X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:19:09 -0000 Panos, I am re-sending this summary of previous questions to the list on the logic= included in the IODEF-Guidance so you and others don't have to dig it up. = I think when you include examples, it would be helpful to make sure these = questions are addressed with the updated description and logic. An explana= tion around each example would be helpful in this section to help implement= ers with consistency between implementations. Thanks! Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Rom= an D. Danyliw Sent: Monday, August 05, 2013 8:02 AM To: Panos Kampanakis (pkampana); mile@ietf.org Subject: Re: [mile] IODEF predicate logic Hi Panos, Response inline ... > -----Original Message----- > From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] > Sent: Thursday, August 01, 2013 2:56 PM > To: Roman D. Danyliw; mile@ietf.org > Subject: RE: IODEF predicate logic >=20 > Hi Roman, >=20 > Thank you for the comments. I answer them below. ">>>" is in front of=20 > your questions. >=20 > >>> In your email below you used the terminology "multiple=20 > >>> indicators on > one folder" which I hadn't read before. Did you mean multiple=20 > indicators in a single IODEF document? >=20 > Yes >=20 > >>> Isn't that reversed, "When an IODEF **System** consists of two or=20 > >>> more > **Node** classes with the category attribute set to watchlist-source=20 > or watchlist-destination ...", since Node sub-element of System? =20 > However, this isn't consistent with the -00 draft since System can=20 > only contain exactly 1 node. >=20 > You are right, it wasnot clear. I will rephrase it to something like "=20 > When a Flow Class that consists of multiple Systems with > watchlist-source and watchlist-destination attributes (watchlist of > Systems) the System information should be ORed for the Flow Class > described... " > Looks better? I'm still having a little bit of trouble. To reason about it, I listed the= interpretation of the example below into a series of parsing rules: (a) Multiple Systems in a given Flow are combined together into single expr= ession where each IP is OR-ed (b) Multiple Flow classes in a given EventData are combined into a series o= f expressions each AND-ed together Is that right? This leads me to ask the following questions: ** What's the semantics of multiple EventData classes into a parent EventDa= ta? ** What is the difference between annotating a System to be a watchlist-sou= rce or watchlist-destination? In the example XML snippet below, an express= ion of "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)" was created. How woul= d have using "watchlist-destination" have changed the expression? Is it th= at things marked as source warns of inbound connections to a network? ** Can one create a Flow with a System@category=3D"source" and System@categ= ory=3D"watchlist-source"? If so, what would that mean? ** Can one create an EventData with two Flows, one Flow has several System@= category=3D"watchlist-source" and another exclusively of several System@cat= egory=3D"source"? If so, what would that mean? ** Do these expressions only apply to the IP address, or other things that = can be indicators too? For example, say I had:
IP1
80
IP2
... =20 Would the expression be "(IP1 OR 80 OR IP2)"? "(IP1 AND 80 AND IP2)"? "((IP= 1 OR 80) OR IP2)"? "((IP1 AND 80) OR IP2)? What I'm asking is what is the= parsing rule of multiple indicators in a given Node? > >>> ... > >
IP1
... > >
IP2
... > >
IP3
... > >
IP4
... > >
IP5
... > >
IP6
... > > Is the watchlist defined as "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)"= ? >=20 > Yes. If an company saw IP1 or 2 or 3 only they should not think they=20 > are seeing the indicator. > > >>> Is this AND logic applied across different Flow classes or any=20 > >>> other > indicator in the EventData class parent outside of the Flow parent of=20 > the given System class of interest? >=20 > Yes, I will rephrase it to " The content in > the EventData Class the Node belongs to should be combined with > the watchlist of Systems using AND logic.=20 It's the use of Node here that still confuses me since a Node is inside a S= ystem. Could you express this sentence as a parsing statement like above? > Different Flow > classes > that consist of different System classes (with watchlist-source > or destination as attributes) follow AND logic in their parent > EventData Class. " > in order to make it clearer. Makes more sense? The double use of different confuses me also. Do you mean "Distinct Flow c= lasses with the same parent EventData classes are ANDed together", aka pars= ing rule (b) from above? Roman =20 > Panos >=20 >=20 >=20 > -----Original Message----- > From: Roman D. Danyliw [mailto:rdd@cert.org] > Sent: Tuesday, July 30, 2013 5:54 AM > To: Panos Kampanakis (pkampana); mile@ietf.org > Subject: RE: IODEF predicate logic >=20 > Hi Panos! >=20 > Could you describe a little more about what you had in mind with the=20 > predicate logic? In your email below you used the terminology =20 > "multiple indicators on one folder" which I hadn't read before. Did=20 > you mean multiple indicators in a single IODEF document? >=20 > In seeking clarity in Section 4.4 of draft-ietf-mile-iodef-guidance-01=20 > I had a few questions. Citing this section ... >=20 > > [I-D.ietf-mile-rfc5070-bis] defines two new category attributes in=20 > > the System Class. These are watchlist-source and watchlist-=20 > > destination and they serve for watchlist indicator groupings. When=20 > > an IODEF Node consists of two or more System Classes with various=20 > > watchlist-source and watchlist-destination attributes (watchlist of > > Systems) >=20 > Isn't that reversed, "When an IODEF **System** consists of two or=20 > more > **Node** classes with the category attribute set to watchlist-source=20 > or watchlist-destination ...", since Node sub-element of System? =20 > However, this isn't consistent with the -00 draft since System can=20 > only contain exactly 1 node. >=20 > [snip] > > > > ... >=20 > > the System information should be ORed with the information in the=20 > > Flow Class. >=20 > Could you clarify what it means to be OR multiple Systems in the flow cla= ss? > For example, with a snippet as follows, >=20 > ... > >
IP1
... > >
IP2
... > >
IP3
... > >
IP4
... > >
IP5
... > >
IP6
... > >=20 > Is the watchlist defined as "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)"= ? >=20 > > In other words, either System description should be considered as a=20 > > watchlist indicator. The rest of the content in the EventData Class=20 > > the Node belongs to should be combined with the watchlist of Systems=20 > > using AND logic. >=20 > Is this AND logic applied across different Flow classes or any other=20 > indicator in the EventData class parent outside of the Flow parent of=20 > the given System class of interest? >=20 > Roman >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Panos Kampanakis (pkampana) > Sent: Monday, July 15, 2013 4:02 PM > To: mile@ietf.org > Subject: [mile] IODEF predicate logic >=20 > Hello everyone, >=20 > In the past people have asked how IODEF can combine multiple=20 > indicators in one IODEF definition. For example a question can be, if=20 > there are more than two malicious addresses, how they can be added in=20 > one definition and what is the logic behind how they are combined? >=20 > draft-ietf-mile-rfc5070-bis-00 introduces some watchlist fields that=20 > allow for multiple indicators on one folder. In=20 > draft-ietf-mile-iodef-guidance-01 I have added section=20 > http://tools.ietf.org/html/draft-ietf-mile-iodef-guidance- > 01#section-4.4 that describes how the predicate logic works. >=20 > Comments and thoughts are welcome. >=20 > Rgs, > Panos _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Wed Dec 11 07:18:23 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8200E1AC421 for ; Wed, 11 Dec 2013 07:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 1AV3OMLvQCbY for ; Wed, 11 Dec 2013 07:18:20 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id D05311ADEBF for ; Wed, 11 Dec 2013 07:18:19 -0800 (PST) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBBFIApw003139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Dec 2013 10:18:13 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com rBBFIApw003139 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1386775093; bh=a6slicHz1aSc6/ffTrWUwmOUfrk=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=KOa7Ur+lMSnCnJiNialadoev8xwHi541rAbcrq4rfAUGdhz+bwEp6i6jJgiqNwJu3 ZDf/uI3kjbajMmxhecfdYgc4wx/eKy1aTuOlj6j9IlZ+EldVTCkZJhiWlhDVNQEe44 wknutuUhnC4V/Qz+c/e1DWitPkZshyFSkJVKKGVk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com rBBFIApw003139 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd06.lss.emc.com (RSA Interceptor); Wed, 11 Dec 2013 07:18:01 -0800 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBBFI0H0006864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 10:18:00 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Wed, 11 Dec 2013 10:18:00 -0500 From: "Moriarty, Kathleen" To: Trey Darley , "Dandurand Luc (Luc.Dandurand@ncia.nato.int)" Date: Wed, 11 Dec 2013 10:17:59 -0500 Thread-Topic: [mile] New ENISA report: Detect, SHARE, Protect Thread-Index: AQHO8dKSpveWCmebgUWUuyg4hMfc05pPnzwA//+EnIA= Message-ID: References: <01FDD0EDFF2BFC47A89029A6B409322E91555D@bobcat.bronze.us-cert.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Cc: "mile@ietf.org" Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 15:18:23 -0000 Hello, Trey. I believe this is the right link to the CDXI paper. Luc is on the list, so= he may chime in if he sees this. A search for "CDXI Dandurand" turns up p= revious presentations he has given as well if that is helpful. http://ieeexplore.ieee.org/xpl/login.jsp?tp=3D&arnumber=3D6568369&url=3Dhtt= p%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6568369 The paper turned up in the first page of links from Google with those searc= h terms and has the title, "Towards Improved Cyber Security Information Sha= ring". Best regards, Kathleen -----Original Message----- From: Trey Darley [mailto:tdarley@splunk.com]=20 Sent: Wednesday, December 11, 2013 8:36 AM To: Moriarty, Kathleen Cc: mile@ietf.org Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect Hi, Kathleen - Have you got a link to the IEEE CDXI whitepaper handy? IEEE is great but th= eir site nav / search...not so much. Thanks! Cheers, Trey -- Trey Darley Minister of Foreign Affairs Brussels > Cupertino Seattle London Hong Kong Washington D.C. Plano San Francisco Singapore Munich Paris Splunk > because specialisation = is for insects On 05.12.13 16:56, "Moriarty, Kathleen" wrote: >Hi Tom, > >Thank you, this is a good discussion and your points are well taken! >CDXI and MACCSA could be separated out to show they fit into=20 >complimentary buckets. It should not take a PhD to understand this=20 >stuff, but when we get it right (hopefully soon) no one will have to=20 >know what any of these acronyms are, it will just work. > >A white paper on CDXI was published through IEEE, so it may not have=20 >been read as much due to the fee, not sure. CDXI is open in terms of=20 >the formats and protocols used in their framework. Luc has presented=20 >on it externally, I had the opportunity to see him present at RSA=20 >Europe in October and the work is excellent. His presentation was=20 >extremely well-received. Maybe he can share some of the public=20 >information on this list? > >As for use cases, I agree a lot of the work has been focused on use=20 >cases, but think some efforts have done better at the sharing model=20 >development than others. I think there are valuable lessons we can all=20 >learn as we build out the space further to increase the success. I=20 >spent some time writing my thoughts on the topic to help in a white=20 >paper and several blogs that are intentionally neutral on=20 >formats/protocols as I think your sharing model and requirements should=20 >be well-defined prior to any selection. Answers could vary within a=20 >sharing model as well. Here are a few links for those that are=20 >interested in a deeper explanation of my use cases comment: > >RSA White paper: >http://www.emc.com/collateral/emc-perspective/h12175-transf-expect-for- >thr >eat-intell-sharing.pdf > >RSA Blogs: >https://blogs.rsa.com/information-sharing-done-right-whats-useful-to-sh >are >-and-who-should-get-it/ >https://blogs.rsa.com/information-sharing-how-do-we-share-data-effectiv >ely >/ >https://blogs.rsa.com/standards-matter-information-sharing/ > >Thanks, >Kathleen > >-----Original Message----- >From: Thomas.Millar@us-cert.gov [mailto:Thomas.Millar@us-cert.gov] >Sent: Thursday, December 05, 2013 10:00 AM >To: Moriarty, Kathleen; mchernin@dtcc.com; mile@ietf.org >Subject: RE: [mile] New ENISA report: Detect, SHARE, Protect > >Thank you Kathleen. > >I think some of the head-scratching stems from the fact that there is=20 >very little out there to explain the "framework" efforts like MACCSA=20 >and CDXI. That's especially problematic when trying to put them side by=20 >side against activities like STIX, TAXII, CybOX, CIF, AbuseHelper, and=20 >this WG. To clarify - each of those latter items I just mentioned has a=20 >public website with lots of information on the work, links to=20 >repositories of running code, major commercial entities involved=20 >(several publicly announcing their involvement, like Microsoft with=20 >regards to STIX), and most importantly to me, other national CSIRTs active= ly participating. >CDXI and MACCSA, as far as I can tell, have been discussed for years=20 >but I have yet to see how they actually work or who is actually using=20 >them in an operational environment, or even in a testbed. You could=20 >throw NEISAS in the latter category as well, I suppose. > >I'm concerned that putting white paper frameworks up against actual=20 >specifications and working software that people use every day can only=20 >lead to more confusion in an arena where - as you and I have noted time=20 >and again - there is already more than sufficient bewilderment. > >I don't understand your second paragraph. It has always been my=20 >understanding that all of the sharing models, specifications and=20 >working software in this arena have been based on actual use cases.=20 >Many of those use cases are documented or even explicit in the names of=20 >the efforts themselves. > > - Tom Millar > >thomas.millar@us-cert.gov >BB: thomas.millar@dhs.gov / 202-631-1915 >24x7: soc@us-cert.gov / 888-282-0870 > >-----Original Message----- >From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty,=20 >Kathleen >Sent: Wednesday, December 04, 2013 5:41 PM >To: Chernin, Michael A.; mile@ietf.org >Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect > >Thanks Tom & Aaron for sharing your feedback. These are helpful=20 >discussions. > >=20 > >I can assist on the MACCSA question for those not familiar as it is not=20 >in itself a format, but rather a framework that references and includes=20 >other efforts. It actually covers quite a bit from identity and access=20 >management through to sharing formats and protocols referencing work=20 >from several international standards bodies as appropriate. This was=20 >done to show that standards existed and could be combined to provide=20 >the necessary coverage without having to invent anything new. The work=20 >that proceeded MACCSA involved about 18 nations who had requirements=20 >for international standards (IETF, ISO, ITU, etc.) and the ability to=20 >update and evolve referenced standards as needed in the future. I=20 >think there are over 30 nations involved now. In addition to the MILE=20 >work, the MITRE work is mentioned and will be included more directly=20 >when it moves to a standards body. It is mentioned and described in=20 >the current version. Last time I looked at the MACCSA framework, it=20 >did not compare the formats as that is not the purpose of the=20 >framework. Many large efforts like the NATO CDXI for example, are=20 >looking IODEF, STIX, as well as OpenIOC to use what they need, where=20 >they need it. MACCSA is putting all of the pieces together. > >=20 > >In terms of comparisons, I see the formats as suitable for different=20 >use cases and think the report comes at a very good time as Aaron points o= ut. > Even within a use case, sharing between different entities could vary=20 >greatly and thus the requirements for exchange could vary. Privacy and=20 >information leakage concerns could limit what is used for sharing with=20 >certain parties and it may be desirable to just support a minimum=20 >baseline of what should be exchanged in those situations. For other=20 >exchanges (even in the same sharing model), richer data sets and=20 >information may be very important (Aaron's 4th bullet - I would say=20 >STIX is the most robust as capable depends on your use case and requiremen= ts. >Not everyone can handle that much information as they are lacking=20 >analyst resources to deal with threat actors, campaigns, etc.). That's=20 >part of the reason I think use cases based sharing models are very=20 >important as well as having options to choose formats and protocols=20 >that meet your requirements. > >=20 > >Thanks again for all of your efforts on this report Romain! > >=20 > >Best regards, > >Kathleen > >=20 > >From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Chernin, Michael A. >Sent: Wednesday, December 04, 2013 4:58 PM >To: mile@ietf.org >Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect > >=20 > >Thanks for the report Romain. I will second Mr. Millar that sections=20 >1-3 provide valuable information regards to the barriers to sharing. > >=20 > >My concerns start in section 4, where the Data Exchange formats are=20 >compared. At our current sharing maturity level, people are doing a lot=20 >of research on specification selection, and during this time=20 >specification perception holds a lot of value. I am concerned about the=20 >primary image (Figure 6) used to open section 4. My input is below: > >=20 > >* It's easy to imagine a standard/specification that can do >everything. While there is an asterisk next to MACCSA stating that it's=20 >in the definition phase, the way it spans the entire chart gives it a=20 >superior perception to other more defined specifications like IODEF and=20 >STIX. > >* I am unable to locate a definition for Network and File >observable columns on the chart. All the specifications compared have=20 >key coverage differences in these areas. > >* Critical areas that both STIX and IODEF excel at, like email, >are missing as a column entirely > >* Key observable columns that STIX excels at are missing >entirely: Actors, Campaigns, TTP, Targeting, Windows objects, Unix=20 >objects, Privileges, Package Manager Data, User Account Data, DNS, etc. >These missing columns make STIX appear less capable. If you add those=20 >columns in, than a completely different story is told and STIX appears=20 >the most capable. > >=20 > >Thanks > >Aharon > >=20 > >DTCC Non-Confidential (White) > >=20 > > >_____________________________________________________________ >DTCC DISCLAIMER: This email and any files transmitted with it are=20 >confidential and intended solely for the use of the individual or=20 >entity to whom they are addressed. If you have received this email in=20 >error, please notify us immediately and delete the email and any=20 >attachments from your system. The recipient should check this email and=20 >any attachments for the presence of viruses. The company accepts no=20 >liability for any damage caused by any virus transmitted by this email. > > >_______________________________________________ >mile mailing list >mile@ietf.org >https://www.ietf.org/mailman/listinfo/mile From tdarley@splunk.com Wed Dec 11 05:36:43 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FED71ADE7C for ; Wed, 11 Dec 2013 05:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-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 g70bxaWoopNL for ; Wed, 11 Dec 2013 05:36:40 -0800 (PST) Received: from pfe111-vx-1.mail.splunk.com (pfe111-vx-1.mail.splunk.com [64.78.52.101]) by ietfa.amsl.com (Postfix) with ESMTP id 948C81ADBE5 for ; Wed, 11 Dec 2013 05:36:40 -0800 (PST) Received: from PMBX111-W1-VX-2.pexch111.serverpod.net ([10.254.185.52]) by PFE111-VX-1.pexch111.serverpod.net ([10.254.185.16]) with mapi id 14.03.0158.001; Wed, 11 Dec 2013 05:36:22 -0800 From: Trey Darley To: "Moriarty, Kathleen" Thread-Topic: [mile] New ENISA report: Detect, SHARE, Protect Thread-Index: AQHO8dKSpveWCmebgUWUuyg4hMfc05pPnzwA Date: Wed, 11 Dec 2013 13:36:21 +0000 Message-ID: References: <01FDD0EDFF2BFC47A89029A6B409322E91555D@bobcat.bronze.us-cert.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [77.109.79.78] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 11 Dec 2013 14:28:22 -0800 Cc: "mile@ietf.org" Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 13:37:34 -0000 Hi, Kathleen - Have you got a link to the IEEE CDXI whitepaper handy? IEEE is great but their site nav / search...not so much. Thanks! Cheers, Trey -- Trey Darley Minister of Foreign Affairs Brussels > Cupertino Seattle London Hong Kong Washington D.C. Plano San Francisco Singapore Munich Paris Splunk > because specialisation is for insects On 05.12.13 16:56, "Moriarty, Kathleen" wrote: >Hi Tom,=20 > >Thank you, this is a good discussion and your points are well taken! >CDXI and MACCSA could be separated out to show they fit into >complimentary buckets. It should not take a PhD to understand this >stuff, but when we get it right (hopefully soon) no one will have to know >what any of these acronyms are, it will just work. > >A white paper on CDXI was published through IEEE, so it may not have been >read as much due to the fee, not sure. CDXI is open in terms of the >formats and protocols used in their framework. Luc has presented on it >externally, I had the opportunity to see him present at RSA Europe in >October and the work is excellent. His presentation was extremely >well-received. Maybe he can share some of the public information on this >list? > >As for use cases, I agree a lot of the work has been focused on use >cases, but think some efforts have done better at the sharing model >development than others. I think there are valuable lessons we can all >learn as we build out the space further to increase the success. I spent >some time writing my thoughts on the topic to help in a white paper and >several blogs that are intentionally neutral on formats/protocols as I >think your sharing model and requirements should be well-defined prior to >any selection. Answers could vary within a sharing model as well. Here >are a few links for those that are interested in a deeper explanation of >my use cases comment: > >RSA White paper: >http://www.emc.com/collateral/emc-perspective/h12175-transf-expect-for-thr >eat-intell-sharing.pdf > >RSA Blogs: >https://blogs.rsa.com/information-sharing-done-right-whats-useful-to-share >-and-who-should-get-it/ >https://blogs.rsa.com/information-sharing-how-do-we-share-data-effectively >/=20 >https://blogs.rsa.com/standards-matter-information-sharing/ > >Thanks, >Kathleen > >-----Original Message----- >From: Thomas.Millar@us-cert.gov [mailto:Thomas.Millar@us-cert.gov] >Sent: Thursday, December 05, 2013 10:00 AM >To: Moriarty, Kathleen; mchernin@dtcc.com; mile@ietf.org >Subject: RE: [mile] New ENISA report: Detect, SHARE, Protect > >Thank you Kathleen. > >I think some of the head-scratching stems from the fact that there is >very little out there to explain the "framework" efforts like MACCSA and >CDXI. That's especially problematic when trying to put them side by side >against activities like STIX, TAXII, CybOX, CIF, AbuseHelper, and this >WG. To clarify - each of those latter items I just mentioned has a public >website with lots of information on the work, links to repositories of >running code, major commercial entities involved (several publicly >announcing their involvement, like Microsoft with regards to STIX), and >most importantly to me, other national CSIRTs actively participating. >CDXI and MACCSA, as far as I can tell, have been discussed for years but >I have yet to see how they actually work or who is actually using them in >an operational environment, or even in a testbed. You could throw NEISAS >in the latter category as well, I suppose. > >I'm concerned that putting white paper frameworks up against actual >specifications and working software that people use every day can only >lead to more confusion in an arena where - as you and I have noted time >and again - there is already more than sufficient bewilderment. > >I don't understand your second paragraph. It has always been my >understanding that all of the sharing models, specifications and working >software in this arena have been based on actual use cases. Many of those >use cases are documented or even explicit in the names of the efforts >themselves. > > - Tom Millar > >thomas.millar@us-cert.gov >BB: thomas.millar@dhs.gov / 202-631-1915 >24x7: soc@us-cert.gov / 888-282-0870 > >-----Original Message----- >From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen >Sent: Wednesday, December 04, 2013 5:41 PM >To: Chernin, Michael A.; mile@ietf.org >Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect > >Thanks Tom & Aaron for sharing your feedback. These are helpful >discussions. > >=20 > >I can assist on the MACCSA question for those not familiar as it is not >in itself a format, but rather a framework that references and includes >other efforts. It actually covers quite a bit from identity and access >management through to sharing formats and protocols referencing work from >several international standards bodies as appropriate. This was done to >show that standards existed and could be combined to provide the >necessary coverage without having to invent anything new. The work that >proceeded MACCSA involved about 18 nations who had requirements for >international standards (IETF, ISO, ITU, etc.) and the ability to update >and evolve referenced standards as needed in the future. I think there >are over 30 nations involved now. In addition to the MILE work, the >MITRE work is mentioned and will be included more directly when it moves >to a standards body. It is mentioned and described in the current >version. Last time I looked at the MACCSA framework, it did not compare >the formats as that is not the purpose of the framework. Many large >efforts like the NATO CDXI for example, are looking IODEF, STIX, as well >as OpenIOC to use what they need, where they need it. MACCSA is putting >all of the pieces together. > >=20 > >In terms of comparisons, I see the formats as suitable for different use >cases and think the report comes at a very good time as Aaron points out. > Even within a use case, sharing between different entities could vary >greatly and thus the requirements for exchange could vary. Privacy and >information leakage concerns could limit what is used for sharing with >certain parties and it may be desirable to just support a minimum >baseline of what should be exchanged in those situations. For other >exchanges (even in the same sharing model), richer data sets and >information may be very important (Aaron's 4th bullet - I would say STIX >is the most robust as capable depends on your use case and requirements. >Not everyone can handle that much information as they are lacking analyst >resources to deal with threat actors, campaigns, etc.). That's part of >the reason I think use cases based sharing models are very important as >well as having options to choose formats and protocols that meet your >requirements. > >=20 > >Thanks again for all of your efforts on this report Romain! > >=20 > >Best regards, > >Kathleen > >=20 > >From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Chernin, Michael A. >Sent: Wednesday, December 04, 2013 4:58 PM >To: mile@ietf.org >Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect > >=20 > >Thanks for the report Romain. I will second Mr. Millar that sections 1-3 >provide valuable information regards to the barriers to sharing. > >=20 > >My concerns start in section 4, where the Data Exchange formats are >compared. At our current sharing maturity level, people are doing a lot >of research on specification selection, and during this time >specification perception holds a lot of value. I am concerned about the >primary image (Figure 6) used to open section 4. My input is below: > >=20 > >=B7 It's easy to imagine a standard/specification that can do >everything. While there is an asterisk next to MACCSA stating that it's >in the definition phase, the way it spans the entire chart gives it a >superior perception to other more defined specifications like IODEF and >STIX.=20 > >=B7 I am unable to locate a definition for Network and File >observable columns on the chart. All the specifications compared have key >coverage differences in these areas. > >=B7 Critical areas that both STIX and IODEF excel at, like email, >are missing as a column entirely > >=B7 Key observable columns that STIX excels at are missing >entirely: Actors, Campaigns, TTP, Targeting, Windows objects, Unix >objects, Privileges, Package Manager Data, User Account Data, DNS, etc. >These missing columns make STIX appear less capable. If you add those >columns in, than a completely different story is told and STIX appears >the most capable.=20 > >=20 > >Thanks > >Aharon > >=20 > >DTCC Non-Confidential (White) > >=20 > > >_____________________________________________________________ >DTCC DISCLAIMER: This email and any files transmitted with it are >confidential and intended solely for the use of the individual or entity >to whom they are addressed. If you have received this email in error, >please notify us immediately and delete the email and any attachments >from your system. The recipient should check this email and any >attachments for the presence of viruses. The company accepts no liability >for any damage caused by any virus transmitted by this email. > > >_______________________________________________ >mile mailing list >mile@ietf.org >https://www.ietf.org/mailman/listinfo/mile From tdarley@splunk.com Wed Dec 11 07:23:29 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F150B1ADFC6 for ; Wed, 11 Dec 2013 07:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 JcWZjEkRTsDi for ; Wed, 11 Dec 2013 07:23:26 -0800 (PST) Received: from pfe111-vx-2.mail.splunk.com (pfe111-vx-2.mail.splunk.com [64.78.52.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3C31ADF89 for ; Wed, 11 Dec 2013 07:23:26 -0800 (PST) Received: from PMBX111-W1-VX-2.pexch111.serverpod.net ([10.254.185.52]) by PFE111-VX-2.pexch111.serverpod.net ([10.254.185.18]) with mapi id 14.03.0158.001; Wed, 11 Dec 2013 07:23:07 -0800 From: Trey Darley To: "Moriarty, Kathleen" , "Dandurand Luc (Luc.Dandurand@ncia.nato.int)" Thread-Topic: [mile] New ENISA report: Detect, SHARE, Protect Thread-Index: AQHO8dKSpveWCmebgUWUuyg4hMfc05pPnzwA//+EnICAAAHz1w== Date: Wed, 11 Dec 2013 15:23:06 +0000 Message-ID: <71D62665CFED8841BEC5690C2AA29FA206ADC3@PMBX111-W1-VX-2.pexch111.serverpod.net> References: <01FDD0EDFF2BFC47A89029A6B409322E91555D@bobcat.bronze.us-cert.gov> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [77.109.79.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 11 Dec 2013 14:28:22 -0800 Cc: "mile@ietf.org" Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 15:23:29 -0000 Hi, Kathleen - Thanks! I mistakenly assumed that searching on ieee.org included search res= ults for ieeexplore.ieee.org. Google-fu ftw! Cheers, Trey -- Trey Darley Minister of Foreign Affairs Brussels > Cupertino Seattle London Hong Kong Washington D.C. Plano San Francisco Singapore Munich Paris Splunk > because specialisation is for insects ________________________________________ From: Moriarty, Kathleen [kathleen.moriarty@emc.com] Sent: Wednesday, December 11, 2013 16:17 To: Trey Darley; Dandurand Luc (Luc.Dandurand@ncia.nato.int) Cc: mile@ietf.org Subject: RE: [mile] New ENISA report: Detect, SHARE, Protect Hello, Trey. I believe this is the right link to the CDXI paper. Luc is on the list, so= he may chime in if he sees this. A search for "CDXI Dandurand" turns up p= revious presentations he has given as well if that is helpful. http://ieeexplore.ieee.org/xpl/login.jsp?tp=3D&arnumber=3D6568369&url=3Dhtt= p%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6568369 The paper turned up in the first page of links from Google with those searc= h terms and has the title, "Towards Improved Cyber Security Information Sha= ring". Best regards, Kathleen -----Original Message----- From: Trey Darley [mailto:tdarley@splunk.com] Sent: Wednesday, December 11, 2013 8:36 AM To: Moriarty, Kathleen Cc: mile@ietf.org Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect Hi, Kathleen - Have you got a link to the IEEE CDXI whitepaper handy? IEEE is great but th= eir site nav / search...not so much. Thanks! Cheers, Trey -- Trey Darley Minister of Foreign Affairs Brussels > Cupertino Seattle London Hong Kong Washington D.C. Plano San Francisco Singapore Munich Paris Splunk > because specialisation = is for insects On 05.12.13 16:56, "Moriarty, Kathleen" wrote: >Hi Tom, > >Thank you, this is a good discussion and your points are well taken! >CDXI and MACCSA could be separated out to show they fit into >complimentary buckets. It should not take a PhD to understand this >stuff, but when we get it right (hopefully soon) no one will have to >know what any of these acronyms are, it will just work. > >A white paper on CDXI was published through IEEE, so it may not have >been read as much due to the fee, not sure. CDXI is open in terms of >the formats and protocols used in their framework. Luc has presented >on it externally, I had the opportunity to see him present at RSA >Europe in October and the work is excellent. His presentation was >extremely well-received. Maybe he can share some of the public >information on this list? > >As for use cases, I agree a lot of the work has been focused on use >cases, but think some efforts have done better at the sharing model >development than others. I think there are valuable lessons we can all >learn as we build out the space further to increase the success. I >spent some time writing my thoughts on the topic to help in a white >paper and several blogs that are intentionally neutral on >formats/protocols as I think your sharing model and requirements should >be well-defined prior to any selection. Answers could vary within a >sharing model as well. Here are a few links for those that are >interested in a deeper explanation of my use cases comment: > >RSA White paper: >http://www.emc.com/collateral/emc-perspective/h12175-transf-expect-for- >thr >eat-intell-sharing.pdf > >RSA Blogs: >https://blogs.rsa.com/information-sharing-done-right-whats-useful-to-sh >are >-and-who-should-get-it/ >https://blogs.rsa.com/information-sharing-how-do-we-share-data-effectiv >ely >/ >https://blogs.rsa.com/standards-matter-information-sharing/ > >Thanks, >Kathleen > >-----Original Message----- >From: Thomas.Millar@us-cert.gov [mailto:Thomas.Millar@us-cert.gov] >Sent: Thursday, December 05, 2013 10:00 AM >To: Moriarty, Kathleen; mchernin@dtcc.com; mile@ietf.org >Subject: RE: [mile] New ENISA report: Detect, SHARE, Protect > >Thank you Kathleen. > >I think some of the head-scratching stems from the fact that there is >very little out there to explain the "framework" efforts like MACCSA >and CDXI. That's especially problematic when trying to put them side by >side against activities like STIX, TAXII, CybOX, CIF, AbuseHelper, and >this WG. To clarify - each of those latter items I just mentioned has a >public website with lots of information on the work, links to >repositories of running code, major commercial entities involved >(several publicly announcing their involvement, like Microsoft with >regards to STIX), and most importantly to me, other national CSIRTs active= ly participating. >CDXI and MACCSA, as far as I can tell, have been discussed for years >but I have yet to see how they actually work or who is actually using >them in an operational environment, or even in a testbed. You could >throw NEISAS in the latter category as well, I suppose. > >I'm concerned that putting white paper frameworks up against actual >specifications and working software that people use every day can only >lead to more confusion in an arena where - as you and I have noted time >and again - there is already more than sufficient bewilderment. > >I don't understand your second paragraph. It has always been my >understanding that all of the sharing models, specifications and >working software in this arena have been based on actual use cases. >Many of those use cases are documented or even explicit in the names of >the efforts themselves. > > - Tom Millar > >thomas.millar@us-cert.gov >BB: thomas.millar@dhs.gov / 202-631-1915 >24x7: soc@us-cert.gov / 888-282-0870 > >-----Original Message----- >From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, >Kathleen >Sent: Wednesday, December 04, 2013 5:41 PM >To: Chernin, Michael A.; mile@ietf.org >Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect > >Thanks Tom & Aaron for sharing your feedback. These are helpful >discussions. > > > >I can assist on the MACCSA question for those not familiar as it is not >in itself a format, but rather a framework that references and includes >other efforts. It actually covers quite a bit from identity and access >management through to sharing formats and protocols referencing work >from several international standards bodies as appropriate. This was >done to show that standards existed and could be combined to provide >the necessary coverage without having to invent anything new. The work >that proceeded MACCSA involved about 18 nations who had requirements >for international standards (IETF, ISO, ITU, etc.) and the ability to >update and evolve referenced standards as needed in the future. I >think there are over 30 nations involved now. In addition to the MILE >work, the MITRE work is mentioned and will be included more directly >when it moves to a standards body. It is mentioned and described in >the current version. Last time I looked at the MACCSA framework, it >did not compare the formats as that is not the purpose of the >framework. Many large efforts like the NATO CDXI for example, are >looking IODEF, STIX, as well as OpenIOC to use what they need, where >they need it. MACCSA is putting all of the pieces together. > > > >In terms of comparisons, I see the formats as suitable for different >use cases and think the report comes at a very good time as Aaron points o= ut. > Even within a use case, sharing between different entities could vary >greatly and thus the requirements for exchange could vary. Privacy and >information leakage concerns could limit what is used for sharing with >certain parties and it may be desirable to just support a minimum >baseline of what should be exchanged in those situations. For other >exchanges (even in the same sharing model), richer data sets and >information may be very important (Aaron's 4th bullet - I would say >STIX is the most robust as capable depends on your use case and requiremen= ts. >Not everyone can handle that much information as they are lacking >analyst resources to deal with threat actors, campaigns, etc.). That's >part of the reason I think use cases based sharing models are very >important as well as having options to choose formats and protocols >that meet your requirements. > > > >Thanks again for all of your efforts on this report Romain! > > > >Best regards, > >Kathleen > > > >From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Chernin, Michael A. >Sent: Wednesday, December 04, 2013 4:58 PM >To: mile@ietf.org >Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect > > > >Thanks for the report Romain. I will second Mr. Millar that sections >1-3 provide valuable information regards to the barriers to sharing. > > > >My concerns start in section 4, where the Data Exchange formats are >compared. At our current sharing maturity level, people are doing a lot >of research on specification selection, and during this time >specification perception holds a lot of value. I am concerned about the >primary image (Figure 6) used to open section 4. My input is below: > > > >* It's easy to imagine a standard/specification that can do >everything. While there is an asterisk next to MACCSA stating that it's >in the definition phase, the way it spans the entire chart gives it a >superior perception to other more defined specifications like IODEF and >STIX. > >* I am unable to locate a definition for Network and File >observable columns on the chart. All the specifications compared have >key coverage differences in these areas. > >* Critical areas that both STIX and IODEF excel at, like email, >are missing as a column entirely > >* Key observable columns that STIX excels at are missing >entirely: Actors, Campaigns, TTP, Targeting, Windows objects, Unix >objects, Privileges, Package Manager Data, User Account Data, DNS, etc. >These missing columns make STIX appear less capable. If you add those >columns in, than a completely different story is told and STIX appears >the most capable. > > > >Thanks > >Aharon > > > >DTCC Non-Confidential (White) > > > > >_____________________________________________________________ >DTCC DISCLAIMER: This email and any files transmitted with it are >confidential and intended solely for the use of the individual or >entity to whom they are addressed. If you have received this email in >error, please notify us immediately and delete the email and any >attachments from your system. The recipient should check this email and >any attachments for the presence of viruses. The company accepts no >liability for any damage caused by any virus transmitted by this email. > > >_______________________________________________ >mile mailing list >mile@ietf.org >https://www.ietf.org/mailman/listinfo/mile From merike.kaeo@internetidentity.com Wed Dec 11 14:19:51 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1851AE0DC for ; Wed, 11 Dec 2013 14:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 xkgWj4v2o_UN for ; Wed, 11 Dec 2013 14:19:48 -0800 (PST) Received: from mail.internetidentity.com (mail.internetidentity.com [66.150.9.152]) by ietfa.amsl.com (Postfix) with ESMTP id 04FCC1ADDD2 for ; Wed, 11 Dec 2013 14:19:47 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.internetidentity.com (Postfix) with ESMTP id 6092345C095C; Wed, 11 Dec 2013 14:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at mail.internetidentity.com Received: from mail.internetidentity.com ([127.0.0.1]) by localhost (mail.internetidentity.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgHTzRURb3qq; Wed, 11 Dec 2013 14:19:41 -0800 (PST) Received: from [192.168.10.225] (unknown [64.122.169.98]) by mail.internetidentity.com (Postfix) with ESMTPSA id EA05A45C091B; Wed, 11 Dec 2013 14:19:40 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Merike Kaeo In-Reply-To: Date: Wed, 11 Dec 2013 14:19:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7F9E7A46-FFFE-4977-AB1E-510D115814A0@internetidentity.com> References: <01FDD0EDFF2BFC47A89029A6B409322E91555D@bobcat.bronze.us-cert.gov> To: "Moriarty, Kathleen" X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Wed, 11 Dec 2013 14:28:22 -0800 Cc: "mile@ietf.org" , Trey Darley , "Dandurand Luc \(Luc.Dandurand@ncia.nato.int\)" Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 22:22:06 -0000 Hi. That was the IEEE paper I downloaded from the IEEE site (I am a member). = That and the presentation you reference from search of 'CDXI Dandurand' = were useful for me to get a good synopsis of CDXI. - merike On Dec 11, 2013, at 7:17 AM, "Moriarty, Kathleen" = wrote: > Hello, Trey. >=20 > I believe this is the right link to the CDXI paper. Luc is on the = list, so he may chime in if he sees this. A search for "CDXI Dandurand" = turns up previous presentations he has given as well if that is helpful. >=20 > = http://ieeexplore.ieee.org/xpl/login.jsp?tp=3D&arnumber=3D6568369&url=3Dht= tp%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6568369 >=20 > The paper turned up in the first page of links from Google with those = search terms and has the title, "Towards Improved Cyber Security = Information Sharing". >=20 > Best regards, > Kathleen >=20 > -----Original Message----- > From: Trey Darley [mailto:tdarley@splunk.com]=20 > Sent: Wednesday, December 11, 2013 8:36 AM > To: Moriarty, Kathleen > Cc: mile@ietf.org > Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect >=20 > Hi, Kathleen - >=20 > Have you got a link to the IEEE CDXI whitepaper handy? IEEE is great = but their site nav / search...not so much. Thanks! >=20 > Cheers, > Trey > -- > Trey Darley > Minister of Foreign Affairs > Brussels > Cupertino Seattle London Hong Kong Washington D.C. > Plano San Francisco Singapore Munich Paris Splunk > because = specialisation is for insects >=20 >=20 >=20 >=20 > On 05.12.13 16:56, "Moriarty, Kathleen" = wrote: >=20 >> Hi Tom, >>=20 >> Thank you, this is a good discussion and your points are well taken! >> CDXI and MACCSA could be separated out to show they fit into=20 >> complimentary buckets. It should not take a PhD to understand this=20= >> stuff, but when we get it right (hopefully soon) no one will have to=20= >> know what any of these acronyms are, it will just work. >>=20 >> A white paper on CDXI was published through IEEE, so it may not have=20= >> been read as much due to the fee, not sure. CDXI is open in terms of=20= >> the formats and protocols used in their framework. Luc has presented=20= >> on it externally, I had the opportunity to see him present at RSA=20 >> Europe in October and the work is excellent. His presentation was=20 >> extremely well-received. Maybe he can share some of the public=20 >> information on this list? >>=20 >> As for use cases, I agree a lot of the work has been focused on use=20= >> cases, but think some efforts have done better at the sharing model=20= >> development than others. I think there are valuable lessons we can = all=20 >> learn as we build out the space further to increase the success. I=20= >> spent some time writing my thoughts on the topic to help in a white=20= >> paper and several blogs that are intentionally neutral on=20 >> formats/protocols as I think your sharing model and requirements = should=20 >> be well-defined prior to any selection. Answers could vary within a=20= >> sharing model as well. Here are a few links for those that are=20 >> interested in a deeper explanation of my use cases comment: >>=20 >> RSA White paper: >> = http://www.emc.com/collateral/emc-perspective/h12175-transf-expect-for- >> thr >> eat-intell-sharing.pdf >>=20 >> RSA Blogs: >> = https://blogs.rsa.com/information-sharing-done-right-whats-useful-to-sh >> are >> -and-who-should-get-it/ >> = https://blogs.rsa.com/information-sharing-how-do-we-share-data-effectiv >> ely >> / >> https://blogs.rsa.com/standards-matter-information-sharing/ >>=20 >> Thanks, >> Kathleen >>=20 >> -----Original Message----- >> From: Thomas.Millar@us-cert.gov [mailto:Thomas.Millar@us-cert.gov] >> Sent: Thursday, December 05, 2013 10:00 AM >> To: Moriarty, Kathleen; mchernin@dtcc.com; mile@ietf.org >> Subject: RE: [mile] New ENISA report: Detect, SHARE, Protect >>=20 >> Thank you Kathleen. >>=20 >> I think some of the head-scratching stems from the fact that there is=20= >> very little out there to explain the "framework" efforts like MACCSA=20= >> and CDXI. That's especially problematic when trying to put them side = by=20 >> side against activities like STIX, TAXII, CybOX, CIF, AbuseHelper, = and=20 >> this WG. To clarify - each of those latter items I just mentioned has = a=20 >> public website with lots of information on the work, links to=20 >> repositories of running code, major commercial entities involved=20 >> (several publicly announcing their involvement, like Microsoft with=20= >> regards to STIX), and most importantly to me, other national CSIRTs = actively participating. >> CDXI and MACCSA, as far as I can tell, have been discussed for years=20= >> but I have yet to see how they actually work or who is actually using=20= >> them in an operational environment, or even in a testbed. You could=20= >> throw NEISAS in the latter category as well, I suppose. >>=20 >> I'm concerned that putting white paper frameworks up against actual=20= >> specifications and working software that people use every day can = only=20 >> lead to more confusion in an arena where - as you and I have noted = time=20 >> and again - there is already more than sufficient bewilderment. >>=20 >> I don't understand your second paragraph. It has always been my=20 >> understanding that all of the sharing models, specifications and=20 >> working software in this arena have been based on actual use cases.=20= >> Many of those use cases are documented or even explicit in the names = of=20 >> the efforts themselves. >>=20 >> - Tom Millar >>=20 >> thomas.millar@us-cert.gov >> BB: thomas.millar@dhs.gov / 202-631-1915 >> 24x7: soc@us-cert.gov / 888-282-0870 >>=20 >> -----Original Message----- >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty,=20 >> Kathleen >> Sent: Wednesday, December 04, 2013 5:41 PM >> To: Chernin, Michael A.; mile@ietf.org >> Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect >>=20 >> Thanks Tom & Aaron for sharing your feedback. These are helpful=20 >> discussions. >>=20 >>=20 >>=20 >> I can assist on the MACCSA question for those not familiar as it is = not=20 >> in itself a format, but rather a framework that references and = includes=20 >> other efforts. It actually covers quite a bit from identity and = access=20 >> management through to sharing formats and protocols referencing work=20= >> from several international standards bodies as appropriate. This was=20= >> done to show that standards existed and could be combined to provide=20= >> the necessary coverage without having to invent anything new. The = work=20 >> that proceeded MACCSA involved about 18 nations who had requirements=20= >> for international standards (IETF, ISO, ITU, etc.) and the ability to=20= >> update and evolve referenced standards as needed in the future. I=20 >> think there are over 30 nations involved now. In addition to the = MILE=20 >> work, the MITRE work is mentioned and will be included more directly=20= >> when it moves to a standards body. It is mentioned and described in=20= >> the current version. Last time I looked at the MACCSA framework, it=20= >> did not compare the formats as that is not the purpose of the=20 >> framework. Many large efforts like the NATO CDXI for example, are=20 >> looking IODEF, STIX, as well as OpenIOC to use what they need, where=20= >> they need it. MACCSA is putting all of the pieces together. >>=20 >>=20 >>=20 >> In terms of comparisons, I see the formats as suitable for different=20= >> use cases and think the report comes at a very good time as Aaron = points out. >> Even within a use case, sharing between different entities could vary=20= >> greatly and thus the requirements for exchange could vary. Privacy = and=20 >> information leakage concerns could limit what is used for sharing = with=20 >> certain parties and it may be desirable to just support a minimum=20 >> baseline of what should be exchanged in those situations. For other=20= >> exchanges (even in the same sharing model), richer data sets and=20 >> information may be very important (Aaron's 4th bullet - I would say=20= >> STIX is the most robust as capable depends on your use case and = requirements. >> Not everyone can handle that much information as they are lacking=20 >> analyst resources to deal with threat actors, campaigns, etc.). = That's=20 >> part of the reason I think use cases based sharing models are very=20 >> important as well as having options to choose formats and protocols=20= >> that meet your requirements. >>=20 >>=20 >>=20 >> Thanks again for all of your efforts on this report Romain! >>=20 >>=20 >>=20 >> Best regards, >>=20 >> Kathleen >>=20 >>=20 >>=20 >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Chernin, = Michael A. >> Sent: Wednesday, December 04, 2013 4:58 PM >> To: mile@ietf.org >> Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect >>=20 >>=20 >>=20 >> Thanks for the report Romain. I will second Mr. Millar that sections=20= >> 1-3 provide valuable information regards to the barriers to sharing. >>=20 >>=20 >>=20 >> My concerns start in section 4, where the Data Exchange formats are=20= >> compared. At our current sharing maturity level, people are doing a = lot=20 >> of research on specification selection, and during this time=20 >> specification perception holds a lot of value. I am concerned about = the=20 >> primary image (Figure 6) used to open section 4. My input is below: >>=20 >>=20 >>=20 >> * It's easy to imagine a standard/specification that can do >> everything. While there is an asterisk next to MACCSA stating that = it's=20 >> in the definition phase, the way it spans the entire chart gives it a=20= >> superior perception to other more defined specifications like IODEF = and=20 >> STIX. >>=20 >> * I am unable to locate a definition for Network and File >> observable columns on the chart. All the specifications compared have=20= >> key coverage differences in these areas. >>=20 >> * Critical areas that both STIX and IODEF excel at, like = email, >> are missing as a column entirely >>=20 >> * Key observable columns that STIX excels at are missing >> entirely: Actors, Campaigns, TTP, Targeting, Windows objects, Unix=20= >> objects, Privileges, Package Manager Data, User Account Data, DNS, = etc. >> These missing columns make STIX appear less capable. If you add those=20= >> columns in, than a completely different story is told and STIX = appears=20 >> the most capable. >>=20 >>=20 >>=20 >> Thanks >>=20 >> Aharon >>=20 >>=20 >>=20 >> DTCC Non-Confidential (White) >>=20 >>=20 >>=20 >>=20 >> _____________________________________________________________ >> DTCC DISCLAIMER: This email and any files transmitted with it are=20 >> confidential and intended solely for the use of the individual or=20 >> entity to whom they are addressed. If you have received this email in=20= >> error, please notify us immediately and delete the email and any=20 >> attachments from your system. The recipient should check this email = and=20 >> any attachments for the presence of viruses. The company accepts no=20= >> liability for any damage caused by any virus transmitted by this = email. >>=20 >>=20 >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >=20 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Fri Dec 13 06:24:04 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F041AE124 for ; Fri, 13 Dec 2013 06:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.996 X-Spam-Level: * X-Spam-Status: No, score=1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_STOCK2=3.988, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_FRT_STOCK2=0.01] 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 7whyzkzcUraA for ; Fri, 13 Dec 2013 06:24:02 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 42FF51ADBF7 for ; Fri, 13 Dec 2013 06:24:02 -0800 (PST) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBDENtbC025192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Dec 2013 09:23:55 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com rBDENtbC025192 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1386944635; bh=qweTXGT9wUEDDinX/5wbZ8P9lgo=; h=From:To:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=qVKl7jwgsk5wvdZBDMdKEqEDODFDyTAPx7+B69hKbgy2Oi8vQkcWglejLw8cT9Ye8 2SiuxX905dJ7vS5RIarCjK9GZ5h7ExR+xm7jtMuK9l8L4x/c3xus1tabUz7JVodITg Pz2eK0AfIcMxOYFClFwgUb54i/IQy4HIN/WrSM1I= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com rBDENtbC025192 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd54.lss.emc.com (RSA Interceptor) for ; Fri, 13 Dec 2013 09:23:48 -0500 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBDENlvN016657 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 13 Dec 2013 09:23:47 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Fri, 13 Dec 2013 09:23:47 -0500 From: "Moriarty, Kathleen" To: "mile@ietf.org" Date: Fri, 13 Dec 2013 09:23:46 -0500 Thread-Topic: Call for WG Reviews of RFC5070-bis Thread-Index: Ac74Dra96ZvGRTFmTV+XXlqv9V6HvQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Subject: [mile] Call for WG Reviews of RFC5070-bis X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 14:24:04 -0000 Hello, RFC5070-bis will move to working group last call as scheduled in January. = Reviews prior to last call are extremely important to ensure the WG has add= ressed any major concerns in the draft. Please take the time to review the= draft that will result in an IODEF v2.0. Reviews and discussion of review= s should all be posted to mile@ietf.org. If something is more sensitive, p= lease send it to the editors and copy Brian and myself so that we see the a= ctivity and interest. This will be the easiest time to get your requested changes in as we can al= low for detailed discussions that may be necessary. Reviews will be encour= aged during last call as well within a 2 week period in January. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis=20 Thank you! Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Rom= an D. Danyliw Sent: Saturday, October 19, 2013 9:11 PM To: mile@ietf.org Subject: [mile] FW: I-D Action: draft-ietf-mile-rfc5070-bis-02.txt Hello! A new version of 5070bis has been published as -02. The following is a lis= t of the changes: ** (schema) Added Contact/ContactTitle to describe the title of the contact= (Issue #35) ** (schema) Added System/AssetId to represent an opaque asset identifier (I= ssue #33) ** (schema) Added RelatedActivity/{ThreadActor, Campaign, Confidence, Descr= iption, AdditionalData} (Issue #31 and partial #22) ** (schema) Changed cardinality of Incident/RelatedActivity to be 0..many i= n Incident (needed for Issue #31) ** (schema) Added System@virtual to convey whether a device is physical or = virtual (Issue #16) ** (schema) Added Incident@purpose=3D{watch} (Issue #17) ** (schema) Added System@ownership to describe asset ownership (Issue #34) ** (schema) Various fixes to schema to make it valid=20 ** (editorial) Minor spelling fixes Roman -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Saturday, October 19, 2013 9:09 PM To: i-d-announce@ietf.org Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange Wor= king Group of the IETF. Title : The Incident Object Description Exchange Format v2 Author(s) : Roman Danyliw Paul Stoecker Filename : draft-ietf-mile-rfc5070-bis-02.txt Pages : 112 Date : 2013-10-19 Abstract: The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-rfc5070-bis-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From athiasjerome@gmail.com Mon Dec 16 08:13:11 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0681AE360 for ; Mon, 16 Dec 2013 08:13:11 -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, FRT_STOCK2=3.988, SPF_PASS=-0.001, T_FRT_STOCK2=0.01] 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 prm_Qx7r2QDu for ; Mon, 16 Dec 2013 08:13:09 -0800 (PST) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8780E1AE357 for ; Mon, 16 Dec 2013 08:13:09 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id p10so5500456pdj.18 for ; Mon, 16 Dec 2013 08:13:08 -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=c0T3+4k4ZjwqxeduArDTrpftnxu/1u3c7fZzc+KJRN8=; b=ol4f/iIl0x2tbT4ShmFGX1dx1ye2sh1ZFn5qXjWEy5hSAMIvHf2uu6KdkUpdVrfN2x 7BtmbgcMZLBGNHvtfw6opXxKwrk6dJo4vn3eY/1kQCSQOfn0GC2obevssRucTsNnTLAl F0JhSgKUyDY3g0EMCTYbkg2qs31Rqpyv2OQECvzLRFh/hs7jRexQodt/WYB7qoExSG7n LIDtHvVtvObteEc8905ib/Lsueu+D9k6XvOofKQpRRVD0gOb8MotvM/6o/rlyKmHAw4H r4joW1z361QpplP7G/iVjR7opfoFmsf3SZe9tAvmPQoAHZFZkWp2GY6AzEe+x7M5D/uR rWTQ== MIME-Version: 1.0 X-Received: by 10.68.34.37 with SMTP id w5mr20879412pbi.159.1387210388870; Mon, 16 Dec 2013 08:13:08 -0800 (PST) Received: by 10.68.195.104 with HTTP; Mon, 16 Dec 2013 08:13:08 -0800 (PST) In-Reply-To: References: Date: Mon, 16 Dec 2013 19:13:08 +0300 Message-ID: From: Jerome Athias To: "Moriarty, Kathleen" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mile@ietf.org" Subject: Re: [mile] Call for WG Reviews of RFC5070-bis X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 16:13:11 -0000 Hi, after a quick review, here are some notes: Nice work! The attributes are sometimes missing into the figures. Examples: 3.11.1. and in many cases the (new) indicator-uid and indicator-set-id (3.12., 3.15., 3.18.2., 3.19., 3.21.1., ...) Sometimes the sentence "The X class has no attributes." is missing, i.e.: 3= .18. In 3.4, should "activity described the IODEF document" be "activity described in the IODEF document" ? In 3.9.1 should "A means by which" be "A mean by which" (or meaning) ? Is the word "STRING" missing in 3.22.1. for KeyName and Value? Is Value a full path? (if so, maybe it should be clarified) (I will review later the registry action default enumeration) I would review the relationships between FileName and FileSize in 3.23. HashInformation Class (I would prefer to have ProtoCode and ProtoType to be ProtocolCode and ProtocolType) Maybe the virtual enumeration (3.17. System Class) could have also "unknown= " I would double-check the description of duration in 3.18.1. Could we discuss the possibility to extend the Application (and so OperatingSystem) Class?, with: name lang or/and an extension mechanism Contact Class It should be difficult to use a RACI matrix (if needed) with the actual roles enumeration Cardinality of 0..1 between Incident and AlternativeID (I would have to investigate further, but it could lead to some issues while consolidating information for the same incident described by 2+ parties) I like to use a ConfidenceReason when describing/exchanging a Confidence NB: It also helps for making automated choices at a parser level And also for automation, "asset" or "system" could be useful in the type enumeration of 3.9. Contact class I will try to review the XML part (is everything documented? EMailDetails (should maybe be EmailDetails), DomainData, HashSigDetails...) I will think about the user-agent (and maybe come with some thoughts about predictability next year) My 2c for now Best regards /JA 2013/12/13 Moriarty, Kathleen : > Hello, > > RFC5070-bis will move to working group last call as scheduled in January.= Reviews prior to last call are extremely important to ensure the WG has a= ddressed any major concerns in the draft. Please take the time to review t= he draft that will result in an IODEF v2.0. Reviews and discussion of revi= ews should all be posted to mile@ietf.org. If something is more sensitive,= please send it to the editors and copy Brian and myself so that we see the= activity and interest. > > This will be the easiest time to get your requested changes in as we can = allow for detailed discussions that may be necessary. Reviews will be enco= uraged during last call as well within a 2 week period in January. > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis > > Thank you! > Kathleen > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of R= oman D. Danyliw > Sent: Saturday, October 19, 2013 9:11 PM > To: mile@ietf.org > Subject: [mile] FW: I-D Action: draft-ietf-mile-rfc5070-bis-02.txt > > Hello! > > A new version of 5070bis has been published as -02. The following is a l= ist of the changes: > > ** (schema) Added Contact/ContactTitle to describe the title of the conta= ct (Issue #35) > ** (schema) Added System/AssetId to represent an opaque asset identifier = (Issue #33) > ** (schema) Added RelatedActivity/{ThreadActor, Campaign, Confidence, Des= cription, AdditionalData} (Issue #31 and partial #22) > ** (schema) Changed cardinality of Incident/RelatedActivity to be 0..many= in Incident (needed for Issue #31) > ** (schema) Added System@virtual to convey whether a device is physical o= r virtual (Issue #16) > ** (schema) Added Incident@purpose=3D{watch} (Issue #17) > ** (schema) Added System@ownership to describe asset ownership (Issue #34= ) > ** (schema) Various fixes to schema to make it valid > ** (editorial) Minor spelling fixes > > Roman > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org > Sent: Saturday, October 19, 2013 9:09 PM > To: i-d-announce@ietf.org > Cc: mile@ietf.org > Subject: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Managed Incident Lightweight Exchange W= orking Group of the IETF. > > Title : The Incident Object Description Exchange Format= v2 > Author(s) : Roman Danyliw > Paul Stoecker > Filename : draft-ietf-mile-rfc5070-bis-02.txt > Pages : 112 > Date : 2013-10-19 > > Abstract: > The Incident Object Description Exchange Format (IODEF) defines a > data representation that provides a framework for sharing information > commonly exchanged by Computer Security Incident Response Teams > (CSIRTs) about computer security incidents. This document describes > the information model for the IODEF and provides an associated data > model specified with XML Schema. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-rfc5070-bis-02 > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From rdd@cert.org Thu Dec 19 13:16:51 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4C81AE8E6 for ; Thu, 19 Dec 2013 13:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 iuxsqsKkGJEi for ; Thu, 19 Dec 2013 13:16:49 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 06CFA1AE8E9 for ; Thu, 19 Dec 2013 13:16:48 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id rBJLGkb3019889 for ; Thu, 19 Dec 2013 16:16:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1387487806; bh=ll4uoF1V+aj84HAf7JgjbijcsIya5zRbC9ngrYy9Fvk=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version:Sender: Reply-To:Cc:In-Reply-To:References; b=Wc6/1x/j3E7nbwpSnsF804HeradWI0tNhhoCOYIW0OyC6R5nQ0LQZgN6Np6umSPYZ IAcenh6eqmWmJvOoOYeaDosGwGaULnl106xNMHWnT8CxC5zpl4dOmeZXughgACyvr/ S/TeTu15FeEjv7veC2tsTAwdAvVXni4vUCk9qZ14= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id rBJLGkDv006377 for ; Thu, 19 Dec 2013 16:16:46 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Thu, 19 Dec 2013 16:16:45 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Proposal for adding predefined courses of action Thread-Index: Ac78/xkIYRPHHGIHTrCa/IwvQw4L7Q== Date: Thu, 19 Dec 2013 21:16:45 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54BF7C86@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC54BF7C86marathon_" MIME-Version: 1.0 Subject: [mile] Proposal for adding predefined courses of action X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 21:16:51 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC54BF7C86marathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello! Ticket #32 (http://tools.ietf.org/wg/mile/trac/ticket/32) outlines the need= for a means to specify a predetermined course of action (COA) in the Expec= tation and HistoryItem class. Five implementation options were suggested. = After review, I would propose adoption of a blend of #4 and #5. ** Add a class named "DefinedCOA" to Expectation and History Item +-------------------+ | Expectation | +-------------------+ | ENUM restriction |<>--{0..*}--[ Description ] | ENUM severity |<>--{0..*}--[ DefinedCOA ] | ENUM action |<>--{0..1}--[ StartTime ] | STRING ext-action |<>--{0..1}--[ EndTime ] | |<>--{0..1}--[ Contact ] +-------------------+ DefinedCOA Zero or many. ML_STRING. A unique identifier meaningful to the send= er and recipient of this document that references a course of action. This= class must be present if the action attribute is set to "defined-coa". ** Add an "defined-coa" to @action in Expectation and HistoryItem 17. defined-coa. Perform a predefined course of action (COA). The COA is= named in the DefinedCOA class. Examples of this approach would look like the following: [Example 1] Procedure-A [Example 2] Do the following ... Procedure-A [Example 3] Procedure-A Procedure-B Roman --_000_359EC4B99E040048A7131E0F4E113AFC54BF7C86marathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello!

 

Ticket #32 (http://tools.ietf.org/wg/mile/trac/ticket/32) outlines= the need for a means to specify a predetermined course of action (COA) in = the Expectation and HistoryItem class.  Five implementation options were suggested.  After review, I would pr= opose adoption of a blend of #4 and #5.

 

<proposal>

** Add a class named “DefinedCOA” to Exp= ectation and History Item

 

   +-------------------+

   | Expectation      &= nbsp;|

   +-------------------+

   | ENUM restriction  |<>--{0..*}--[= Description ]

   | ENUM severity     |<= >--{0..*}--[ DefinedCOA  ]

   | ENUM action      &= nbsp;|<>--{0..1}--[ StartTime   ]

   | STRING ext-action |<>--{0..1}--[ EndT= ime     ]

   |        &= nbsp;          |<>-= -{0..1}--[ Contact     ]

   +-------------------+

 

DefinedCOA
      Zero or many.  ML_STRING.  A =
unique identifier meaningful to the sender and recipient of this document t=
hat references a course of action.  This class must be present if the =
action attribute is set to “defined-coa”.
 
** Add an “defined-coa” to @action in Expectation and Hist=
oryItem
 
17.  defined-coa.  Perform a predefined course of action (CO=
A).  The COA is named in the DefinedCOA class.
</proposal>
 
Examples of this approach would look like the following:

 


[Example 1]


<!-- simple example, no details provided -->


<Expectation action=3D"defined-coa"> 


   <DefinedCOA>Procedure-A</DefinedCOA>


 


[Example 2]


<!-- preserves the type of action taken -->


<!-- distinguishes Description from COA easing parsing complexity -=
->


<Expectation action=3D"watch-and-warning"> =



   <Description>Do the following ...</Descript=
ion>
   <DefinedCOA>Procedure-A</DefinedCOA>


 


[Example 3]


<!-- multiple COA requested -->


<Expectation action=3D"defined-coa"> 


   <DefinedCOA>Procedure-A</DefinedCOA>


   <DefinedCOA>Procedure-B</DefinedCOA>


 


Roman
--_000_359EC4B99E040048A7131E0F4E113AFC54BF7C86marathon_-- From rdd@cert.org Thu Dec 19 13:54:30 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC101AE9EA for ; Thu, 19 Dec 2013 13:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.303 X-Spam-Level: X-Spam-Status: No, score=-0.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FRT_STOCK2=0.01] 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 NYi2kLW_cbMV for ; Thu, 19 Dec 2013 13:54:28 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 413F01AE9E5 for ; Thu, 19 Dec 2013 13:54:28 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id rBJLsPUt020820; Thu, 19 Dec 2013 16:54:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1387490065; bh=Z0XRnVwNJP/YUD1jetTRrFTxIp51/GkIqk3faz3s0ZA=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=c5Wpc7eWHapYILELOF7s7LeAgcpec8zdWeXGjawO5bM5P4OdEpC+jYCSgFf18tKnr FOtYuJ+XxWPO4F1AIrvShBsfXZ/KgkVvsyz0Cy9S4FaD6fLHeJrxkrQUnSIUhW/lnu DNBT8xakEcWeekZY1iTbcVxgMo6ai1e6dqlPcrNU= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id rBJLsPkq009414; Thu, 19 Dec 2013 16:54:25 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Thu, 19 Dec 2013 16:54:24 -0500 From: "Roman D. Danyliw" To: Jerome Athias Thread-Topic: [mile] Call for WG Reviews of RFC5070-bis Thread-Index: Ac74Dra96ZvGRTFmTV+XXlqv9V6HvQClOdkAAJcXg0A= Date: Thu, 19 Dec 2013 21:54:23 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54BF7D9C@marathon> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mile@ietf.org" Subject: Re: [mile] Call for WG Reviews of RFC5070-bis X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 21:54:30 -0000 Hi Jerome, Thanks for the thorough review! Comments inline ... > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Jerome Athias > Sent: Monday, December 16, 2013 11:13 AM > To: Moriarty, Kathleen > Cc: mile@ietf.org > Subject: Re: [mile] Call for WG Reviews of RFC5070-bis >=20 > Hi, >=20 > after a quick review, here are some notes: >=20 > Nice work! >=20 >=20 > The attributes are sometimes missing into the figures. > Examples: > 3.11.1. > and in many cases the (new) indicator-uid and indicator-set-id (3.12., 3.= 15., > 3.18.2., 3.19., 3.21.1., ...) Concur. Good catch. This will be fixed. > Sometimes the sentence "The X class has no attributes." is missing, i.e.:= 3.18. Concur. This will be fixed. > In 3.4, should > "activity described the IODEF document" > be > "activity described in the IODEF document" > ? Concur. Your text "activity described in the IODEF document" is the better= language to use > In 3.9.1 should > "A means by which" > be > "A mean by which" (or meaning) > ? Disagree. The "A means by which" is the standard language used by all of t= he ext-* attribute write-ups. =20 > Is the word "STRING" missing in 3.22.1. for KeyName and Value? Concur. STRING is missing. > Is Value a full path? (if so, maybe it should be clarified) (I will revie= w later the > registry action default enumeration) Did you mean is KeyName a full path? I'm not sure what a full path is for = a registry value (i.e., the Value class). > I would review the relationships between FileName and FileSize in 3.23. > HashInformation Class Concur. This came up as an issue and is tracked in Ticket #20 (http://trac= .tools.ietf.org/wg/mile/trac/ticket/20). While identified, it is not yet r= esolved. =20 > (I would prefer to have ProtoCode and ProtoType to be ProtocolCode and > ProtocolType) I see how this change would be cleaner. Balanced against the backward comp= atibility of IODEF-v1, do you think it's worth the change? > Maybe the virtual enumeration (3.17. System Class) could have also > "unknown" Concur. "unknown" will be added. > I would double-check the description of duration in 3.18.1. Could you please be a little more specific? Is the text clumsy, not clear i= n some way, or both? > Could we discuss the possibility to extend the Application (and so > OperatingSystem) Class?, with: > name > lang > or/and an extension mechanism Do you have a specific proposal in mind, or is the list above data you'd li= ke to see represented? How does this list match against the Platform class in draft-ietf-mile-sci-= 12? > Contact Class > It should be difficult to use a RACI matrix (if needed) with the actual r= oles > enumeration Could you provide an example of where the current approach would break? > Cardinality of 0..1 between Incident and AlternativeID (I would have to > investigate further, but it could lead to some issues while consolidating > information for the same incident described by 2+ > parties) Could you provide an example of where the current cardinality wouldn't be a= dequate? While an Incident can only have 0..1 AlternativeIDs, an Alternati= veID has many IncidentIDs potentially from many organizations. > I like to use a ConfidenceReason when describing/exchanging a Confidence > NB: It also helps for making automated choices at a parser level And also= for > automation,=20 Can you clarify (or provide an example of) of your thinking about "Confiden= ceReason"? Is there a need to document why a particular confidence value w= as chosen? > "asset" or "system" could be useful in the type enumeration of > 3.9. Contact class Can you clarify (or provide an example of) what it would mean to have a Con= tact@type=3D"system"? Is it to convey contact information at the asset lev= el? If so, a System and Contact class can already be represented grouped t= ogether with an EventData class. >=20 > I will try to review the XML part (is everything documented? > EMailDetails (should maybe be EmailDetails), DomainData, > HashSigDetails...) > > I will think about the user-agent > (and maybe come with some thoughts about predictability next year) >=20 >=20 > My 2c for now >=20 > Best regards > /JA We're very appreciative for this feedback Jerome! Roman > 2013/12/13 Moriarty, Kathleen : > > Hello, > > > > RFC5070-bis will move to working group last call as scheduled in Januar= y. > Reviews prior to last call are extremely important to ensure the WG has > addressed any major concerns in the draft. Please take the time to revie= w > the draft that will result in an IODEF v2.0. Reviews and discussion of r= eviews > should all be posted to mile@ietf.org. If something is more sensitive, p= lease > send it to the editors and copy Brian and myself so that we see the activ= ity > and interest. > > > > This will be the easiest time to get your requested changes in as we ca= n > allow for detailed discussions that may be necessary. Reviews will be > encouraged during last call as well within a 2 week period in January. > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis > > > > Thank you! > > Kathleen > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of Roman D. Danyliw > > Sent: Saturday, October 19, 2013 9:11 PM > > To: mile@ietf.org > > Subject: [mile] FW: I-D Action: draft-ietf-mile-rfc5070-bis-02.txt > > > > Hello! > > > > A new version of 5070bis has been published as -02. The following is a= list > of the changes: > > > > ** (schema) Added Contact/ContactTitle to describe the title of the > > contact (Issue #35) > > ** (schema) Added System/AssetId to represent an opaque asset > > identifier (Issue #33) > > ** (schema) Added RelatedActivity/{ThreadActor, Campaign, Confidence, > > Description, AdditionalData} (Issue #31 and partial #22) > > ** (schema) Changed cardinality of Incident/RelatedActivity to be > > 0..many in Incident (needed for Issue #31) > > ** (schema) Added System@virtual to convey whether a device is > > physical or virtual (Issue #16) > > ** (schema) Added Incident@purpose=3D{watch} (Issue #17) > > ** (schema) Added System@ownership to describe asset ownership > (Issue > > #34) > > ** (schema) Various fixes to schema to make it valid > > ** (editorial) Minor spelling fixes > > > > Roman > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of internet-drafts@ietf.org > > Sent: Saturday, October 19, 2013 9:09 PM > > To: i-d-announce@ietf.org > > Cc: mile@ietf.org > > Subject: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-02.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Managed Incident Lightweight Exchange > Working Group of the IETF. > > > > Title : The Incident Object Description Exchange Form= at v2 > > Author(s) : Roman Danyliw > > Paul Stoecker > > Filename : draft-ietf-mile-rfc5070-bis-02.txt > > Pages : 112 > > Date : 2013-10-19 > > > > Abstract: > > The Incident Object Description Exchange Format (IODEF) defines a > > data representation that provides a framework for sharing informatio= n > > commonly exchanged by Computer Security Incident Response Teams > > (CSIRTs) about computer security incidents. This document describes > > the information model for the IODEF and provides an associated data > > model specified with XML Schema. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-rfc5070-bis-02 > > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From athiasjerome@gmail.com Fri Dec 20 00:43:59 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1C61AD8E1 for ; Fri, 20 Dec 2013 00:43:59 -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 tveAZC4n5343 for ; Fri, 20 Dec 2013 00:43:58 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 380D11ACCE8 for ; Fri, 20 Dec 2013 00:43:58 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id p10so2246222pdj.40 for ; Fri, 20 Dec 2013 00:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XbFs6btgItk+IYtVPtb57DFA7Ftl4EmqGa67LEzSpUA=; b=gH54X48EBTcFo8xCvcF1FCAkFRLIDQ9OP7U0pcEiT6JS8QowphTMZkaEYd8FaGDUPE 3AyGrxeyRV1nxZqkt34Um9byYB69PIFu+y0xWSbnFEIJmuPaey5qpvKI7MN5FL83ErKN x3ZWZqhqwbMjIFhJ5Na4xJfDd/IEW/ry+YF2e7D/BmGtZr6FucRo2dGBDDihXavPH6CB NKC//gUL9Jb9bNZiKTypDE+Owd57HZt7KP4W+Ck5rUuat2oMKY3rRG1mPcXoS7d28raS OJVixGzRL8qWdkGPcPvIynagcqplOBU8qORSiZ9ij1zX8CqZVvBDhzkMeZqOps1qeh0V 0BQw== MIME-Version: 1.0 X-Received: by 10.68.163.33 with SMTP id yf1mr6975410pbb.143.1387529036227; Fri, 20 Dec 2013 00:43:56 -0800 (PST) Received: by 10.68.195.104 with HTTP; Fri, 20 Dec 2013 00:43:56 -0800 (PST) Date: Fri, 20 Dec 2013 11:43:56 +0300 Message-ID: From: Jerome Athias To: "stix-discussion-list Structured Threat Information Expression/ST" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "mile@ietf.org" Subject: [mile] Courses of action COA X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 08:44:00 -0000 Hi, I would like, if I may, try to join efforts on this one. https://github.com/STIXProject/schemas/wiki/Proposal:-Add-Parameter_Observa= bles-field-to-CourseOfAction Best regards 2013/12/20 Roman D. Danyliw : > Hello! > > > > Ticket #32 (http://tools.ietf.org/wg/mile/trac/ticket/32) outlines the ne= ed > for a means to specify a predetermined course of action (COA) in the > Expectation and HistoryItem class. Five implementation options were > suggested. After review, I would propose adoption of a blend of #4 and #= 5. > > > > > > ** Add a class named =93DefinedCOA=94 to Expectation and History Item > > > > +-------------------+ > > | Expectation | > > +-------------------+ > > | ENUM restriction |<>--{0..*}--[ Description ] > > | ENUM severity |<>--{0..*}--[ DefinedCOA ] > > | ENUM action |<>--{0..1}--[ StartTime ] > > | STRING ext-action |<>--{0..1}--[ EndTime ] > > | |<>--{0..1}--[ Contact ] > > +-------------------+ > > > > DefinedCOA > > Zero or many. ML_STRING. A unique identifier meaningful to the > sender and recipient of this document that references a course of action. > This class must be present if the action attribute is set to =93defined-c= oa=94. > > > > ** Add an =93defined-coa=94 to @action in Expectation and HistoryItem > > > > 17. defined-coa. Perform a predefined course of action (COA). The COA = is > named in the DefinedCOA class. > > > > > > Examples of this approach would look like the following: > > > > [Example 1] > > > > > > Procedure-A > > > > [Example 2] > > > > > > > > Do the following ... > Procedure-A > > > > [Example 3] > > > > > > Procedure-A > > Procedure-B > > > > Roman > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > From rdd@cert.org Fri Dec 20 13:25:55 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AA31AE15A for ; Fri, 20 Dec 2013 13:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 HscnDh-eCIGZ for ; Fri, 20 Dec 2013 13:25:50 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id CB9881AE16B for ; Fri, 20 Dec 2013 13:25:37 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id rBKLPZWo020512 for ; Fri, 20 Dec 2013 16:25:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1387574735; bh=52DTf2n89MG/wkbdIrY7NqlbsmmsFLTz194zOsAqQAk=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version:Sender: Reply-To:Cc:In-Reply-To:References; b=hXOd6JhJhtHDKVXZ4oipyTcdFp/Plb4zmaDdBXTO9yeKjThzawjGQYzZbFNrlJR33 gK1BSz6Nr0ag43qSWVG2hYDPE244uAOzzptxtC/rhoQievUiKoeg7GdHTkV9yf8Tln OPihSP29W8TGCbBYvfVB28WHEzYSLvKfrSjYduVM= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id rBKLPZo7022944 for ; Fri, 20 Dec 2013 16:25:35 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Fri, 20 Dec 2013 16:25:34 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Describing the time window during which an indicator should be used Thread-Index: Ac79wEREoR/sG5XCQ7SYud4bxnPHvA== Date: Fri, 20 Dec 2013 21:25:33 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54BF92D2@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC54BF92D2marathon_" MIME-Version: 1.0 Subject: [mile] Describing the time window during which an indicator should be used X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 21:25:56 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC54BF92D2marathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello! Ticket #28 (http://trac.tools.ietf.org/wg/mile/trac/ticket/28) is tracking = the need to convey the valid time during which to apply an indicator. I wa= nted to solicit from the community the degree of flexibility desired. For = the purposes of this discussion an indicator is defined as a class that has= an @indicator-uid attribute. ** Does this flexibility need to exist on a per indicator basis? Example 1, ** Could it be at the EventData level (and the time window cascades to all = indicators that are children)? Example 2:, ... = ... many domain indicators ... Example 3: ... 2013/12/01 12:00:00 ... ... many domain indicators ... ** Could it be at the Incident level? Example 4: ... 2013/12/01 12:00:00 ... many domain indicators ... Per indicator time information would provide the most flexibility but would= require duplication of the same information. A time window for indicator validity specified at the Incident level would = not allow for multiple time windows per indicator. A time window for indicator validity specified in the EventData class would= require nested EventData instances to convey different time period. Also,= some indicators are only in the Incident class so this approach would be i= nsufficient. Perhaps a hybrid approach where this timing information is in= the EventData and IncidentData classes could be possible. Roman --_000_359EC4B99E040048A7131E0F4E113AFC54BF92D2marathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello!

 

Ticket #28 (http://trac.tools.ietf.org/wg/mile/trac/ticket/28= ) is tracking the need to convey the valid time during which to apply an in= dicator.  I wanted to solicit from the community the degree of flexibility desired.  For the purposes of thi= s discussion an indicator is defined as a class that has an @indicator-uid = attribute.

 

** Does this flexibility need to exist on a per indi= cator basis?

Example 1, <Assessment indicator-uid=3D”foo= -12345” indicator-valid-stime=3D”2013/12/01 12:00:00”>=

 

** Could it be at the EventData level (and the time = window cascades to all indicators that are children)?

Example 2:, <EventData indicator-stime=3D”2= 013/12/01 12:00:00”> … <Flow> … many domain indi= cators </Flow> … </EventData>

 

Example 3: <EventData>  … <Indic= atorStartTime>2013/12/01 12:00:00</IndicatorStartTime> … <= ;Flow> … many domain indicators </Flow> … </EventDa= ta>

 

** Could it be at the Incident level?

Example 4: <Incident>  … <Indica= torStartTime>2013/12/01 12:00:00</IndicatorStartTime> … many= domain indicators </Flow> … </Incident>

 

Per indicator time information would provide the mos= t flexibility but would require duplication of the same information.

 

A time window for indicator validity specified at th= e Incident level would not allow for multiple time windows per indicator.

 

A time window for indicator validity specified in th= e EventData class would require nested EventData instances to convey differ= ent time period.  Also, some indicators are only in the Incident class= so this approach would be insufficient.  Perhaps a hybrid approach where this timing information is in the EventDat= a and IncidentData classes could be possible.

 

Roman

 

--_000_359EC4B99E040048A7131E0F4E113AFC54BF92D2marathon_-- From Christopher.Harrington@emc.com Fri Dec 20 13:57:39 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761C41ADF74 for ; Fri, 20 Dec 2013 13:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 uS-sxlPFFXQD for ; Fri, 20 Dec 2013 13:57:35 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 756991ACC87 for ; Fri, 20 Dec 2013 13:57:34 -0800 (PST) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBKLvJLm010283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Dec 2013 16:57:21 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com rBKLvJLm010283 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1387576641; bh=BIzVIx+3hzC7vgQbwgnvdqg9y04=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=bjN5SBMDpdT8nIEgo1kf5Eqszs2ypWCXgihHA70gNXOo7FWPjvlEfqPJ04KxGt34m 4/KbOpek6TBmV7XVgRwiO6ieaS4OgocoQWoamUSaLCQ47arMwDHom3VfEiDKIcbphK rDxs3J1rc9EjgPZ7bRftekkWwpTEXTQzjKmqpL+M= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com rBKLvJLm010283 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd53.lss.emc.com (RSA Interceptor); Fri, 20 Dec 2013 16:57:01 -0500 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBKLv0Dh001448 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Dec 2013 16:57:01 -0500 Received: from mx36a.corp.emc.com ([169.254.1.232]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Fri, 20 Dec 2013 16:57:00 -0500 From: "Harrington, Christopher" To: "Roman D. Danyliw" , "mile@ietf.org" Date: Fri, 20 Dec 2013 16:56:58 -0500 Thread-Topic: [mile] Describing the time window during which an indicator should be used Thread-Index: Ac79wEREoR/sG5XCQ7SYud4bxnPHvAADNhDA Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC54BF92D2@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54BF92D2@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_067E_01CEFDA4.7E6BC920" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Subject: Re: [mile] Describing the time window during which an indicator should be used X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 21:57:39 -0000 ------=_NextPart_000_067E_01CEFDA4.7E6BC920 Content-Type: multipart/alternative; boundary="----=_NextPart_001_067F_01CEFDA4.7E6BF030" ------=_NextPart_001_067F_01CEFDA4.7E6BF030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Answers inline below. Thanks, --Chris Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Friday, December 20, 2013 4:26 PM To: mile@ietf.org Subject: [mile] Describing the time window during which an indicator should be used Hello! Ticket #28 (http://trac.tools.ietf.org/wg/mile/trac/ticket/28) is tracking the need to convey the valid time during which to apply an indicator. I wanted to solicit from the community the degree of flexibility desired. For the purposes of this discussion an indicator is defined as a class that has an @indicator-uid attribute. ** Does this flexibility need to exist on a per indicator basis? Example 1, Yes, a malicious URL would be valid only as long as it is live. ** Could it be at the EventData level (and the time window cascades to all indicators that are children)? Example 2:, . . many domain indicators . Example 3: . 2013/12/01 12:00:00 . . many domain indicators . Yes, you could have multiple malware delivery URLs that are all on the same domain. If the Domain is specified at EvenData level then when it is no longer valid the children would no longer be valid. I hope I explained that right J I am not sure how it would differ between Example 2 and 3. ** Could it be at the Incident level? Example 4: . 2013/12/01 12:00:00 . many domain indicators . If there was only one Indicator in an incident it could be. In practical terms this is very unlikely. Per indicator time information would provide the most flexibility but would require duplication of the same information. A time window for indicator validity specified at the Incident level would not allow for multiple time windows per indicator. A time window for indicator validity specified in the EventData class would require nested EventData instances to convey different time period. Also, some indicators are only in the Incident class so this approach would be insufficient. Perhaps a hybrid approach where this timing information is in the EventData and IncidentData classes could be possible. Personally I think the safest approach is validity per Indicator. Validity for parent / child would be rare and validity per Incident even rarer. One question, how do we represent "still valid"? If I have an indicator that is valid when I send the message how do I know what that time represents? If I put "12/20/2013 13:00" as the time can you tell if I mean that it was still valid when I sent the message at that time or that its validity period ended at that time. Those are very different scenarios and critically important for searching / responding to indicator hits. Roman ------=_NextPart_001_067F_01CEFDA4.7E6BF030 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Answers inline below. =

 

Thanks,

 

--Chris

 

Christopher = Harrington
Consulting Security Engineer
GSO - Critical Incident = Response Center
EMC
174 Middlesex Turnpike
Bedford, MA = 01730
781-515-5862 (work)
603-583-1585 = (cell)

 

From:= = mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. = Danyliw
Sent: Friday, December 20, 2013 4:26 PM
To: = mile@ietf.org
Subject: [mile] Describing the time window = during which an indicator should be = used

 

Hello!

 

Ticket #28 = (http://trac.to= ols.ietf.org/wg/mile/trac/ticket/28) is tracking the need to convey = the valid time during which to apply an indicator.  I wanted to = solicit from the community the degree of flexibility desired.  For = the purposes of this discussion an indicator is defined as a class that = has an @indicator-uid attribute.

 

** Does this = flexibility need to exist on a per indicator basis?

Example 1, <Assessment = indicator-uid=3D”foo-12345” = indicator-valid-stime=3D”2013/12/01 = 12:00:00”>

Yes, a malicious URL would be valid only as long = as it is live.

 

** Could it = be at the EventData level (and the time window cascades to all = indicators that are children)?

Example 2:, <EventData = indicator-stime=3D”2013/12/01 12:00:00”> … = <Flow> … many domain indicators </Flow> … = </EventData>

Example 3: = <EventData>  … <IndicatorStartTime>2013/12/01 = 12:00:00</IndicatorStartTime> … <Flow> … many = domain indicators </Flow> … = </EventData>

Yes, you could have multiple malware delivery = URLs that are all on the same domain. If the Domain is specified at = EvenData level then when it is no longer valid the children would no = longer be valid. I hope I explained that right J  I am not sure how it would differ between = Example 2 and 3.

 

** Could it be at the Incident level?

Example 4: <Incident>  … = <IndicatorStartTime>2013/12/01 12:00:00</IndicatorStartTime> = … many domain indicators </Flow> … = </Incident>

If there was only one Indicator in an incident = it could be. In practical terms this is very unlikely. =

 

Per indicator time information would provide the most = flexibility but would require duplication of the same = information.

 

A time window for indicator validity specified at the = Incident level would not allow for multiple time windows per = indicator.

 

A time window for indicator validity specified in the = EventData class would require nested EventData instances to convey = different time period.  Also, some indicators are only in the = Incident class so this approach would be insufficient.  Perhaps a = hybrid approach where this timing information is in the EventData and = IncidentData classes could be possible.

 

Personally I think the = safest approach is validity per Indicator.  Validity for parent / = child would be rare and validity per Incident even rarer. =

 

One question, how do we = represent “still valid”? If I have an indicator that is = valid when I send the message how do I know what that time = represents?  If I put “12/20/2013 13:00” as the time = can you tell if I mean that it was still valid when I sent the message = at that time or that its validity period ended at that time. Those are = very different scenarios and critically important for searching / = responding to indicator hits.

 

Roman

 

------=_NextPart_001_067F_01CEFDA4.7E6BF030-- ------=_NextPart_000_067E_01CEFDA4.7E6BC920 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIY2DCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIEzDCCA7SgAwIBAgIQfwkpTisxI69dQcDR3n6N2TANBgkqhkiG9w0BAQUFADA6 MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkgMjA0OCBW MzAeFw0xMTAzMDMyMDUyMTVaFw0xOTA0MDExNDQ1MzlaMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaLCcEh7lhj dqYo6ryZ8oHK4kJRmQuxfwMa/3PE1Vd4U7U5x15UuSX+qd78hnEdR6yGGxhmY8U2SDG31u+yJD9o OpXFQm6/A4xzItwfcs6SD3Gt6nI/Oa6M0M/7MjPqSc1aUUm2NFiyb6DjotYLDzeAVCqF+4V/Dgc2 QdO1FZeFUCcb5lMqkVAr+O3uAEZEmtD3Cr06YavA38fxeWCiPoheUuWuAQcvOdEnSzJFm6GM8yBJ l9J1cAibE6c4DCl+eHj4M+O/ON2fFVb/lQdS4xO7cSZ9fKGCI7kWr0/7ssSjPsIIGpg0hLRZ35aZ fCK1fFLi9VKvIcTYTrA8Gf9bIGsCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk +v8kLDPQsZ2MMBIGA1UdEwEB/wQIMAYBAf8CAQMwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3 dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0 YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwHQYDVR0OBBYEFHMbOEsly1qOvQLs310p9hB0 DtiYMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUGATB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2Eu cnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExM QzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTAOBgNVHQ8BAf8EBAMCAYYwDQYJ KoZIhvcNAQEFBQADggEBAHGIVCAjCZ+z2vRElolRsLsz4L/js0Zm019rr/+eFks5VnSf5T0HJj7Z tzjtna/+O5b01L8L6Fz64Yui+h/cnxvDwQrhzajbiMiN/JFH+kNOUJ9LcInBkmu45d98h+EQw3Yz XwfnHYaXLArfgeY3CP8AYi0pxXEXf0bH8Prl+P0n4SOUqxh6J0GIz/haW1+usvMscB7lCpJ2loo9 +TmRn3WQrokgr1ILm/3apel6ydpkoFUxEoP5a1806Z7SD9KljN+Vc9o521VkMtnzLlDEkn05by/p QNdlidY7eV7xcpCvuI6qFzyfHdI3G0/Vao0L0os6lEwb5PSa1IysLlHT0uUwggT+MIID5qADAgEC AhBiTV1a7zr4E+gcgJ4lG6TBMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjAeFw0xMTAzMTAyMjQwMDRaFw0xOTAyMjgyMTU2MzNaMIGeMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UE ChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlv bjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDNEVsNPFZOP83bMzCpUDGnf/5IDIQvVRhDHkyrkbv5X1ih4xdTsSdzTDrj LUxIzC7nJswCv+jBaWWm1YoqzBXqQl2/Hl6T5Bt3HBT302GSYamtKcCWve25DoJav+dJd9U/XkCq SSNN7DNVXkJrKC7Zq7OS6/O308pZNkCRJJfMRrodgSx1NoQYZJCfufTOshslVSVhj3Ar274qmuf8 iqM0RR5OMpm7t2dtHzvYJPHR3+HwfQ+s64YBC7NBrBLOYMeq8tzkPKzyITXhwopgbM6gbp+Z8qX5 /lo4Y3OEm7ED51iDqdruRoRnfTQGKdZJT7IYGLH+x0roRKmYKP/2HRNpAgMBAAGjggE7MIIBNzAP BgNVHRMECDAGAQH/AgECMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUHAjB2MC4GCCsGAQUFBwIB FiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNB IFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTBABgNVHR8E OTA3MDWgM6Axhi9odHRwOi8vY3JsLnJzYXNlY3VyaXR5LmNvbS9SU0FDb3Jwb3JhdGVDQXYyLmNy bDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFBQw62v19Em1aFJ1ptu9rlvIrH1MMB8GA1UdIwQY MBaAFHMbOEsly1qOvQLs310p9hB0DtiYMA0GCSqGSIb3DQEBBQUAA4IBAQCPepLT4buLa9p5VwF1 OW2YUwliCqxecs0CxRGJVR4cwvOuMeXxutP+m51n3vzseGkM0d1fmA9JTz8X+5LFdRD12Iw124oj 79QA7NKhO/xoPgbo0QxgnvHS15o94BPvFiZE6QGUjkHs9/hDvU+eIx7OG+Kzxt47vZZef+fJF0+s ZgEDIMXXPXAtJW3xg/JhPrl4z0L7gmjgO+KxV0cyxaDrk6SEW5zZCqAcLehnW7MH8vvlzMsQ6pVr f1g8xMCJonyxow9AwXGyQ0z1866qbJ8t+nQC/sGx3msJVHQg1JyjOWF4PMm8DdeUt+qUrSFRLY4J MroY51gM90nnhtijtleCMIIFxTCCBK2gAwIBAgIRAIQ3oNuoPqBS3YhDUJp3rlQwDQYJKoZIhvcN AQEFBQAwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdC ZWRmb3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJp dHkgT3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MjAeFw0x MzA2MTkxMTAwNThaFw0xNTA2MTkxMTAwNThaMIHvMRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYK CZImiZPyLGQBGRYDZW1jMRgwFgYDVQQKEw9FTUMgQ29ycG9yYXRpb24xETAPBgNVBAsTCEFtZXJp Y2FzMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMQ8wDQYDVQQFEwYxMjI3NjUxFzAVBgoJ kiaJk/IsZAEBEwdoYXJyaWM4MR8wHQYDVQQDExZDaHJpc3RvcGhlciBIYXJyaW5ndG9uMS0wKwYJ KoZIhvcNAQkBFh5jaHJpc3RvcGhlci5oYXJyaW5ndG9uQGVtYy5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIBKcM4e/EfofFwfGGTTzP9Q5h+TbnMfUHaXkYleI6YteMOkHmp+f3 6y9+TztCDzpypIBDHJ61t9jP3Wl1ktHiRvXUyjvciaJuVGNSlhqik/9i94jfWeb0Tw5bjFWgnFyW f4nk51Zu2NvMfCVA3Uu6PS7pf1vWkkDs37XIX3zHeATa189aQRHS8enAItBbC8aE38b+H4Umy2Nm IQQFtXbkB3pzzBImFujgbZdx8PrjRmBaIfXNXIaLDkTc8VmF1MkxSk2Gwt4BeLE5xGMWtTqXv3j8 D7YTk416tj/vIpe+t/cSa7eiydNP74no4GMSRhY4Z6iaX+A+kCTshLze/4w5AgMBAAGjggGpMIIB pTAfBgNVHSMEGDAWgBQUMOtr9fRJtWhSdabbva5byKx9TDCBkQYDVR0gBIGJMIGGMIGDBgkqhkiG 9w0FBwUwdjAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBE BggrBgEFBQcCAjA4MBcWEFJTQSBTZWN1cml0eSBMTEMwAwIBARodQ1BTIEluY29ycG9yYXRlZCBi eSByZWZlcmVuY2UwKQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMEoG A1UdEQRDMEGBHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbaAfBgorBgEEAYI3FAIDoBEM D2hhcnJpYzhAZW1jLmNvbTAOBgNVHQ8BAf8EBAMCB4AwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDov L2NybC5yc2FzZWN1cml0eS5jb206ODAvUlNBQ2xhc3MyUGVyc29uYWxDQXYyLmNybDAdBgNVHQ4E FgQU8PcZ+AZ1SlXp4EE3P4yjbslfqpIwDQYJKoZIhvcNAQEFBQADggEBAL9Or82VcAEw1PGuPbBD QzDy1rwrjFwoN9nMuNaMdqtgNlhhiHldOOlccTiXJVMykbmY3brFqTnvwCA9vMnJJnRqHPfZp5ic waWVpn8H50FHx0o4ftycPEl0oH9RPOJgDc/t/jHpLpLB94kHxyxQ4vJundplDbR2LYsUZa03GBMo hvfMuiKw0CeBr1R7x4WIiseWQ4KB71zmW3AbsYI9y0q9DlHIgtNmfOj84tY9f2QC3ndMkmSGvmMm X7DWCMnlHPN+0FiRkMqOeoYFwRaTeRM1i2Sm91E83TNRmb7f6xzIc4mLsHKP2Jui5nA/V8NWvTqI YhCkCB0cZkc91ehe4n4wggXUMIIEvKADAgECAhAzkGSOsA6fNPJDSK+W/N5kMA0GCSqGSIb3DQEB BQUAMIGeMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVk Zm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5 IE9yZ2FuaXphdGlvbjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwHhcNMTMw NjE5MTUwNDQ1WhcNMTUwNjE5MTUwNDIxWjCB8zETMBEGCgmSJomT8ixkARkWA2NvbTETMBEGCgmS JomT8ixkARkWA2VtYzEYMBYGA1UEChMPRU1DIENvcnBvcmF0aW9uMREwDwYDVQQLEwhBbWVyaWNh czEcMBoGA1UECxMTSW5mb3JtYXRpb24gU3lzdGVtczEPMA0GA1UEBRMGMTIyNzY1MRcwFQYKCZIm iZPyLGQBARMHaGFycmljODEjMCEGA1UEAxMaQ2hyaXN0b3BoZXIgSGFycmluZ3Rvbi1FbmMxLTAr BgkqhkiG9w0BCQEWHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBALkuHI2WDll/BOd40HVywnDJpkxwxGs0Hpqxmikq298tLVn4QxLr LhdIFtW+8Ish3Cfat2810FCTAbmh855JYkAJlj2zMx5s4hri45l4cRpRVeWxdH0o5X278NS2ZXU2 DDJAa3Dx46gTz9/xRE4EAoHtMhr5Vr9rDOqkfCmAZmd1kOeQF3W1SmUgaPxEIHp27s0Sso5khGdc 2/2GyEmos4dJ86PaaZbpf9lcZwC5LVfcpa9ZOXh6bqd7U8hDznZ5PRJB6k+CAFBrt+WiYvsYG7is IYIPXrCkUVuRYkXupXqXqu5OEs3ANeAG+ehJxn6Ww+mZeYJfOSAWLARLWsI5ZGsCAwEAAaOCAbUw ggGxMDUGA1UdJQQuMCwGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoD BDAfBgNVHSMEGDAWgBQUMOtr9fRJtWhSdabbva5byKx9TDCBkQYDVR0gBIGJMIGGMIGDBgkqhkiG 9w0FBwUwdjAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBE BggrBgEFBQcCAjA4MBcWEFJTQSBTZWN1cml0eSBMTEMwAwIBARodQ1BTIEluY29ycG9yYXRlZCBi eSByZWZlcmVuY2UwSgYDVR0RBEMwQYEeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29toB8G CisGAQQBgjcUAgOgEQwPaGFycmljOEBlbWMuY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9j cmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNvbmFsQ0F2Mi5jcmwwHQYDVR0OBBYE FFp5a07UDPJYJvedFEuB1U2ACAW1MA4GA1UdDwEB/wQEAwIDODANBgkqhkiG9w0BAQUFAAOCAQEA PaMUkDlrJh/pKXE9hwn4NJny1feBdfjqRUlziiKo3/+Jwn3YToU+nh+uic4anPiw+Iv1N1apK5mW aPCu36xFhgtVBnbSJQ0c+Aeal1HxRttlJp2AtQ8WBYN2eJ7NkEHajhTU+49GL6woFU9cKS+GI9cp QU6H2E/eYe628ngK/sTqfUF2HZalvwLcQZAr7RkrLcOYt8PsXFZmijVGZC76wI4xRfo4o9Of1epL jZ0FmhRy3sfnLuEmDBuOOnlQSkyBUinHcv0g0QhZ8WOvhocAvobbYXk67ADjRF2MV/J6jHq+lQVG p5/DLic0VM0W/gRcpZmZu5DYeK/TJD8ohGaq1zGCBHswggR3AgEBMIG0MIGeMQswCQYDVQQGEwJV UzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEG A1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjICEQCEN6DbqD6gUt2IQ1Cad65UMAkGBSsO AwIaBQCgggKbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTIy MDIxNTY1N1owIwYJKoZIhvcNAQkEMRYEFNxaCdlI4njHLbKlPfGcXl4+xPFvMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHEBgkrBgEE AYI3EAQxgbYwgbMwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYD VQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwg U2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2 MgIQM5BkjrAOnzTyQ0ivlvzeZDCBxgYLKoZIhvcNAQkQAgsxgbaggbMwgZ4xCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0Eg U2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYD VQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MgIQM5BkjrAOnzTyQ0ivlvzeZDANBgkqhkiG 9w0BAQEFAASCAQBNo2xdnM/rWAYmNnpmxuPdQOYVbEpkUr2w4vUTOp6E4EC9DerI2F43SlH17WE3 GuKOhqwRBPAQh4hSXj+bhWeqinKx9A+jBQ+7XJ6QOdUcqDmgAoHxnqToGzwLVC91GxYgpq+ZSiXG aIPUznOaa6lMztLIL1uTcFs/74Ug6oqRijAgYZaLk1isBDQRJMXFYEfIWKPM5+sKJv7oH3AKKMzV 3UPmC4j5vOF8SR3eoVkPmHUd4vg37bN/bJbZwPEp4bri7nZGQh0UHxeyqzz3pjrL+Mv7xq54X4M6 k8qALrHAgsProi+GqRLJSV/ruH3lrl0pmh+6b1YY+xeSu5EvtKfkAAAAAAAA ------=_NextPart_000_067E_01CEFDA4.7E6BC920-- From Paul.Stoecker@rsa.com Mon Dec 23 07:29:20 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299901AE109 for ; Mon, 23 Dec 2013 07:29:20 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 APHmwyRnCQT9 for ; Mon, 23 Dec 2013 07:29:17 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id DC8E21AE104 for ; Mon, 23 Dec 2013 07:29:16 -0800 (PST) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBNFT5Pp014037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Dec 2013 10:29:09 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com rBNFT5Pp014037 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1387812550; bh=sELtc6NU3mw6XDFmVianyTszApA=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=FCzfEQaIbvliuXmXs+bEzR5vWbi13jBQg3qEaZQeOfzLY7sgJ/GfYnHNR/nU4e7Fj eAFh8t9k25NRVm2y8Ei7cB34HbGrrgWy2n9mSAgvp/u4SVrAzCgvWkjCKcI9twYlmM 9qIYG3z3Wy/6AC88HN84PmSzQnjDXyW9HlBp5iw8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com rBNFT5Pp014037 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd06.lss.emc.com (RSA Interceptor); Mon, 23 Dec 2013 07:28:57 -0800 Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBNFRxlG017051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Dec 2013 10:28:57 -0500 Received: from MXHUB105.corp.emc.com (10.253.50.22) by mxhub25.corp.emc.com (10.254.110.181) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 23 Dec 2013 10:26:13 -0500 Received: from MX103CL01.corp.emc.com ([169.254.5.132]) by MXHUB105.corp.emc.com ([10.253.50.22]) with mapi id 14.03.0158.001; Mon, 23 Dec 2013 10:26:13 -0500 From: "Stoecker, Paul" To: "Harrington, Christopher" Thread-Topic: [mile] Describing the time window during which an indicator should be used Thread-Index: Ac79wEREoR/sG5XCQ7SYud4bxnPHvAADNhDAAImM6KM= Date: Mon, 23 Dec 2013 15:26:12 +0000 Message-ID: <8E856A31-290B-4A4A-ABC5-DC7177E41B89@rsa.com> References: <359EC4B99E040048A7131E0F4E113AFC54BF92D2@marathon>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_8E856A31290B4A4AABC5DC7177E41B89rsacom_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Cc: "mile@ietf.org" Subject: Re: [mile] Describing the time window during which an indicator should be used X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 15:29:20 -0000 --_000_8E856A31290B4A4AABC5DC7177E41B89rsacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have a question...Do we really stop looking for IOCs whose time has expir= ed? Like a malicious URL whose time has expired...do you stop looking for = that URL? Let's say that Paul the malware dude got a hold of the IODEF doc= ument...I shutdown my web server and after the time expired I turned it bac= k on? Just wondering how IOC aging is actually handled? Sent from my iPhone On Dec 20, 2013, at 4:57 PM, "Harrington, Christopher" > wrote: Hello, Answers inline below. Thanks, --Chris Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Friday, December 20, 2013 4:26 PM To: mile@ietf.org Subject: [mile] Describing the time window during which an indicator should= be used Hello! Ticket #28 (http://trac.tools.ietf.org/wg/mile/trac/ticket/28) is tracking = the need to convey the valid time during which to apply an indicator. I wa= nted to solicit from the community the degree of flexibility desired. For = the purposes of this discussion an indicator is defined as a class that has= an @indicator-uid attribute. ** Does this flexibility need to exist on a per indicator basis? Example 1, Yes, a malicious URL would be valid only as long as it is live. ** Could it be at the EventData level (and the time window cascades to all = indicators that are children)? Example 2:, =85 =85 many domain indicators =85 Example 3: =85 2013/12/01 12:00:00 =85 =85 many domain indicators =85 Yes, you could have multiple malware delivery URLs that are all on the same= domain. If the Domain is specified at EvenData level then when it is no lo= nger valid the children would no longer be valid. I hope I explained that r= ight :) I am not sure how it would differ between Example 2 and 3. ** Could it be at the Incident level? Example 4: =85 2013/12/01 12:00:00 =85 many domain indicators =85 If there was only one Indicator in an incident it could be. In practical te= rms this is very unlikely. Per indicator time information would provide the most flexibility but would= require duplication of the same information. A time window for indicator validity specified at the Incident level would = not allow for multiple time windows per indicator. A time window for indicator validity specified in the EventData class would= require nested EventData instances to convey different time period. Also,= some indicators are only in the Incident class so this approach would be i= nsufficient. Perhaps a hybrid approach where this timing information is in= the EventData and IncidentData classes could be possible. Personally I think the safest approach is validity per Indicator. Validity= for parent / child would be rare and validity per Incident even rarer. One question, how do we represent =93still valid=94? If I have an indicator= that is valid when I send the message how do I know what that time represe= nts? If I put =9312/20/2013 13:00=94 as the time can you tell if I mean th= at it was still valid when I sent the message at that time or that its vali= dity period ended at that time. Those are very different scenarios and crit= ically important for searching / responding to indicator hits. Roman _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --_000_8E856A31290B4A4AABC5DC7177E41B89rsacom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I have a question...Do we really stop looking for IOCs whose time has = expired?  Like a malicious URL whose time has expired...do you stop lo= oking for that URL?  Let's say that Paul the malware dude got a hold o= f the IODEF document...I shutdown my web server and after the time expired I turned it back on?

Just wondering how IOC aging is actually handled?

Sent from my iPhone

On Dec 20, 2013, at 4:57 PM, "Harrington, Christopher" <Christopher.Harrington@emc.com<= /a>> wrote:

Hello,

 

Answers inline below. =

 

Thanks,

 

--Chris

 

Christopher Harrington=
Consulting Security Engineer
GSO - Critical Incident Response Center
EMC
174 Middlesex Turnpike
Bedford, MA 01730
781-515-5862 (work)
603-583-1585 (cell)

 

From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw
Sent: Friday, December 20, 2013 4:26 PM
To: mile@ietf.org
Subject: [mile] Describing the time window during which an indicator= should be used

 

Hello!

 

Ticket #28 (http://trac.tools.ietf.org/wg/mile/trac/ticket/28= ) is tracking the need to convey the valid time during which to apply an in= dicator.  I wanted to solicit from the community the degree of flexibility desired.  For the purposes of thi= s discussion an indicator is defined as a class that has an @indicator-uid = attribute.

 

** Does this flexibility need to exist on a per indi= cator basis?

Example 1, <Assessment indicator-uid=3D=94foo-123= 45=94 indicator-valid-stime=3D=942013/12/01 12:00:00=94>

Yes, a malicious URL w= ould be valid only as long as it is live.

 

** Could it be at the EventData level (and the time = window cascades to all indicators that are children)?

Example 2:, <EventData indicator-stime=3D=942013/= 12/01 12:00:00=94> =85 <Flow> =85 many domain indicators </Flow= > =85 </EventData>

Example 3: <EventData>  =85 <Indicator= StartTime>2013/12/01 12:00:00</IndicatorStartTime> =85 <Flow>= ; =85 many domain indicators </Flow> =85 </EventData>

Yes, you could have mu= ltiple malware delivery URLs that are all on the same domain. If the Domain= is specified at EvenData level then when it is no longer valid the childre= n would no longer be valid. I hope I explained that right J  I am not sure how it wou= ld differ between Example 2 and 3.

 

** Could it be at the Incident level?

Example 4: <Incident>  =85 <IndicatorS= tartTime>2013/12/01 12:00:00</IndicatorStartTime> =85 many domain = indicators </Flow> =85 </Incident>

If there was only one = Indicator in an incident it could be. In practical terms this is very unlik= ely.

 

Per indicator time information would provide the mos= t flexibility but would require duplication of the same information.

 

A time window for indicator validity specified at th= e Incident level would not allow for multiple time windows per indicator.

 

A time window for indicator validity specified in th= e EventData class would require nested EventData instances to convey differ= ent time period.  Also, some indicators are only in the Incident class= so this approach would be insufficient.  Perhaps a hybrid approach where this timing information is in the EventDat= a and IncidentData classes could be possible.

 

Personally I think the= safest approach is validity per Indicator.  Validity for parent / chi= ld would be rare and validity per Incident even rarer.

 

One question, how do w= e represent =93still valid=94? If I have an indicator that is valid when I = send the message how do I know what that time represents?  If I put = =9312/20/2013 13:00=94 as the time can you tell if I mean that it was still valid when I sent the message at that time or tha= t its validity period ended at that time. Those are very different scenario= s and critically important for searching / responding to indicator hits.

 

Roman

 

_______________________________________________
mile mailing list
mile@ietf.org
https://www.ie= tf.org/mailman/listinfo/mile
--_000_8E856A31290B4A4AABC5DC7177E41B89rsacom_-- From Paul.Stoecker@rsa.com Mon Dec 23 07:34:05 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304E21AE10B for ; Mon, 23 Dec 2013 07:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_SOFTFAIL=0.665] 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 SkqpP5v0OQur for ; Mon, 23 Dec 2013 07:34:03 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 73D8E1AE0FA for ; Mon, 23 Dec 2013 07:34:03 -0800 (PST) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBNFXs4e015380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Dec 2013 10:33:57 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com rBNFXs4e015380 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1387812838; bh=6CgdlmuHYTbOFEix+H6nsvDExTA=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=AG5LT2M+YcC7/XB6vNb5KXBXJ3FJNj+xvwnotx88w+o+FudfQYFt5SUC5X15ueCJq jKSqKsa0RdBc2+itEfrzxlGMupSBUP0P++eYf4NdaE3BRKVRQG4rZ80KlMuMXGGtD6 HrBpfnN0CPWJP410OtTd8xwPbGi3UseLoD6Q1PAU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com rBNFXs4e015380 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd53.lss.emc.com (RSA Interceptor); Mon, 23 Dec 2013 10:33:43 -0500 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBNFXhCo024251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Dec 2013 10:33:43 -0500 Received: from MXHUB105.corp.emc.com (10.253.50.22) by mxhub32.corp.emc.com (128.222.70.172) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 23 Dec 2013 10:33:42 -0500 Received: from MX103CL01.corp.emc.com ([169.254.5.132]) by MXHUB105.corp.emc.com ([10.253.50.22]) with mapi id 14.03.0158.001; Mon, 23 Dec 2013 10:33:42 -0500 From: "Stoecker, Paul" To: Jerome Athias Thread-Topic: [mile] Courses of action COA Thread-Index: AQHO/V/sPRQZR+qU30iZaGQRz5xGYZph7fjS Date: Mon, 23 Dec 2013 15:33:41 +0000 Message-ID: <66EDD72A-9DBC-4876-AD75-038D59BCD0A5@rsa.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Cc: "mile@ietf.org" , stix-discussion-list Structured Threat Information Expression/ST Subject: Re: [mile] Courses of action COA X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 15:34:05 -0000 I am always concerned about things like this where there is a provided mean= s of what to do or what actions to take. =20 What if the course of action is wrong? Or worse what if a nefarious person= were to put in a IODEF document where the course of action opened them up = for an attack? Is it good to have COA or would it be better to not have a COA and just sha= re the information to detect malicious activity and leave it to the analyst= s to understand the issue and respond as they see fit? Sent from my iPhone > On Dec 20, 2013, at 3:46 AM, "Jerome Athias" wro= te: >=20 > Hi, >=20 > I would like, if I may, try to join efforts on this one. >=20 > https://github.com/STIXProject/schemas/wiki/Proposal:-Add-Parameter_Obser= vables-field-to-CourseOfAction >=20 > Best regards >=20 > 2013/12/20 Roman D. Danyliw : >> Hello! >>=20 >>=20 >>=20 >> Ticket #32 (http://tools.ietf.org/wg/mile/trac/ticket/32) outlines the n= eed >> for a means to specify a predetermined course of action (COA) in the >> Expectation and HistoryItem class. Five implementation options were >> suggested. After review, I would propose adoption of a blend of #4 and = #5. >>=20 >>=20 >>=20 >> >>=20 >> ** Add a class named =93DefinedCOA=94 to Expectation and History Item >>=20 >>=20 >>=20 >> +-------------------+ >>=20 >> | Expectation | >>=20 >> +-------------------+ >>=20 >> | ENUM restriction |<>--{0..*}--[ Description ] >>=20 >> | ENUM severity |<>--{0..*}--[ DefinedCOA ] >>=20 >> | ENUM action |<>--{0..1}--[ StartTime ] >>=20 >> | STRING ext-action |<>--{0..1}--[ EndTime ] >>=20 >> | |<>--{0..1}--[ Contact ] >>=20 >> +-------------------+ >>=20 >>=20 >>=20 >> DefinedCOA >>=20 >> Zero or many. ML_STRING. A unique identifier meaningful to the >> sender and recipient of this document that references a course of action= . >> This class must be present if the action attribute is set to =93defined-= coa=94. >>=20 >>=20 >>=20 >> ** Add an =93defined-coa=94 to @action in Expectation and HistoryItem >>=20 >>=20 >>=20 >> 17. defined-coa. Perform a predefined course of action (COA). The COA= is >> named in the DefinedCOA class. >>=20 >> >>=20 >>=20 >>=20 >> Examples of this approach would look like the following: >>=20 >>=20 >>=20 >> [Example 1] >>=20 >> >>=20 >> >>=20 >> Procedure-A >>=20 >>=20 >>=20 >> [Example 2] >>=20 >> >>=20 >> >>=20 >> >>=20 >> Do the following ... >> Procedure-A >>=20 >>=20 >>=20 >> [Example 3] >>=20 >> >>=20 >> >>=20 >> Procedure-A >>=20 >> Procedure-B >>=20 >>=20 >>=20 >> Roman >>=20 >>=20 >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile >=20 From Christopher.Harrington@emc.com Mon Dec 23 07:46:20 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5425B1AE0C1 for ; Mon, 23 Dec 2013 07:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.46 X-Spam-Level: * X-Spam-Status: No, score=1.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_FRT_STOCK2=0.01] 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 pfVw9-gqaPeI for ; Mon, 23 Dec 2013 07:46:17 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id BD1D11ADEBA for ; Mon, 23 Dec 2013 07:46:16 -0800 (PST) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBNFk6Dr028672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Dec 2013 10:46:08 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com rBNFk6Dr028672 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1387813568; bh=+1rjqmlYt54ihLqhcdrPrXIT5cU=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=eHia4S+tF+bWog7Q4+yW5mcMZbsCuCA/8BlXQJseBpvF0onAXWjXqT5OVklWLt+O6 hPOC8/uykqr0jG9XDpfWPD4P64xBdv8T3Vs6hK4TPpwBcbsB3QIJWI4nZdwo90l60j J86k7JGyg7tj/6tGE703cQ2pYRboJ2XDaPRZg0O0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com rBNFk6Dr028672 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd04.lss.emc.com (RSA Interceptor); Mon, 23 Dec 2013 07:45:49 -0800 Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBNFjmIj031527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Dec 2013 10:45:48 -0500 Received: from mx36a.corp.emc.com ([169.254.1.232]) by mxhub36.corp.emc.com ([::1]) with mapi; Mon, 23 Dec 2013 10:45:47 -0500 From: "Harrington, Christopher" To: "Stoecker, Paul" Date: Mon, 23 Dec 2013 10:45:46 -0500 Thread-Topic: [mile] Describing the time window during which an indicator should be used Thread-Index: Ac79wEREoR/sG5XCQ7SYud4bxnPHvAADNhDAAImM6KMAAF0t0A== Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC54BF92D2@marathon>, <8E856A31-290B-4A4A-ABC5-DC7177E41B89@rsa.com> In-Reply-To: <8E856A31-290B-4A4A-ABC5-DC7177E41B89@rsa.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0736_01CEFFCC.22D615F0" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Cc: "mile@ietf.org" Subject: Re: [mile] Describing the time window during which an indicator should be used X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 15:46:20 -0000 ------=_NextPart_000_0736_01CEFFCC.22D615F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0737_01CEFFCC.22D615F0" ------=_NextPart_001_0737_01CEFFCC.22D615F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes we do stop looking. A good example is when NBC.com got hacked a few months ago. We watched for people hitting it while the URL was malicious. Once it was cleaned up we stopped watching for it since it was a somewhat popular URL that would fire all the time and bury us in false positives. Indicator aging is an area that nobody has a good handle one. Each organization seems to have their own way of doing things with aging, if they do anything at all. Some commercial threat intel providers use a decrementing counter based on the last time the indicator was seen. At EMC we make the aging calculation based on time since last seen, attribution (if known), kill chain stage, confidence in the source and other factors. It's not automated at this point. We can't keep all indicators forever. At some point the watch lists and block lists on your Proxy, firewall, etc get too large and the devices start having issues. We ran into this at EMC and had to switch from Proxy blocks for domains to DNS RPZ with a sinkhole web servers. There were too many domains in the proxy block list. We have tens of thousands. There are indicators that we consider "persistent". These are indicators that we always want to be alerted about. Generally these are advanced threat / APT and have either been seen in activity involving EMC or they belong to threat actor groups that we have seen at EMC. Thanks, --Chris From: Stoecker, Paul Sent: Monday, December 23, 2013 10:26 AM To: Harrington, Christopher Cc: Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] Describing the time window during which an indicator should be used I have a question...Do we really stop looking for IOCs whose time has expired? Like a malicious URL whose time has expired...do you stop looking for that URL? Let's say that Paul the malware dude got a hold of the IODEF document...I shutdown my web server and after the time expired I turned it back on? Just wondering how IOC aging is actually handled? Sent from my iPhone On Dec 20, 2013, at 4:57 PM, "Harrington, Christopher" wrote: Hello, Answers inline below. Thanks, --Chris Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Friday, December 20, 2013 4:26 PM To: mile@ietf.org Subject: [mile] Describing the time window during which an indicator should be used Hello! Ticket #28 (http://trac.tools.ietf.org/wg/mile/trac/ticket/28) is tracking the need to convey the valid time during which to apply an indicator. I wanted to solicit from the community the degree of flexibility desired. For the purposes of this discussion an indicator is defined as a class that has an @indicator-uid attribute. ** Does this flexibility need to exist on a per indicator basis? Example 1, Yes, a malicious URL would be valid only as long as it is live. ** Could it be at the EventData level (and the time window cascades to all indicators that are children)? Example 2:, . . many domain indicators . Example 3: . 2013/12/01 12:00:00 . . many domain indicators . Yes, you could have multiple malware delivery URLs that are all on the same domain. If the Domain is specified at EvenData level then when it is no longer valid the children would no longer be valid. I hope I explained that right J I am not sure how it would differ between Example 2 and 3. ** Could it be at the Incident level? Example 4: . 2013/12/01 12:00:00 . many domain indicators . If there was only one Indicator in an incident it could be. In practical terms this is very unlikely. Per indicator time information would provide the most flexibility but would require duplication of the same information. A time window for indicator validity specified at the Incident level would not allow for multiple time windows per indicator. A time window for indicator validity specified in the EventData class would require nested EventData instances to convey different time period. Also, some indicators are only in the Incident class so this approach would be insufficient. Perhaps a hybrid approach where this timing information is in the EventData and IncidentData classes could be possible. Personally I think the safest approach is validity per Indicator. Validity for parent / child would be rare and validity per Incident even rarer. One question, how do we represent "still valid"? If I have an indicator that is valid when I send the message how do I know what that time represents? If I put "12/20/2013 13:00" as the time can you tell if I mean that it was still valid when I sent the message at that time or that its validity period ended at that time. Those are very different scenarios and critically important for searching / responding to indicator hits. Roman _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_001_0737_01CEFFCC.22D615F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes we do stop looking. A good example is when = NBC.com got hacked a few months ago. We watched for people hitting it = while the URL was malicious. Once it was cleaned up we stopped watching = for it since it was a somewhat popular  URL that would fire all the = time and bury us in false positives.

 

Indicator aging is an = area that nobody has a good handle one. Each organization seems to have = their own way of doing things with aging, if they do anything at all. = Some commercial threat intel providers use a decrementing counter based = on the last time the indicator was seen. At EMC we make the aging = calculation based on time since last seen, attribution (if known), kill = chain stage, confidence in the source  and other factors. = It’s not automated at this point.

 

We can’t keep all = indicators forever. At some point the watch lists and block lists on = your Proxy, firewall, etc get too large and the devices start having = issues. We ran into this at EMC and had to switch from Proxy blocks for = domains to DNS RPZ with a sinkhole web servers. There were too many = domains in the proxy block list. We have tens of thousands. There are = indicators that we consider “persistent”. These are = indicators that we always want to be alerted about. Generally these are = advanced threat / APT and have either been seen in activity involving = EMC or they belong to threat actor groups that we have seen at EMC. =

 

Thanks,

 

--Chris

 

From:= = Stoecker, Paul
Sent: Monday, December 23, 2013 10:26 = AM
To: Harrington, Christopher
Cc: Roman D. Danyliw; = mile@ietf.org
Subject: Re: [mile] Describing the time window = during which an indicator should be = used

 

I have = a question...Do we really stop looking for IOCs whose time has expired? =  Like a malicious URL whose time has expired...do you stop looking = for that URL?  Let's say that Paul the malware dude got a hold of = the IODEF document...I shutdown my web server and after the time expired = I turned it back on?

 

Just wondering how IOC aging is actually = handled?

Sent from my iPhone


On Dec 20, 2013, at = 4:57 PM, "Harrington, Christopher" <Christopher.Harrington@emc= .com> wrote:

Hello,

 

Answers inline below. =

 

Thanks,

 

--Chris

 

Christopher = Harrington
Consulting Security Engineer
GSO - Critical Incident = Response Center
EMC
174 Middlesex Turnpike
Bedford, MA = 01730
781-515-5862 (work)
603-583-1585 = (cell)

 

From:= = mile [mailto:mile-bounces@ietf.org] = On Behalf Of Roman D. Danyliw
Sent: Friday, December = 20, 2013 4:26 PM
To: mile@ietf.org
Subject: = [mile] Describing the time window during which an indicator should be = used

 

Hello!

 

Ticket #28 = (http://trac.to= ols.ietf.org/wg/mile/trac/ticket/28) is tracking the need to convey = the valid time during which to apply an indicator.  I wanted to = solicit from the community the degree of flexibility desired.  For = the purposes of this discussion an indicator is defined as a class that = has an @indicator-uid attribute.

 

** Does this = flexibility need to exist on a per indicator basis?

Example 1, <Assessment = indicator-uid=3D”foo-12345” = indicator-valid-stime=3D”2013/12/01 = 12:00:00”>

Yes, a malicious URL would be valid only as long = as it is live.

 

** Could it = be at the EventData level (and the time window cascades to all = indicators that are children)?

Example 2:, <EventData = indicator-stime=3D”2013/12/01 12:00:00”> … = <Flow> … many domain indicators </Flow> … = </EventData>

Example 3: = <EventData>  … <IndicatorStartTime>2013/12/01 = 12:00:00</IndicatorStartTime> … <Flow> … many = domain indicators </Flow> … = </EventData>

Yes, you could have multiple malware delivery = URLs that are all on the same domain. If the Domain is specified at = EvenData level then when it is no longer valid the children would no = longer be valid. I hope I explained that right J  I am not sure how it would differ between = Example 2 and 3.

 

** Could it be at the Incident level?

Example 4: <Incident>  … = <IndicatorStartTime>2013/12/01 12:00:00</IndicatorStartTime> = … many domain indicators </Flow> … = </Incident>

If there was only one Indicator in an incident = it could be. In practical terms this is very unlikely. =

 

Per indicator time information would provide the most = flexibility but would require duplication of the same = information.

 

A time window for indicator validity specified at the = Incident level would not allow for multiple time windows per = indicator.

 

A time window for indicator validity specified in the = EventData class would require nested EventData instances to convey = different time period.  Also, some indicators are only in the = Incident class so this approach would be insufficient.  Perhaps a = hybrid approach where this timing information is in the EventData and = IncidentData classes could be possible.

 

Personally I think the = safest approach is validity per Indicator.  Validity for parent / = child would be rare and validity per Incident even rarer. =

 

One question, how do we = represent “still valid”? If I have an indicator that is = valid when I send the message how do I know what that time = represents?  If I put “12/20/2013 13:00” as the time = can you tell if I mean that it was still valid when I sent the message = at that time or that its validity period ended at that time. Those are = very different scenarios and critically important for searching / = responding to indicator hits.

 

Roman

 

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

<= /body> ------=_NextPart_001_0737_01CEFFCC.22D615F0-- ------=_NextPart_000_0736_01CEFFCC.22D615F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIY2DCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIEzDCCA7SgAwIBAgIQfwkpTisxI69dQcDR3n6N2TANBgkqhkiG9w0BAQUFADA6 MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkgMjA0OCBW MzAeFw0xMTAzMDMyMDUyMTVaFw0xOTA0MDExNDQ1MzlaMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaLCcEh7lhj dqYo6ryZ8oHK4kJRmQuxfwMa/3PE1Vd4U7U5x15UuSX+qd78hnEdR6yGGxhmY8U2SDG31u+yJD9o OpXFQm6/A4xzItwfcs6SD3Gt6nI/Oa6M0M/7MjPqSc1aUUm2NFiyb6DjotYLDzeAVCqF+4V/Dgc2 QdO1FZeFUCcb5lMqkVAr+O3uAEZEmtD3Cr06YavA38fxeWCiPoheUuWuAQcvOdEnSzJFm6GM8yBJ l9J1cAibE6c4DCl+eHj4M+O/ON2fFVb/lQdS4xO7cSZ9fKGCI7kWr0/7ssSjPsIIGpg0hLRZ35aZ fCK1fFLi9VKvIcTYTrA8Gf9bIGsCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk +v8kLDPQsZ2MMBIGA1UdEwEB/wQIMAYBAf8CAQMwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3 dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0 YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwHQYDVR0OBBYEFHMbOEsly1qOvQLs310p9hB0 DtiYMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUGATB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2Eu cnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExM QzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTAOBgNVHQ8BAf8EBAMCAYYwDQYJ KoZIhvcNAQEFBQADggEBAHGIVCAjCZ+z2vRElolRsLsz4L/js0Zm019rr/+eFks5VnSf5T0HJj7Z tzjtna/+O5b01L8L6Fz64Yui+h/cnxvDwQrhzajbiMiN/JFH+kNOUJ9LcInBkmu45d98h+EQw3Yz XwfnHYaXLArfgeY3CP8AYi0pxXEXf0bH8Prl+P0n4SOUqxh6J0GIz/haW1+usvMscB7lCpJ2loo9 +TmRn3WQrokgr1ILm/3apel6ydpkoFUxEoP5a1806Z7SD9KljN+Vc9o521VkMtnzLlDEkn05by/p QNdlidY7eV7xcpCvuI6qFzyfHdI3G0/Vao0L0os6lEwb5PSa1IysLlHT0uUwggT+MIID5qADAgEC AhBiTV1a7zr4E+gcgJ4lG6TBMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjAeFw0xMTAzMTAyMjQwMDRaFw0xOTAyMjgyMTU2MzNaMIGeMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UE ChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlv bjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDNEVsNPFZOP83bMzCpUDGnf/5IDIQvVRhDHkyrkbv5X1ih4xdTsSdzTDrj LUxIzC7nJswCv+jBaWWm1YoqzBXqQl2/Hl6T5Bt3HBT302GSYamtKcCWve25DoJav+dJd9U/XkCq SSNN7DNVXkJrKC7Zq7OS6/O308pZNkCRJJfMRrodgSx1NoQYZJCfufTOshslVSVhj3Ar274qmuf8 iqM0RR5OMpm7t2dtHzvYJPHR3+HwfQ+s64YBC7NBrBLOYMeq8tzkPKzyITXhwopgbM6gbp+Z8qX5 /lo4Y3OEm7ED51iDqdruRoRnfTQGKdZJT7IYGLH+x0roRKmYKP/2HRNpAgMBAAGjggE7MIIBNzAP BgNVHRMECDAGAQH/AgECMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUHAjB2MC4GCCsGAQUFBwIB FiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNB IFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTBABgNVHR8E OTA3MDWgM6Axhi9odHRwOi8vY3JsLnJzYXNlY3VyaXR5LmNvbS9SU0FDb3Jwb3JhdGVDQXYyLmNy bDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFBQw62v19Em1aFJ1ptu9rlvIrH1MMB8GA1UdIwQY MBaAFHMbOEsly1qOvQLs310p9hB0DtiYMA0GCSqGSIb3DQEBBQUAA4IBAQCPepLT4buLa9p5VwF1 OW2YUwliCqxecs0CxRGJVR4cwvOuMeXxutP+m51n3vzseGkM0d1fmA9JTz8X+5LFdRD12Iw124oj 79QA7NKhO/xoPgbo0QxgnvHS15o94BPvFiZE6QGUjkHs9/hDvU+eIx7OG+Kzxt47vZZef+fJF0+s ZgEDIMXXPXAtJW3xg/JhPrl4z0L7gmjgO+KxV0cyxaDrk6SEW5zZCqAcLehnW7MH8vvlzMsQ6pVr f1g8xMCJonyxow9AwXGyQ0z1866qbJ8t+nQC/sGx3msJVHQg1JyjOWF4PMm8DdeUt+qUrSFRLY4J MroY51gM90nnhtijtleCMIIFxTCCBK2gAwIBAgIRAIQ3oNuoPqBS3YhDUJp3rlQwDQYJKoZIhvcN AQEFBQAwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdC ZWRmb3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJp dHkgT3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MjAeFw0x MzA2MTkxMTAwNThaFw0xNTA2MTkxMTAwNThaMIHvMRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYK CZImiZPyLGQBGRYDZW1jMRgwFgYDVQQKEw9FTUMgQ29ycG9yYXRpb24xETAPBgNVBAsTCEFtZXJp Y2FzMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMQ8wDQYDVQQFEwYxMjI3NjUxFzAVBgoJ kiaJk/IsZAEBEwdoYXJyaWM4MR8wHQYDVQQDExZDaHJpc3RvcGhlciBIYXJyaW5ndG9uMS0wKwYJ KoZIhvcNAQkBFh5jaHJpc3RvcGhlci5oYXJyaW5ndG9uQGVtYy5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIBKcM4e/EfofFwfGGTTzP9Q5h+TbnMfUHaXkYleI6YteMOkHmp+f3 6y9+TztCDzpypIBDHJ61t9jP3Wl1ktHiRvXUyjvciaJuVGNSlhqik/9i94jfWeb0Tw5bjFWgnFyW f4nk51Zu2NvMfCVA3Uu6PS7pf1vWkkDs37XIX3zHeATa189aQRHS8enAItBbC8aE38b+H4Umy2Nm IQQFtXbkB3pzzBImFujgbZdx8PrjRmBaIfXNXIaLDkTc8VmF1MkxSk2Gwt4BeLE5xGMWtTqXv3j8 D7YTk416tj/vIpe+t/cSa7eiydNP74no4GMSRhY4Z6iaX+A+kCTshLze/4w5AgMBAAGjggGpMIIB pTAfBgNVHSMEGDAWgBQUMOtr9fRJtWhSdabbva5byKx9TDCBkQYDVR0gBIGJMIGGMIGDBgkqhkiG 9w0FBwUwdjAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBE BggrBgEFBQcCAjA4MBcWEFJTQSBTZWN1cml0eSBMTEMwAwIBARodQ1BTIEluY29ycG9yYXRlZCBi eSByZWZlcmVuY2UwKQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMEoG A1UdEQRDMEGBHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbaAfBgorBgEEAYI3FAIDoBEM D2hhcnJpYzhAZW1jLmNvbTAOBgNVHQ8BAf8EBAMCB4AwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDov L2NybC5yc2FzZWN1cml0eS5jb206ODAvUlNBQ2xhc3MyUGVyc29uYWxDQXYyLmNybDAdBgNVHQ4E FgQU8PcZ+AZ1SlXp4EE3P4yjbslfqpIwDQYJKoZIhvcNAQEFBQADggEBAL9Or82VcAEw1PGuPbBD QzDy1rwrjFwoN9nMuNaMdqtgNlhhiHldOOlccTiXJVMykbmY3brFqTnvwCA9vMnJJnRqHPfZp5ic waWVpn8H50FHx0o4ftycPEl0oH9RPOJgDc/t/jHpLpLB94kHxyxQ4vJundplDbR2LYsUZa03GBMo hvfMuiKw0CeBr1R7x4WIiseWQ4KB71zmW3AbsYI9y0q9DlHIgtNmfOj84tY9f2QC3ndMkmSGvmMm X7DWCMnlHPN+0FiRkMqOeoYFwRaTeRM1i2Sm91E83TNRmb7f6xzIc4mLsHKP2Jui5nA/V8NWvTqI YhCkCB0cZkc91ehe4n4wggXUMIIEvKADAgECAhAzkGSOsA6fNPJDSK+W/N5kMA0GCSqGSIb3DQEB BQUAMIGeMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVk Zm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5 IE9yZ2FuaXphdGlvbjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwHhcNMTMw NjE5MTUwNDQ1WhcNMTUwNjE5MTUwNDIxWjCB8zETMBEGCgmSJomT8ixkARkWA2NvbTETMBEGCgmS JomT8ixkARkWA2VtYzEYMBYGA1UEChMPRU1DIENvcnBvcmF0aW9uMREwDwYDVQQLEwhBbWVyaWNh czEcMBoGA1UECxMTSW5mb3JtYXRpb24gU3lzdGVtczEPMA0GA1UEBRMGMTIyNzY1MRcwFQYKCZIm iZPyLGQBARMHaGFycmljODEjMCEGA1UEAxMaQ2hyaXN0b3BoZXIgSGFycmluZ3Rvbi1FbmMxLTAr BgkqhkiG9w0BCQEWHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBALkuHI2WDll/BOd40HVywnDJpkxwxGs0Hpqxmikq298tLVn4QxLr LhdIFtW+8Ish3Cfat2810FCTAbmh855JYkAJlj2zMx5s4hri45l4cRpRVeWxdH0o5X278NS2ZXU2 DDJAa3Dx46gTz9/xRE4EAoHtMhr5Vr9rDOqkfCmAZmd1kOeQF3W1SmUgaPxEIHp27s0Sso5khGdc 2/2GyEmos4dJ86PaaZbpf9lcZwC5LVfcpa9ZOXh6bqd7U8hDznZ5PRJB6k+CAFBrt+WiYvsYG7is IYIPXrCkUVuRYkXupXqXqu5OEs3ANeAG+ehJxn6Ww+mZeYJfOSAWLARLWsI5ZGsCAwEAAaOCAbUw ggGxMDUGA1UdJQQuMCwGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoD BDAfBgNVHSMEGDAWgBQUMOtr9fRJtWhSdabbva5byKx9TDCBkQYDVR0gBIGJMIGGMIGDBgkqhkiG 9w0FBwUwdjAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBE BggrBgEFBQcCAjA4MBcWEFJTQSBTZWN1cml0eSBMTEMwAwIBARodQ1BTIEluY29ycG9yYXRlZCBi eSByZWZlcmVuY2UwSgYDVR0RBEMwQYEeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29toB8G CisGAQQBgjcUAgOgEQwPaGFycmljOEBlbWMuY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9j cmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNvbmFsQ0F2Mi5jcmwwHQYDVR0OBBYE FFp5a07UDPJYJvedFEuB1U2ACAW1MA4GA1UdDwEB/wQEAwIDODANBgkqhkiG9w0BAQUFAAOCAQEA PaMUkDlrJh/pKXE9hwn4NJny1feBdfjqRUlziiKo3/+Jwn3YToU+nh+uic4anPiw+Iv1N1apK5mW aPCu36xFhgtVBnbSJQ0c+Aeal1HxRttlJp2AtQ8WBYN2eJ7NkEHajhTU+49GL6woFU9cKS+GI9cp QU6H2E/eYe628ngK/sTqfUF2HZalvwLcQZAr7RkrLcOYt8PsXFZmijVGZC76wI4xRfo4o9Of1epL jZ0FmhRy3sfnLuEmDBuOOnlQSkyBUinHcv0g0QhZ8WOvhocAvobbYXk67ADjRF2MV/J6jHq+lQVG p5/DLic0VM0W/gRcpZmZu5DYeK/TJD8ohGaq1zGCBHswggR3AgEBMIG0MIGeMQswCQYDVQQGEwJV UzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEG A1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjICEQCEN6DbqD6gUt2IQ1Cad65UMAkGBSsO AwIaBQCgggKbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTIy MzE1NDU0NlowIwYJKoZIhvcNAQkEMRYEFPV7rYNR3UBlQCw9oMo4c7MerPKsMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHEBgkrBgEE AYI3EAQxgbYwgbMwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYD VQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwg U2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2 MgIQM5BkjrAOnzTyQ0ivlvzeZDCBxgYLKoZIhvcNAQkQAgsxgbaggbMwgZ4xCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0Eg U2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYD VQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MgIQM5BkjrAOnzTyQ0ivlvzeZDANBgkqhkiG 9w0BAQEFAASCAQB8HvjVaFuk71FDrvDEqGPGxTMrUZilsVQykhWZW5WuPehR+AVh9Q5v9e7+/QSk QIBUkvgfynujLbriUypiopEBYxhX5O+3bPJ47peOaEr+Gaawk+X7yveEFQS0EYfPTEXW2t3pEWuI vwvxbUi+wWkgN1it2Ekitv8A1Evg/HGFDyxqevWzWnTxCH9JpiL1UNvBYaqhmuxZWsLvyGhbPF+r B5wNkoaqNUmSMos/JEBSYG5cnk734E9JjiPAygtSpM/ZlMh0Ze/Zwj3x/yEhPxA+QsOApTqIoVrj ve3j92sgAs7cmKD5Vr5uGjhotfc0vqn4EFD6LMFBOzKK3hE/XKfCAAAAAAAA ------=_NextPart_000_0736_01CEFFCC.22D615F0-- From Christopher.Harrington@emc.com Mon Dec 23 10:03:48 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D651AE249 for ; Mon, 23 Dec 2013 10:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.459 X-Spam-Level: * X-Spam-Status: No, score=1.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_STOCK2=3.988, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_FRT_STOCK2=0.01] 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 Znb9hzs0hIw7 for ; Mon, 23 Dec 2013 10:03:47 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 953FA1AE23E for ; Mon, 23 Dec 2013 10:03:45 -0800 (PST) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBNI3b4M009157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Dec 2013 13:03:38 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com rBNI3b4M009157 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1387821818; bh=4pqILyAnFwTrTnYGXAucjOLYIdc=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=h/4EdP6F8ap5uUrMizm9LSmizF82Os/pBEIJZgZlUSD0Wt/ANmkMutxmgnc1k3iy9 023NJlBlbsqBMenkNEvZlHKAlx2RG7TEx3zEOhL9+zznFrvihwyw9L/N7l+BvDCRvB EOP3pzYIXAH/aH6U8/mZ6S553OSh7FceANZMiw0s= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com rBNI3b4M009157 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd04.lss.emc.com (RSA Interceptor); Mon, 23 Dec 2013 10:03:27 -0800 Received: from mxhub38.corp.emc.com (mxhub38.corp.emc.com [128.222.70.105]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBNI3RZ4013831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Dec 2013 13:03:27 -0500 Received: from mx36a.corp.emc.com ([169.254.1.232]) by mxhub38.corp.emc.com ([128.222.70.105]) with mapi; Mon, 23 Dec 2013 13:03:26 -0500 From: "Harrington, Christopher" To: "Stoecker, Paul" , Jerome Athias Date: Mon, 23 Dec 2013 13:03:24 -0500 Thread-Topic: [mile] Courses of action COA Thread-Index: AQHO/V/sPRQZR+qU30iZaGQRz5xGYZph7fjSgAAomOA= Message-ID: References: <66EDD72A-9DBC-4876-AD75-038D59BCD0A5@rsa.com> In-Reply-To: <66EDD72A-9DBC-4876-AD75-038D59BCD0A5@rsa.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_07C3_01CEFFDF.5D250460" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Cc: "mile@ietf.org" , stix-discussion-list Structured Threat Information Expression/ST Subject: Re: [mile] Courses of action COA X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 18:03:48 -0000 ------=_NextPart_000_07C3_01CEFFDF.5D250460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I would think that the course of action would be dependent on the capabilities that the receiving party had. Unless we are talking COA at a very high level like BLOCK, ALERT, IGNORE, etc. As an example what would you send for a COA for a malicious delivery URL? Sending a generic BLOCK COA would be fine. Sending something like BLOCK AT PROXY wouldn't work since not everyone has a proxy. Again, situational dependent. >From a practitioners standpoint EMC wouldn't be sending a COA for any indicators that we generate. Thanks, --Chris -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Stoecker, Paul Sent: Monday, December 23, 2013 10:34 AM To: Jerome Athias Cc: mile@ietf.org; stix-discussion-list Structured Threat Information Expression/ST Subject: Re: [mile] Courses of action COA I am always concerned about things like this where there is a provided means of what to do or what actions to take. What if the course of action is wrong? Or worse what if a nefarious person were to put in a IODEF document where the course of action opened them up for an attack? Is it good to have COA or would it be better to not have a COA and just share the information to detect malicious activity and leave it to the analysts to understand the issue and respond as they see fit? Sent from my iPhone > On Dec 20, 2013, at 3:46 AM, "Jerome Athias" wrote: > > Hi, > > I would like, if I may, try to join efforts on this one. > > https://github.com/STIXProject/schemas/wiki/Proposal:-Add-Parameter_Ob > servables-field-to-CourseOfAction > > Best regards > > 2013/12/20 Roman D. Danyliw : >> Hello! >> >> >> >> Ticket #32 (http://tools.ietf.org/wg/mile/trac/ticket/32) outlines >> the need for a means to specify a predetermined course of action >> (COA) in the Expectation and HistoryItem class. Five implementation >> options were suggested. After review, I would propose adoption of a blend of #4 and #5. >> >> >> >> >> >> ** Add a class named "DefinedCOA" to Expectation and History Item >> >> >> >> +-------------------+ >> >> | Expectation | >> >> +-------------------+ >> >> | ENUM restriction |<>--{0..*}--[ Description ] >> >> | ENUM severity |<>--{0..*}--[ DefinedCOA ] >> >> | ENUM action |<>--{0..1}--[ StartTime ] >> >> | STRING ext-action |<>--{0..1}--[ EndTime ] >> >> | |<>--{0..1}--[ Contact ] >> >> +-------------------+ >> >> >> >> DefinedCOA >> >> Zero or many. ML_STRING. A unique identifier meaningful to the >> sender and recipient of this document that references a course of action. >> This class must be present if the action attribute is set to "defined-coa". >> >> >> >> ** Add an "defined-coa" to @action in Expectation and HistoryItem >> >> >> >> 17. defined-coa. Perform a predefined course of action (COA). The >> COA is named in the DefinedCOA class. >> >> >> >> >> >> Examples of this approach would look like the following: >> >> >> >> [Example 1] >> >> >> >> >> >> Procedure-A >> >> >> >> [Example 2] >> >> >> >> >> >> >> >> Do the following ... >> Procedure-A >> >> >> >> [Example 3] >> >> >> >> >> >> Procedure-A >> >> Procedure-B >> >> >> >> Roman >> >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_000_07C3_01CEFFDF.5D250460 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIY2DCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIEzDCCA7SgAwIBAgIQfwkpTisxI69dQcDR3n6N2TANBgkqhkiG9w0BAQUFADA6 MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkgMjA0OCBW MzAeFw0xMTAzMDMyMDUyMTVaFw0xOTA0MDExNDQ1MzlaMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaLCcEh7lhj dqYo6ryZ8oHK4kJRmQuxfwMa/3PE1Vd4U7U5x15UuSX+qd78hnEdR6yGGxhmY8U2SDG31u+yJD9o OpXFQm6/A4xzItwfcs6SD3Gt6nI/Oa6M0M/7MjPqSc1aUUm2NFiyb6DjotYLDzeAVCqF+4V/Dgc2 QdO1FZeFUCcb5lMqkVAr+O3uAEZEmtD3Cr06YavA38fxeWCiPoheUuWuAQcvOdEnSzJFm6GM8yBJ l9J1cAibE6c4DCl+eHj4M+O/ON2fFVb/lQdS4xO7cSZ9fKGCI7kWr0/7ssSjPsIIGpg0hLRZ35aZ fCK1fFLi9VKvIcTYTrA8Gf9bIGsCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk +v8kLDPQsZ2MMBIGA1UdEwEB/wQIMAYBAf8CAQMwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3 dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0 YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwHQYDVR0OBBYEFHMbOEsly1qOvQLs310p9hB0 DtiYMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUGATB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2Eu cnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExM QzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTAOBgNVHQ8BAf8EBAMCAYYwDQYJ KoZIhvcNAQEFBQADggEBAHGIVCAjCZ+z2vRElolRsLsz4L/js0Zm019rr/+eFks5VnSf5T0HJj7Z tzjtna/+O5b01L8L6Fz64Yui+h/cnxvDwQrhzajbiMiN/JFH+kNOUJ9LcInBkmu45d98h+EQw3Yz XwfnHYaXLArfgeY3CP8AYi0pxXEXf0bH8Prl+P0n4SOUqxh6J0GIz/haW1+usvMscB7lCpJ2loo9 +TmRn3WQrokgr1ILm/3apel6ydpkoFUxEoP5a1806Z7SD9KljN+Vc9o521VkMtnzLlDEkn05by/p QNdlidY7eV7xcpCvuI6qFzyfHdI3G0/Vao0L0os6lEwb5PSa1IysLlHT0uUwggT+MIID5qADAgEC AhBiTV1a7zr4E+gcgJ4lG6TBMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjAeFw0xMTAzMTAyMjQwMDRaFw0xOTAyMjgyMTU2MzNaMIGeMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UE ChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlv bjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDNEVsNPFZOP83bMzCpUDGnf/5IDIQvVRhDHkyrkbv5X1ih4xdTsSdzTDrj LUxIzC7nJswCv+jBaWWm1YoqzBXqQl2/Hl6T5Bt3HBT302GSYamtKcCWve25DoJav+dJd9U/XkCq SSNN7DNVXkJrKC7Zq7OS6/O308pZNkCRJJfMRrodgSx1NoQYZJCfufTOshslVSVhj3Ar274qmuf8 iqM0RR5OMpm7t2dtHzvYJPHR3+HwfQ+s64YBC7NBrBLOYMeq8tzkPKzyITXhwopgbM6gbp+Z8qX5 /lo4Y3OEm7ED51iDqdruRoRnfTQGKdZJT7IYGLH+x0roRKmYKP/2HRNpAgMBAAGjggE7MIIBNzAP BgNVHRMECDAGAQH/AgECMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUHAjB2MC4GCCsGAQUFBwIB FiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNB IFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTBABgNVHR8E OTA3MDWgM6Axhi9odHRwOi8vY3JsLnJzYXNlY3VyaXR5LmNvbS9SU0FDb3Jwb3JhdGVDQXYyLmNy bDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFBQw62v19Em1aFJ1ptu9rlvIrH1MMB8GA1UdIwQY MBaAFHMbOEsly1qOvQLs310p9hB0DtiYMA0GCSqGSIb3DQEBBQUAA4IBAQCPepLT4buLa9p5VwF1 OW2YUwliCqxecs0CxRGJVR4cwvOuMeXxutP+m51n3vzseGkM0d1fmA9JTz8X+5LFdRD12Iw124oj 79QA7NKhO/xoPgbo0QxgnvHS15o94BPvFiZE6QGUjkHs9/hDvU+eIx7OG+Kzxt47vZZef+fJF0+s ZgEDIMXXPXAtJW3xg/JhPrl4z0L7gmjgO+KxV0cyxaDrk6SEW5zZCqAcLehnW7MH8vvlzMsQ6pVr f1g8xMCJonyxow9AwXGyQ0z1866qbJ8t+nQC/sGx3msJVHQg1JyjOWF4PMm8DdeUt+qUrSFRLY4J MroY51gM90nnhtijtleCMIIFxTCCBK2gAwIBAgIRAIQ3oNuoPqBS3YhDUJp3rlQwDQYJKoZIhvcN AQEFBQAwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdC ZWRmb3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJp dHkgT3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MjAeFw0x MzA2MTkxMTAwNThaFw0xNTA2MTkxMTAwNThaMIHvMRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYK CZImiZPyLGQBGRYDZW1jMRgwFgYDVQQKEw9FTUMgQ29ycG9yYXRpb24xETAPBgNVBAsTCEFtZXJp Y2FzMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMQ8wDQYDVQQFEwYxMjI3NjUxFzAVBgoJ kiaJk/IsZAEBEwdoYXJyaWM4MR8wHQYDVQQDExZDaHJpc3RvcGhlciBIYXJyaW5ndG9uMS0wKwYJ KoZIhvcNAQkBFh5jaHJpc3RvcGhlci5oYXJyaW5ndG9uQGVtYy5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIBKcM4e/EfofFwfGGTTzP9Q5h+TbnMfUHaXkYleI6YteMOkHmp+f3 6y9+TztCDzpypIBDHJ61t9jP3Wl1ktHiRvXUyjvciaJuVGNSlhqik/9i94jfWeb0Tw5bjFWgnFyW f4nk51Zu2NvMfCVA3Uu6PS7pf1vWkkDs37XIX3zHeATa189aQRHS8enAItBbC8aE38b+H4Umy2Nm IQQFtXbkB3pzzBImFujgbZdx8PrjRmBaIfXNXIaLDkTc8VmF1MkxSk2Gwt4BeLE5xGMWtTqXv3j8 D7YTk416tj/vIpe+t/cSa7eiydNP74no4GMSRhY4Z6iaX+A+kCTshLze/4w5AgMBAAGjggGpMIIB pTAfBgNVHSMEGDAWgBQUMOtr9fRJtWhSdabbva5byKx9TDCBkQYDVR0gBIGJMIGGMIGDBgkqhkiG 9w0FBwUwdjAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBE BggrBgEFBQcCAjA4MBcWEFJTQSBTZWN1cml0eSBMTEMwAwIBARodQ1BTIEluY29ycG9yYXRlZCBi eSByZWZlcmVuY2UwKQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMEoG A1UdEQRDMEGBHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbaAfBgorBgEEAYI3FAIDoBEM D2hhcnJpYzhAZW1jLmNvbTAOBgNVHQ8BAf8EBAMCB4AwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDov L2NybC5yc2FzZWN1cml0eS5jb206ODAvUlNBQ2xhc3MyUGVyc29uYWxDQXYyLmNybDAdBgNVHQ4E FgQU8PcZ+AZ1SlXp4EE3P4yjbslfqpIwDQYJKoZIhvcNAQEFBQADggEBAL9Or82VcAEw1PGuPbBD QzDy1rwrjFwoN9nMuNaMdqtgNlhhiHldOOlccTiXJVMykbmY3brFqTnvwCA9vMnJJnRqHPfZp5ic waWVpn8H50FHx0o4ftycPEl0oH9RPOJgDc/t/jHpLpLB94kHxyxQ4vJundplDbR2LYsUZa03GBMo hvfMuiKw0CeBr1R7x4WIiseWQ4KB71zmW3AbsYI9y0q9DlHIgtNmfOj84tY9f2QC3ndMkmSGvmMm X7DWCMnlHPN+0FiRkMqOeoYFwRaTeRM1i2Sm91E83TNRmb7f6xzIc4mLsHKP2Jui5nA/V8NWvTqI YhCkCB0cZkc91ehe4n4wggXUMIIEvKADAgECAhAzkGSOsA6fNPJDSK+W/N5kMA0GCSqGSIb3DQEB BQUAMIGeMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVk Zm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5 IE9yZ2FuaXphdGlvbjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwHhcNMTMw NjE5MTUwNDQ1WhcNMTUwNjE5MTUwNDIxWjCB8zETMBEGCgmSJomT8ixkARkWA2NvbTETMBEGCgmS JomT8ixkARkWA2VtYzEYMBYGA1UEChMPRU1DIENvcnBvcmF0aW9uMREwDwYDVQQLEwhBbWVyaWNh czEcMBoGA1UECxMTSW5mb3JtYXRpb24gU3lzdGVtczEPMA0GA1UEBRMGMTIyNzY1MRcwFQYKCZIm iZPyLGQBARMHaGFycmljODEjMCEGA1UEAxMaQ2hyaXN0b3BoZXIgSGFycmluZ3Rvbi1FbmMxLTAr BgkqhkiG9w0BCQEWHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBALkuHI2WDll/BOd40HVywnDJpkxwxGs0Hpqxmikq298tLVn4QxLr LhdIFtW+8Ish3Cfat2810FCTAbmh855JYkAJlj2zMx5s4hri45l4cRpRVeWxdH0o5X278NS2ZXU2 DDJAa3Dx46gTz9/xRE4EAoHtMhr5Vr9rDOqkfCmAZmd1kOeQF3W1SmUgaPxEIHp27s0Sso5khGdc 2/2GyEmos4dJ86PaaZbpf9lcZwC5LVfcpa9ZOXh6bqd7U8hDznZ5PRJB6k+CAFBrt+WiYvsYG7is IYIPXrCkUVuRYkXupXqXqu5OEs3ANeAG+ehJxn6Ww+mZeYJfOSAWLARLWsI5ZGsCAwEAAaOCAbUw ggGxMDUGA1UdJQQuMCwGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoD BDAfBgNVHSMEGDAWgBQUMOtr9fRJtWhSdabbva5byKx9TDCBkQYDVR0gBIGJMIGGMIGDBgkqhkiG 9w0FBwUwdjAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBE BggrBgEFBQcCAjA4MBcWEFJTQSBTZWN1cml0eSBMTEMwAwIBARodQ1BTIEluY29ycG9yYXRlZCBi eSByZWZlcmVuY2UwSgYDVR0RBEMwQYEeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29toB8G CisGAQQBgjcUAgOgEQwPaGFycmljOEBlbWMuY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9j cmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNvbmFsQ0F2Mi5jcmwwHQYDVR0OBBYE FFp5a07UDPJYJvedFEuB1U2ACAW1MA4GA1UdDwEB/wQEAwIDODANBgkqhkiG9w0BAQUFAAOCAQEA PaMUkDlrJh/pKXE9hwn4NJny1feBdfjqRUlziiKo3/+Jwn3YToU+nh+uic4anPiw+Iv1N1apK5mW aPCu36xFhgtVBnbSJQ0c+Aeal1HxRttlJp2AtQ8WBYN2eJ7NkEHajhTU+49GL6woFU9cKS+GI9cp QU6H2E/eYe628ngK/sTqfUF2HZalvwLcQZAr7RkrLcOYt8PsXFZmijVGZC76wI4xRfo4o9Of1epL jZ0FmhRy3sfnLuEmDBuOOnlQSkyBUinHcv0g0QhZ8WOvhocAvobbYXk67ADjRF2MV/J6jHq+lQVG p5/DLic0VM0W/gRcpZmZu5DYeK/TJD8ohGaq1zGCBHswggR3AgEBMIG0MIGeMQswCQYDVQQGEwJV UzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEG A1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjICEQCEN6DbqD6gUt2IQ1Cad65UMAkGBSsO AwIaBQCgggKbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTIy MzE4MDMyNFowIwYJKoZIhvcNAQkEMRYEFEO/XN0F36YHj9WhEADHScHaXxT0MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHEBgkrBgEE AYI3EAQxgbYwgbMwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYD VQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwg U2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2 MgIQM5BkjrAOnzTyQ0ivlvzeZDCBxgYLKoZIhvcNAQkQAgsxgbaggbMwgZ4xCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0Eg U2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYD VQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MgIQM5BkjrAOnzTyQ0ivlvzeZDANBgkqhkiG 9w0BAQEFAASCAQAilOA7x+/+ThbH/88wz0qewuRXsajH8smkMryuuvbDBZC32LnShgn7nnePKpQO mkJOFXB+vQi/ncF8JFiw2YgFpzaweb756nSfkWNSR+os6JAggL2HKCiT4mwQIGccqK1QXl6ZHezX GKC7Gn2Bf+J5DkwdKcD7CmFpcYSojJ76JpCCqcdOa8Nnjuaj/meIYArqQQmSNLgf94Yy+audhug7 8KM2UhDL0rsFB4/hzd/SEKcZHplauSZF4woC4NdzuJ8Lw03u5b3691RHIlNKTApZi8lWCixPBaJQ VndrvKlvrl5LDvjHA7fXkvhf+ZDkKGQRv1v2DoNICPicSv1O9a5pAAAAAAAA ------=_NextPart_000_07C3_01CEFFDF.5D250460--