From pkampana@cisco.com Tue Jan 8 08:06:01 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811B021F8976 for ; Tue, 8 Jan 2013 08:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrnbZtLj3B8h for ; Tue, 8 Jan 2013 08:06:00 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9E52421F8971 for ; Tue, 8 Jan 2013 08:06:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2122; q=dns/txt; s=iport; t=1357661160; x=1358870760; h=from:to:subject:date:message-id:mime-version; bh=GB0ifaZKbA3/jorlFM1jhgLZepRKwq2mkMesjkUxUYc=; b=cnHbRXBKIGC15C3GlorbsSiW9mmzKu4BTsng5HfTW8sKDOCJPx+Puezx 1WQLT3ypQyglVYhhB2HlOdR+WipCLclFpErA6SVZ8+7Q1qxjyGq/v6OmV VeyGpYNCAxq+abSPbNqa6Mx1plUHC5zmwx/Sg93y5BbLXLnykwpCLBYHM Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALVC7FCtJV2b/2dsb2JhbABEgki7EhZzgiABBC1eAQwBHVYmAQQbDIgDmDmREY0bkDRhA6ZVgnSCJg X-IronPort-AV: E=Sophos;i="4.84,432,1355097600"; d="scan'208,217";a="160095868" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 08 Jan 2013 16:06:00 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r08G60Gh018327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 8 Jan 2013 16:06:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.229]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 10:05:59 -0600 From: "Panos Kampanakis (pkampana)" To: "mile@ietf.org" Thread-Topic: Question for malware file exchange using SCI draft Thread-Index: Ac3tubkX8RCJhpTiT+iimvYSUJTSbA== Date: Tue, 8 Jan 2013 16:05:58 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A751584C8@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.127] Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A751584C8xmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: [mile] Question for malware file exchange using SCI draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jan 2013 16:06:01 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A751584C8xmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Take et al, We were wondering what the community thinks is the best way to exchange mal= ware in an IODEF document. To me it seems either EventReport or AttackPatt= ern classes are adequate. Now, how will the malware file be exchanged is another question. I wanted t= o see if it is possible to add IEEE's MMDEF in one of SCI's "Candidate Spe= cifications for the IANA Table". MMDEF would be for the exchange of malware= files in a secure way. FYI, I believe MMDEF is used as that is posted righ= t on the IEEE site by APWG with IODEF Rgs, Panos --_000_1C9F17D1873AFA47A969C4DD98F98A751584C8xmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Take et al,
 
We were wondering what the community thinks is the best way to exchang= e malware in an IODEF document. To me it seems either EventReport or Attac= kPattern classes are adequate.
 
Now, how will the malware file be exchanged is another question. I wan= ted to see if it is possible to add IEEE’s MMDEF in one of SCI’= s “Candidate Specifications for the IANA Table”. MMDEF would b= e for the exchange of malware files in a secure way. FYI, I believe MMDEF is used as that is posted right on the IEEE site by APWG wi= th IODEF
 
Rgs,
Panos
 
 
 --_000_1C9F17D1873AFA47A969C4DD98F98A751584C8xmbrcdx10ciscocom_-- From kathleen.moriarty@emc.com Tue Jan 8 09:34:21 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B028321F8606 for ; Tue, 8 Jan 2013 09:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XymvZ-r344Lx for ; Tue, 8 Jan 2013 09:34:19 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id C7A7B21F86DC for ; Tue, 8 Jan 2013 09:34:18 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r08HY6UP008986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jan 2013 12:34:10 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 8 Jan 2013 12:33:59 -0500 Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r08HXkHT019464; Tue, 8 Jan 2013 12:33:52 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub28.corp.emc.com ([10.254.110.184]) with mapi; Tue, 8 Jan 2013 12:33:49 -0500 From: "Moriarty, Kathleen" To: "Panos Kampanakis (pkampana)" , "mile@ietf.org" Date: Tue, 8 Jan 2013 12:33:47 -0500 Thread-Topic: Question for malware file exchange using SCI draft Thread-Index: Ac3tubkX8RCJhpTiT+iimvYSUJTSbAACRuhA Message-ID: References: <1C9F17D1873AFA47A969C4DD98F98A751584C8@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A751584C8@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24CE4BE501MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Question for malware file exchange using SCI draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jan 2013 17:34:21 -0000 --_000_F5063677821E3B4F81ACFB7905573F24CE4BE501MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Panos, Take, et al, Interesting... getting opinions from the list will be very helpful! I think if the group goes this route, we should pick which of those two cla= sses make the most sense to embed MMDEF in IODEF using the SCI draft. If f= olks think this is the best way to include a malware sample (please post op= inions!), it should be possible to put this directly in the SCI draft as th= e first entry for the selected class in the IANA table. More complex repre= sentations for malware could come in the IANA table method later if needed.= The other way to include a file with malware is described in RFC5901, but= if APWG has taken this path, it may be the better option. Copying Pat. I= f it is, we'll want to include this in the IODEF guidance document as well = for use cases that require the exchange of malware. As for which class it belongs in, there are some considerations folks may w= ant to weigh in on (and there may be more I don't list): EventReport is in the Record class of IODEF. Definition from IODEF Record Class: The Record class is a container class = for log and audit data that provides supportive information about the incident. The source of this data will often be the output of monitoring tools. These logs should substantiate the activity described in the document. Definition of EventReport Class from SCI: The extension embeds structured = event reports. AttackPattern is contained in the Method class of IODEF. Definition from IODEF of Method Class: The Method class describes the metho= dology used by the intruder to perpetrate the events of the incident. This class consists of a list of references describing the attack method and a free form description of the technique. Attack pattern Definition from SCI: The extension describes attack patterns= of incidents or events. We can certainly change definitions of the classes in IODEF if that is the = right thing to do as well. Or do folks think one of these is a better fit = than the other? This seems like a solid use case of data commonly exchanged with a possible= schema to reference in a standards organization, so maybe this is a candid= ate for our MTI for the SCI draft? MMDEF is not a formal standard though = because of where it sits in IEEE, but it is a site that can be referenced a= nd the schema is posted publicly. Thanks! Kathleen From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Pan= os Kampanakis (pkampana) Sent: Tuesday, January 08, 2013 11:06 AM To: mile@ietf.org Subject: [mile] Question for malware file exchange using SCI draft Hi Take et al, We were wondering what the community thinks is the best way to exchange mal= ware in an IODEF document. To me it seems either EventReport or AttackPatte= rn classes are adequate. Now, how will the malware file be exchanged is another question. I wanted t= o see if it is possible to add IEEE's MMDEF in one of SCI's "Candidate Spec= ifications for the IANA Table". MMDEF would be for the exchange of malware = files in a secure way. FYI, I believe MMDEF is used as that is posted right= on the IEEE site by APWG with IODEF Rgs, Panos --_000_F5063677821E3B4F81ACFB7905573F24CE4BE501MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Panos,= Take, et al,

 <= /o:p>

Interesting… getting opin= ions from the list will be very helpful!

 

I th= ink if the group goes this route, we should pick which of those two classes= make the most sense to embed MMDEF in IODEF using the SCI draft.  If = folks think this is the best way to include a malware sample (please post o= pinions!), it should be possible to put this directly in the SCI draft as t= he first entry for the selected class in the IANA table.  More complex= representations for malware could come in the IANA table method later if n= eeded.  The other way to include a file with malware is described in R= FC5901, but if APWG has taken this path, it may be the better option. = Copying Pat.  If it is, we’ll want to include this in the IODEF= guidance document as well for use cases that require the exchange of malwa= re.

 

As for which class it belongs in, there a= re some considerations folks may want to weigh in on (and there may be more= I don’t list):

 

EventReport is in the R= ecord class of IODEF.

Definition from IODE=
F Record Class:  The Record class is a container class for log =
and audit data that
   provides supportive i=
nformation about the incident.  The source of
&nb=
sp;  this data will often be the output of monitoring tools.  The=
se logs
   should substantiate the activity =
described in the document.
Definition of EventR=
eport Class from SCI:  The extension embeds structured event re=
ports.

 =

AttackPattern is contained in the Method cl= ass of IODEF.

Definition from IODEF of Met=
hod Class: The Method class describes the methodology used by the in=
truder to

   perpetrate the events of the in= cident.  This class consists of a list

&nb= sp;  of references describing the attack method and a free form

   description of the technique.

Attack pattern Definition from SCI: The extensi=
on describes attack patterns of incidents or events.

<= o:p> 

 

We can certainly change definitions of = the classes in IODEF if that is the right thing to do as well.  Or do = folks think one of these is a better fit than the other?<= /p>

 

This seems like a solid use case of data commonly exchanged wit= h a possible schema to reference in a standards organization, so maybe this= is a candidate for our MTI for the SCI draft?   MMDEF is not a f= ormal standard though because of where it sits in IEEE, but it is a site th= at can be referenced and the schema is posted publicly.

 

Thanks!

Kathlee= n

 =

From: mile-bounces@ietf.org [mailto:mi= le-bounces@ietf.org] On Behalf Of Panos Kampanakis (pkampana)
= Sent: Tuesday, January 08, 2013 11:06 AM
To: mile@ietf.orgSubject: [mile] Question for malware file exchange using SCI draft<= o:p>

 

=

Hi Take et al,

 

We were wonderin= g what the community thinks is the best way to exchange malware in an IODEF= document. To me it seems either EventReport or AttackPattern classes are a= dequate.

 <= /span>

Now, how will the malware file be exchan= ged is another question. I wanted to see if it is possible to add IEEE̵= 7;s MMDEF in one of SCI’s “Candidate Specifications for the IAN= A Table”. MMDEF would be for the exchange of malware files in a secur= e way. FYI, I believe MMDEF is used as that is posted right on the IEEE sit= e by APWG with IODEF

=  <= o:p>

Rgs,

Panos

&= nbsp;

 

= --_000_F5063677821E3B4F81ACFB7905573F24CE4BE501MX15Acorpemccom_-- From takeshi_takahashi@nict.go.jp Wed Jan 9 00:22:09 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7790621F841F for ; Wed, 9 Jan 2013 00:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6JbbOCKwTfA for ; Wed, 9 Jan 2013 00:22:07 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6DD21F84C6 for ; Wed, 9 Jan 2013 00:22:04 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id r098LvBo013902; Wed, 9 Jan 2013 17:21:57 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id r098LusA023940; Wed, 9 Jan 2013 17:21:56 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id r098Lu5j023937; Wed, 9 Jan 2013 17:21:56 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 7B3FC16A53; Wed, 9 Jan 2013 17:21:41 +0900 (JST) Received: from takeVAIO2 (unknown [133.243.119.6]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 72C7619B6; Wed, 9 Jan 2013 17:21:41 +0900 (JST) From: "Takeshi Takahashi" To: "'Moriarty, Kathleen'" , "'Panos Kampanakis \(pkampana\)'" , References: <1C9F17D1873AFA47A969C4DD98F98A751584C8@xmb-rcd-x10.cisco.com> In-Reply-To: Date: Wed, 9 Jan 2013 17:21:28 +0900 Message-ID: <006701cdee42$58bfa7e0$0a3ef7a0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQICDJN2nlZ3wj4VNjqPXjGFEH9KqALBAmTwl8JL6/A= Content-Language: ja Subject: Re: [mile] Question for malware file exchange using SCI draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jan 2013 08:22:09 -0000 Hi Panos, Kathleen, and all, Thank you very much for raising discussion. Let me join the discussion here. > We were wondering what the community thinks is the best way to = exchange malware in an IODEF document. To me it seems either EventReport or AttackPattern classes are adequate. > Now, how will the malware file be exchanged is another question. I = wanted to see if it is possible to add IEEE=92s MMDEF in one of SCI=92s = =93Candidate Specifications for the IANA Table=94. MMDEF would be for the exchange of malware files in a secure way. FYI, I believe MMDEF is used as that is posted right on the IEEE site by APWG with IODEF I personally think it would be very nice to register MMDEF in the SCI's = IANA Table. IMHO, I slightly prefer the AttackPattern class since the MMDEF contains = the samples (malware files) that tried to attack the user's asset. Does the MMDEF metadata XML itself contain actual file data or URI (or = any other pointer)? I think no. (correct me please if I am wrong.) If so, I guess we could convey the MMDEF data by setting values as = follows: SpecID <- namespace of MMDEF ver x.x RawData <- the XML metadata Reference <- pointer to the sample (malware file) I might have wrong understanding of MMDEF. So, please correct me if above is not suitable... > Attack pattern Definition from SCI: The extension describes attack patterns of incidents or events. I think the definitions of the IODEF classes are fine, but the above SCI class definition could be modified to nicely support MMDEF here. For instance, it could be rewritten like this: "The extension describes attack patterns of incidents or events as well as their tools such as malware." Meanwhile, the SCI draft should note that the validation (and parsing) process should be careful if we actually carry a sample (of malware) = instead of its pointer. Kind regards, Take From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Wednesday, January 09, 2013 2:34 AM To: Panos Kampanakis (pkampana); mile@ietf.org Subject: Re: [mile] Question for malware file exchange using SCI draft Hi Panos, Take, et al, Interesting=85 getting opinions from the list will be very helpful! I think if the group goes this route, we should pick which of those two classes make the most sense to embed MMDEF in IODEF using the SCI = draft.=A0 If folks think this is the best way to include a malware sample (please = post opinions!), it should be possible to put this directly in the SCI draft = as the first entry for the selected class in the IANA table.=A0 More = complex representations for malware could come in the IANA table method later if needed.=A0 The other way to include a file with malware is described in RFC5901, but if APWG has taken this path, it may be the better = option.=A0 Copying Pat.=A0 If it is, we=92ll want to include this in the IODEF = guidance document as well for use cases that require the exchange of malware. As for which class it belongs in, there are some considerations folks = may want to weigh in on (and there may be more I don=92t list): EventReport is in the Record class of IODEF. Definition from IODEF Record Class:=A0 The Record class is a container = class for log and audit data that =A0=A0 provides supportive information about the incident.=A0 The source = of =A0=A0 this data will often be the output of monitoring tools.=A0 These = logs =A0=A0 should substantiate the activity described in the document. Definition of EventReport Class from SCI:=A0 The extension embeds = structured event reports. AttackPattern is contained in the Method class of IODEF. Definition from IODEF of Method Class: The Method class describes the methodology used by the intruder to =A0=A0 perpetrate the events of the incident.=A0 This class consists of = a list =A0=A0 of references describing the attack method and a free form =A0=A0 description of the technique. Attack pattern Definition from SCI: The extension describes attack = patterns of incidents or events. We can certainly change definitions of the classes in IODEF if that is = the right thing to do as well.=A0 Or do folks think one of these is a better = fit than the other? This seems like a solid use case of data commonly exchanged with a = possible schema to reference in a standards organization, so maybe this is a candidate for our MTI for the SCI draft?=A0 =A0MMDEF is not a formal = standard though because of where it sits in IEEE, but it is a site that can be referenced and the schema is posted publicly. Thanks! Kathleen From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Panos Kampanakis (pkampana) Sent: Tuesday, January 08, 2013 11:06 AM To: mile@ietf.org Subject: [mile] Question for malware file exchange using SCI draft Hi Take et al, =A0 We were wondering what the community thinks is the best way to exchange malware in an IODEF document. To me it seems either EventReport or AttackPattern classes are adequate.=20 =A0 Now, how will the malware file be exchanged is another question. I = wanted to see if it is possible to add IEEE=92s MMDEF in one of SCI=92s = =93Candidate Specifications for the IANA Table=94. MMDEF would be for the exchange of malware files in a secure way. FYI, I believe MMDEF is used as that is posted right on the IEEE site by APWG with IODEF=20 =A0 Rgs, Panos =A0 =A0 From Kent_Landfield@mcafee.com Wed Jan 9 12:04:01 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B813511E809B for ; Wed, 9 Jan 2013 12:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TI94D61FTnxX for ; Wed, 9 Jan 2013 12:04:00 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 2050721F88B1 for ; Wed, 9 Jan 2013 12:04:00 -0800 (PST) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 6336_6d98_52f9a480_e187_4751_8ef0_f12ba5c1dfc3; Wed, 09 Jan 2013 14:03:45 -0600 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.159]) by MIVEXAMER1N2.corp.nai.org ([169.254.3.39]) with mapi id 14.02.0318.001; Wed, 9 Jan 2013 15:02:42 -0500 From: To: , , , Thread-Topic: [mile] Question for malware file exchange using SCI draft Thread-Index: Ac3tubkX8RCJhpTiT+iimvYSUJTSbAACRuhAACpZnAAAC+pEAA== Date: Wed, 9 Jan 2013 20:02:42 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF0D043C@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <006701cdee42$58bfa7e0$0a3ef7a0$@nict.go.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.48.48.242] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF0D043CMIVEXAMER1N1corpn_" MIME-Version: 1.0 Subject: Re: [mile] Question for malware file exchange using SCI draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jan 2013 20:04:01 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF0D043CMIVEXAMER1N1corpn_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Take, I too prefer the Attack Pattern class for the same reason you stated. Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Takeshi Takahashi > Date: Wednesday, January 9, 2013 2:21 AM To: Kathleen Moriarty >, "'Panos Kampanakis (pkampana)'" >, "mile@ietf.org" > Subject: Re: [mile] Question for malware file exchange using SCI draft Hi Panos, Kathleen, and all, Thank you very much for raising discussion. Let me join the discussion here. We were wondering what the community thinks is the best way to exchange malware in an IODEF document. To me it seems either EventReport or AttackPattern classes are adequate. Now, how will the malware file be exchanged is another question. I wanted to see if it is possible to add IEEE=92s MMDEF in one of SCI=92s =93Candida= te Specifications for the IANA Table=94. MMDEF would be for the exchange of malware files in a secure way. FYI, I believe MMDEF is used as that is posted right on the IEEE site by APWG with IODEF I personally think it would be very nice to register MMDEF in the SCI's IAN= A Table. IMHO, I slightly prefer the AttackPattern class since the MMDEF contains th= e samples (malware files) that tried to attack the user's asset. Does the MMDEF metadata XML itself contain actual file data or URI (or any other pointer)? I think no. (correct me please if I am wrong.) If so, I guess we could convey the MMDEF data by setting values as follows: SpecID <- namespace of MMDEF ver x.x RawData <- the XML metadata Reference <- pointer to the sample (malware file) I might have wrong understanding of MMDEF. So, please correct me if above is not suitable... Attack pattern Definition from SCI: The extension describes attack patterns of incidents or events. I think the definitions of the IODEF classes are fine, but the above SCI class definition could be modified to nicely support MMDEF here. For instance, it could be rewritten like this: "The extension describes attack patterns of incidents or events as well as their tools such as malware." Meanwhile, the SCI draft should note that the validation (and parsing) process should be careful if we actually carry a sample (of malware) instea= d of its pointer. Kind regards, Take From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Wednesday, January 09, 2013 2:34 AM To: Panos Kampanakis (pkampana); mile@ietf.org Subject: Re: [mile] Question for malware file exchange using SCI draft Hi Panos, Take, et al, Interesting=85 getting opinions from the list will be very helpful! I think if the group goes this route, we should pick which of those two classes make the most sense to embed MMDEF in IODEF using the SCI draft. I= f folks think this is the best way to include a malware sample (please post opinions!), it should be possible to put this directly in the SCI draft as the first entry for the selected class in the IANA table. More complex representations for malware could come in the IANA table method later if needed. The other way to include a file with malware is described in RFC5901, but if APWG has taken this path, it may be the better option. Copying Pat. If it is, we=92ll want to include this in the IODEF guidance document as well for use cases that require the exchange of malware. As for which class it belongs in, there are some considerations folks may want to weigh in on (and there may be more I don=92t list): EventReport is in the Record class of IODEF. Definition from IODEF Record Class: The Record class is a container class for log and audit data that provides supportive information about the incident. The source of this data will often be the output of monitoring tools. These logs should substantiate the activity described in the document. Definition of EventReport Class from SCI: The extension embeds structured event reports. AttackPattern is contained in the Method class of IODEF. Definition from IODEF of Method Class: The Method class describes the methodology used by the intruder to perpetrate the events of the incident. This class consists of a list of references describing the attack method and a free form description of the technique. Attack pattern Definition from SCI: The extension describes attack patterns of incidents or events. We can certainly change definitions of the classes in IODEF if that is the right thing to do as well. Or do folks think one of these is a better fit than the other? This seems like a solid use case of data commonly exchanged with a possible schema to reference in a standards organization, so maybe this is a candidate for our MTI for the SCI draft? MMDEF is not a formal standard though because of where it sits in IEEE, but it is a site that can be referenced and the schema is posted publicly. Thanks! Kathleen From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Panos Kampanakis (pkampana) Sent: Tuesday, January 08, 2013 11:06 AM To: mile@ietf.org Subject: [mile] Question for malware file exchange using SCI draft Hi Take et al, We were wondering what the community thinks is the best way to exchange malware in an IODEF document. To me it seems either EventReport or AttackPattern classes are adequate. Now, how will the malware file be exchanged is another question. I wanted t= o see if it is possible to add IEEE=92s MMDEF in one of SCI=92s =93Candidate Specifications for the IANA Table=94. MMDEF would be for the exchange of malware files in a secure way. FYI, I believe MMDEF is used as that is posted right on the IEEE site by APWG with IODEF Rgs, Panos _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --_000_3CBA099FBA0AB843895D72474092B8CF0D043CMIVEXAMER1N1corpn_ Content-Type: text/html; charset="Windows-1252" Content-ID: <65047D4349EA314CA94B0468F213156A@McAfee.com> Content-Transfer-Encoding: quoted-printable
Take,

I too prefer the Attack Pattern class for the same reason you stated.<= /div>

Thanks.

Kent Landfield

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

From: Takeshi Takahashi <takeshi_takahashi@nict.go.jp&g= t;
Date: Wednesday, January 9, 2013 2:= 21 AM
To: Kathleen Moriarty <kathleen.moriarty@emc.com>, &q= uot;'Panos Kampanakis (pkampana)'" <pkampana@cisco.com>, "m= ile@ietf.org" <mile@ietf.org>
Subject: Re: [mile] Question for ma= lware file exchange using SCI draft

Hi Panos, Kathleen, and all,

Thank you very much for raising discussion.
Let me join the discussion here.

We were wondering what the community thinks is the best way to exchang= e
malware in an IODEF document. To me it seems either EventReport or
AttackPattern classes are adequate.
Now, how will the malware file be exchanged is another question. I wan= ted
to see if it is possible to add IEEE=92s MMDEF in one of SCI=92s =93Ca= ndidate
Specifications for the IANA Table=94. MMDEF would be for the exchange = of
malware files in a secure way. FYI, I believe MMDEF is used as that is=
posted right on the IEEE site by APWG with IODEF

I personally think it would be very nice to register MMDEF in the SCI'= s IANA
Table.
IMHO, I slightly prefer the AttackPattern class since the MMDEF contai= ns the
samples (malware files) that tried to attack the user's asset.

Does the MMDEF metadata XML itself contain actual file data or URI (or= any
other pointer)?
I think no. (correct me please if I am wrong.)
If so, I guess we could convey the MMDEF data by setting values as fol= lows:

SpecID <- namespace of MMDEF ver x.x
RawData <- the XML metadata
Reference <- pointer to the sample (malware file)

I might have wrong understanding of MMDEF.
So, please correct me if above is not suitable...

Attack pattern Definition from SCI: The extension describes attack
patterns of incidents or events.

I think the definitions of the IODEF classes are fine, but the above S= CI
class definition could be modified to nicely support MMDEF here.
For instance, it could be rewritten like this: "The extension des= cribes
attack patterns of incidents or events as well as their tools such as<= /div>
malware."

Meanwhile, the SCI draft should note that the validation (and parsing)=
process should be careful if we actually carry a sample (of malware) i= nstead
of its pointer.

Kind regards,
Take




Moriarty, Kathleen
Sent: Wednesday, January 09, 2013 2:34 AM
Subject: Re: [mile] Question for malware file exchange using SCI draft=

Hi Panos, Take, et al,

Interesting=85 getting opinions from the list will be very helpful!

I think if the group goes this route, we should pick which of those tw= o
classes make the most sense to embed MMDEF in IODEF using the SCI draf= t.  If
folks think this is the best way to include a malware sample (please p= ost
opinions!), it should be possible to put this directly in the SCI draf= t as
the first entry for the selected class in the IANA table.  More c= omplex
representations for malware could come in the IANA table method later = if
needed.  The other way to include a file with malware is describe= d in
RFC5901, but if APWG has taken this path, it may be the better option.=  
Copying Pat.  If it is, we=92ll want to include this in the IODEF= guidance
document as well for use cases that require the exchange of malware.

As for which class it belongs in, there are some considerations folks = may
want to weigh in on (and there may be more I don=92t list):

EventReport is in the Record class of IODEF.
Definition from IODEF Record Class:  The Record class is a contai= ner class
for log and audit data that
   provides supportive information about the incident. = The source of
   this data will often be the output of monitoring tools.&n= bsp; These logs
   should substantiate the activity described in the documen= t.
Definition of EventReport Class from SCI:  The extension embeds s= tructured
event reports.

AttackPattern is contained in the Method class of IODEF.
Definition from IODEF of Method Class: The Method class describes the<= /div>
methodology used by the intruder to
   perpetrate the events of the incident.  This class c= onsists of a list
   of references describing the attack method and a free for= m
   description of the technique.
Attack pattern Definition from SCI: The extension describes attack pat= terns
of incidents or events.


We can certainly change definitions of the classes in IODEF if that is= the
right thing to do as well.  Or do folks think one of these is a b= etter fit
than the other?

This seems like a solid use case of data commonly exchanged with a pos= sible
schema to reference in a standards organization, so maybe this is a
candidate for our MTI for the SCI draft?   MMDEF is not a fo= rmal standard
though because of where it sits in IEEE, but it is a site that can be<= /div>
referenced and the schema is posted publicly.

Thanks!
Kathleen

Panos Kampanakis (pkampana)
Sent: Tuesday, January 08, 2013 11:06 AM
Subject: [mile] Question for malware file exchange using SCI draft

Hi Take et al,
 
We were wondering what the community thinks is the best way to exchang= e
malware in an IODEF document. To me it seems either EventReport or
AttackPattern classes are adequate.
 
Now, how will the malware file be exchanged is another question. I wan= ted to
see if it is possible to add IEEE=92s MMDEF in one of SCI=92s =93Candi= date
Specifications for the IANA Table=94. MMDEF would be for the exchange = of
malware files in a secure way. FYI, I believe MMDEF is used as that is=
posted right on the IEEE site by APWG with IODEF
 
Rgs,
Panos
 
 

_______________________________________________
mile mailing list

 --_000_3CBA099FBA0AB843895D72474092B8CF0D043CMIVEXAMER1N1corpn_-- From kathleen.moriarty@emc.com Wed Jan 9 14:08:59 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F5F21F8456 for ; Wed, 9 Jan 2013 14:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBs2q+5Crk1F for ; Wed, 9 Jan 2013 14:08:57 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7565921F843C for ; Wed, 9 Jan 2013 14:08:57 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r09M8sgJ027435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Jan 2013 17:08:54 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Wed, 9 Jan 2013 17:08:38 -0500 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r09M8cIT012110 for ; Wed, 9 Jan 2013 17:08:38 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Wed, 9 Jan 2013 17:08:38 -0500 From: "Moriarty, Kathleen" To: "mile@ietf.org" Date: Wed, 9 Jan 2013 17:08:37 -0500 Thread-Topic: IOCs Thread-Index: Ac3utd/mNv5jaYOQQ6aUKAx2ebt57w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24CE4BE73EMX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jan 2013 22:08:59 -0000 --_000_F5063677821E3B4F81ACFB7905573F24CE4BE73EMX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Take, et. al, In looking at SCI, I am not sure where you might include indicators of comp= romise that are not included in the base IODEF schema and would like to kno= w what others think. To me, the logical place would be directly in the EventData class using the= AdditionalData extension class, maybe using another SCI extension class ca= lled Detection. Is there a place where these would fit already that I am missing or do we n= eed another container? Thank you! Kathleen --_000_F5063677821E3B4F81ACFB7905573F24CE4BE73EMX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Take, et. al,
 
In looking at SCI, I am not sure where you might include indicators of= compromise that are not included in the base IODEF schema and would like t= o know what others think.
 
To me, the logical place would be directly in the EventData class usin= g the AdditionalData extension class, maybe using another SCI extension cla= ss called Detection.
 
Is there a place where these would fit already that I am missing or do= we need another container?
 
Thank you!
Kathleen
 
 --_000_F5063677821E3B4F81ACFB7905573F24CE4BE73EMX15Acorpemccom_-- From takeshi_takahashi@nict.go.jp Fri Jan 11 00:50:23 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4B121F8788 for ; Fri, 11 Jan 2013 00:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejH7gid82N89 for ; Fri, 11 Jan 2013 00:50:22 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FAA21F8786 for ; Fri, 11 Jan 2013 00:50:21 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id r0B8oG1M009898; Fri, 11 Jan 2013 17:50:16 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id r0B8oG5u021314; Fri, 11 Jan 2013 17:50:16 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id r0B8oGs0021311; Fri, 11 Jan 2013 17:50:16 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 0DC7D165F3; Fri, 11 Jan 2013 17:50:16 +0900 (JST) Received: from takeVAIO2 (unknown [133.243.119.6]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 088341D28; Fri, 11 Jan 2013 17:50:16 +0900 (JST) From: "Takeshi Takahashi" To: "'Moriarty, Kathleen'" , References: In-Reply-To: Date: Fri, 11 Jan 2013 17:50:12 +0900 Message-ID: <012901cdefd8$aadf0790$009d16b0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEDdMJpat77Go03FnWbR/JpffItGJnYvIGw Content-Language: ja Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jan 2013 08:50:23 -0000 Hi Kathleen and all, Thank you very much for the comments. I agree that we should consider indicators of compromise that are not included in the base IODEF schema. At the same time, perhaps we could clarify what would be these = indicators... If the indicators are something like an XML-based alert/warning of information leakage, it could be an event that are conveyed in the SCI's EventReport class, IMHO. If the indicators are something like an non-XML ones, I guess it could = be conveyed without using SCI draft. For instance, we could use Impact class of the base IODEF to convey the indicators. We could for instance extend the list of indicators of the Impact class, = if needed. If the indicators are something like the result of penetration test, or indicators of exposed vulnerabilities, I guess neither SCI classes nor = basic IODEF classes have right place to fit them in at this moment. Could we elaborate what would be these indicators? I hope I am not missing the point. Kind regards, Take From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Thursday, January 10, 2013 7:09 AM To: mile@ietf.org Subject: [mile] IOCs Hi Take, et. al, =A0 In looking at SCI, I am not sure where you might include indicators of compromise that are not included in the base IODEF schema and would like = to know what others think. =A0 To me, the logical place would be directly in the EventData class using = the AdditionalData extension class, maybe using another SCI extension class called Detection. =A0 Is there a place where these would fit already that I am missing or do = we need another container? =A0 Thank you! Kathleen =A0 From kathleen.moriarty@emc.com Fri Jan 11 13:54:19 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA6921F8A52 for ; Fri, 11 Jan 2013 13:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWGSKHJ2DeMQ for ; Fri, 11 Jan 2013 13:54:16 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0B74421F86C9 for ; Fri, 11 Jan 2013 13:54:15 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0BLs8wM012997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jan 2013 16:54:10 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 11 Jan 2013 16:53:55 -0500 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0BLrpAf024581; Fri, 11 Jan 2013 16:53:53 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Fri, 11 Jan 2013 16:53:51 -0500 From: "Moriarty, Kathleen" To: Takeshi Takahashi , "mile@ietf.org" Date: Fri, 11 Jan 2013 16:53:50 -0500 Thread-Topic: [mile] IOCs Thread-Index: AQEDdMJpat77Go03FnWbR/JpffItGJnYvIGwgAC0OCA= Message-ID: References: <012901cdefd8$aadf0790$009d16b0$@nict.go.jp> In-Reply-To: <012901cdefd8$aadf0790$009d16b0$@nict.go.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jan 2013 21:54:19 -0000 Hi Take, Thank you for diving into this a bit more. If you look at the base IODEF schema, we have a few issues that the working= group discussed back in July (leading up to the July IETF) in Rosella's wo= rk. For some of the indicators that are not covered, many of us thought it= would make sense to put those directly into the updated version of IODEF. = For instance, including a web site or URI that was part of an attack is no= t covered, although the schema includes URIs for reference materials. This= one won't be part of the issue described below, but rather the less common= ly shared indicators. We may be better able to address this once we sort o= ut some updates to RFC5070-bis and then we'll have a better handle on what = we want to see embedded through other schemas. I'll list out a few example= s that we either have discussed on list or in a meeting before or that we m= ay need to address. URIs part of an attack - I think we all agreed this just needs to be added = to the IODEF schema in RFC5070-bis.=20 Registry Keys -- can be included now through the RecordItem class, but it i= s unclear how to represent them. This should probably be addressed in RFC5= 070-bis, but could also be represented in embedded schemas. Email message -- Could be represented through RFC5901 with more detailed do= main information or you could alternatively embed another schema that can a= lso carry that data. So I think this is covered... File Hashes -- covered in RFC5901 or another embedded schema. Rosella questioned if some of the content from RFC5901 should be in the bas= e IODEF schema... I think the best use of embedding other schemas would be = for any of the indicators that are not as commonly shared or are introduced= between IODEF schema revision cycles or if the representation did not prov= ide enough information and the other schema could convey it better. =20 Maybe we should address the updates in RFC5070-bis and discuss what belongs= in that document and what belongs in the RFC5901 extension before trying t= o figure out where to place other indicators unless others have a few good = examples. This may result in guidance to help implementers (reduce their w= ork if we had common guidance). Thanks, Kathleen -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]=20 Sent: Friday, January 11, 2013 3:50 AM To: Moriarty, Kathleen; mile@ietf.org Subject: RE: [mile] IOCs Hi Kathleen and all, Thank you very much for the comments. I agree that we should consider indicators of compromise that are not included in the base IODEF schema. At the same time, perhaps we could clarify what would be these indicators..= . If the indicators are something like an XML-based alert/warning of information leakage, it could be an event that are conveyed in the SCI's EventReport class, IMHO. If the indicators are something like an non-XML ones, I guess it could be conveyed without using SCI draft. For instance, we could use Impact class of the base IODEF to convey the indicators. We could for instance extend the list of indicators of the Impact class, if needed. If the indicators are something like the result of penetration test, or indicators of exposed vulnerabilities, I guess neither SCI classes nor basi= c IODEF classes have right place to fit them in at this moment. Could we elaborate what would be these indicators? I hope I am not missing the point. Kind regards, Take From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Thursday, January 10, 2013 7:09 AM To: mile@ietf.org Subject: [mile] IOCs Hi Take, et. al, =A0 In looking at SCI, I am not sure where you might include indicators of compromise that are not included in the base IODEF schema and would like to know what others think. =A0 To me, the logical place would be directly in the EventData class using the AdditionalData extension class, maybe using another SCI extension class called Detection. =A0 Is there a place where these would fit already that I am missing or do we need another container? =A0 Thank you! Kathleen =A0 From wwwrun@rfc-editor.org Mon Jan 14 11:39:25 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C693121F8B34 for ; Mon, 14 Jan 2013 11:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2cbrxwh+rnz for ; Mon, 14 Jan 2013 11:39:25 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEC021F8B35 for ; Mon, 14 Jan 2013 11:39:25 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5E966622E9; Mon, 14 Jan 2013 11:28:43 -0800 (PST) To: trammell@tik.ee.ethz.ch, stephen.farrell@cs.tcd.ie, turners@ieca.com, Kathleen.Moriarty@emc.com, trammell@tik.ee.ethz.ch From: RFC Errata System Message-Id: <20130114192843.5E966622E9@rfc-editor.org> Date: Mon, 14 Jan 2013 11:28:43 -0800 (PST) Cc: mile@ietf.org, rfc-editor@rfc-editor.org Subject: [mile] [Technical Errata Reported] RFC6546 (3455) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jan 2013 19:39:25 -0000 The following errata report has been submitted for RFC6546, "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6546&eid=3455 -------------------------------------- Type: Technical Reported by: John Field Section: 3 Original Text ------------- If a RID system receives an improper RID message in an HTTP Request, it MUST return an appropriate 4xx Client Error result code to the requesting RID system. Corrected Text -------------- If a RID system receives an improper HTTP Request, it MUST return an appropriate 4xx Client Error result code to the requesting RID system. Notes ----- There has been some discussion of this issue on the MILE mailing list. Another possible option for the corrected text is to say nothing at all. That is, by changing the specification to focus on an improper HTTP request, rather than an improper RID message, the corrected text is simply a restatement of existing HTTP behavior. (Either way, this still does constitute a technical change since we would no longer be requiring the 400 status code when the error is with the *RID* content). On this technical point, we had consensus on the MILE mailing list: we SHOULD NOT require an HTTP 4xx status code when there is an error with the RID content itself (as opposed to the HTTP layer). HTTP 4xx status is reserved for errors occurring in the HTTP protocol layer. Errors in the RID content will be reported via the RID Acknowledgement message type, with appropriate choices for the RequestStatus element, and Justification attribute. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6546 (draft-ietf-mile-rfc6046-bis-09) -------------------------------------- Title : Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS Publication Date : April 2012 Author(s) : B. Trammell Category : PROPOSED STANDARD Source : Managed Incident Lightweight Exchange Area : Security Stream : IETF Verifying Party : IESG From Paul.Stoecker@rsa.com Thu Jan 17 06:02:28 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E3221F8746 for ; Thu, 17 Jan 2013 06:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.39 X-Spam-Level: * X-Spam-Status: No, score=1.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m77kiF6BvO0j for ; Thu, 17 Jan 2013 06:02:27 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id C779621F8742 for ; Thu, 17 Jan 2013 06:02:27 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0HE2Qn4021347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Jan 2013 09:02:26 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Thu, 17 Jan 2013 09:02:14 -0500 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0HE2Ewx032599 for ; Thu, 17 Jan 2013 09:02:14 -0500 Received: from mxhub40.corp.emc.com (128.222.70.107) by mxhub30.corp.emc.com (128.222.70.170) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 17 Jan 2013 09:02:14 -0500 Received: from mx33a.corp.emc.com ([169.254.1.154]) by mxhub40.corp.emc.com ([128.222.70.107]) with mapi; Thu, 17 Jan 2013 09:02:14 -0500 From: "Stoecker, Paul" To: "mile@ietf.org" Date: Thu, 17 Jan 2013 09:02:12 -0500 Thread-Topic: Errata Questions for RFC 5070 Thread-Index: Ac30u0Azi1JysA5qQfyK+hzPb1evrg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CD1D6E94A244paulstoeckerrsacom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] Errata Questions for RFC 5070 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jan 2013 14:02:29 -0000 --_000_CD1D6E94A244paulstoeckerrsacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Team, As I am going through the errata that has been submitted for RFC 5070 in pr= eparation for a draft of an update, I noticed 2 issues with the errata that= I wanted to get thoughts on: For #18, Section 3.16.2, in the Address Class, the attribute "category" is = listed in the schema as Optional, so the definition in the specification re= quires updating as follows. Change from: " category Required. ENUM. Classifies the role the host or network played in the incident. The possible values are:" To: " category Optional. ENUM. Classifies the role the host or network played in the incident. The possible values are:" In this one, the description of category is incorrect, it was carried over = from errata #17. However, I checked the schema and it is optional, so I ch= anged the UML to make it optional as indicated above. I just wanted to mak= e sure that we agree that it OK? I don't think I need to submit errata for= the errata ;-), but wanted everyone to be aware. #21, Section 3.17 Service Class, the UML diagram and text does not match th= e schema for the ProtoField element. Change from: " ProtoFlags Zero or one. INTEGER. A layer-4 protocol specific flag field." To: " ProtoField Zero or one. INTEGER. A layer-4 protocol specific flag field." AND update the UML diagram from: " +---------------------+ | Service | +---------------------+ | INTEGER ip_protocol |<>--{0..1}--[ Port ] | |<>--{0..1}--[ Portlist ] | |<>--{0..1}--[ ProtoCode ] | |<>--{0..1}--[ ProtoType ] | |<>--{0..1}--[ ProtoFlags ] | |<>--{0..1}--[ Application ] +---------------------+ Figure 31: The Service Class" To: " +---------------------+ | Service | +---------------------+ | INTEGER ip_protocol |<>--{0..1}--[ Port ] | |<>--{0..1}--[ Portlist ] | |<>--{0..1}--[ ProtoCode ] | |<>--{0..1}--[ ProtoType ] | |<>--{0..1}--[ ProtoField ] | |<>--{0..1}--[ Application ] +---------------------+ Figure 31: The Service Class" I understand that we didn't want to make changes to the schema at the time = that the errata was submitted, but for this one I really believe that it sh= ould be ProtoFlags and not ProtField. I understand that this could mean th= at there are issues with backward compatibility for those that have impleme= nted this RFC, but how do we handle other errors that occur in a schema? I= s it better to change the UML to match the schema? I believe that we shoul= d fix the schema and change it to ProtoFlags, what do others think? Regards, Paul Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com --_000_CD1D6E94A244paulstoeckerrsacom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Team,

=
As I am = going through the errata that has been submitted for RFC 5070 in preparatio= n for a draft of an update, I noticed 2 issues with the errata that I wante= d to get thoughts on:

For #18, Section 3.16.2, in = the Address Class, the attribute "category" is listed in the schema as Opti= onal, so the definition in the specification requires updating as follows.<= /span>

Change from:

"   category

      Required.  ENUM.  Classifies th= e role the host or network played

      in the incident.  The possible value= s are:"

To:

"   category

      Optional.  ENUM.  Classifies th= e role the host or network played

      in the incident.  The possible value= s are:"


In this one, the description of category is inco= rrect, it was carried over from errata #17.  However, I checked the sc= hema and it is optional, so I changed the UML to make it optional as indica= ted above.  I just wanted to make sure that we agree that it OK?  = ;I don't think I need to submit errata for the errata ;-), but wanted every= one to be aware.


#21, Secti= on 3.17 Service Class, the UML diagram and text does not match the schema f= or the ProtoField element.

Change from:

"   ProtoF= lags

    &= nbsp; Zero or one.  INTEGER.  A layer-4 protocol specific flag fi= eld."

To:

"   ProtoF= ield

    &= nbsp; Zero or one.  INTEGER.  A layer-4 protocol specific flag fi= eld."

AND update the = UML diagram from:

"  +------= ---------------+

   | = Service             |

   +-= --------------------+

   | = INTEGER ip_protocol |<>--{0..1}--[ Port        ]<= /span>

   | =                     |<= >--{0..1}--[ Portlist    ]

   | =                     |<= >--{0..1}--[ ProtoCode   ]

   | =                     |<= >--{0..1}--[ ProtoType   ]

   | =                     |<= >--{0..1}--[ ProtoFlags  ]

   | =                     |<= >--{0..1}--[ Application ]

   +-= --------------------+


   &n= bsp;                   Figure = 31: The Service Class"

To:

"  +------= ---------------+

   | = Service             |

   +-= --------------------+

   | = INTEGER ip_protocol |<>--{0..1}--[ Port        ]<= /span>

   | =                     |<= >--{0..1}--[ Portlist    ]

   | =                     |<= >--{0..1}--[ ProtoCode   ]

   | =                     |<= >--{0..1}--[ ProtoType   ]

   | =                     |<= >--{0..1}--[ ProtoField  ]

   | =                     |<= >--{0..1}--[ Application ]

   +-= --------------------+


   &n= bsp;                   Figure = 31: The Service Class"




I understand that we didn= 't want to make changes to the schema at the time that the errata was submi= tted, but for this one I really believe that it should be ProtoFlags and no= t ProtField.  I understand that this could mean that there are issues = with backward compatibility for those that have implemented this RFC, but h= ow do we handle other errors that occur in a schema?  Is it better to = change the UML to match the schema?  I believe that we should fix the = schema and change it to ProtoFlags, what do others think?

Regards,

=
Paul


=
=
Paul W. Stoecker, Ph.D.

SMC Lead Con= tent Architect

RSA, The Security Division of EMC

cell: 302.379.3375 | e: paul.stoecker@r= sa.com


--_000_CD1D6E94A244paulstoeckerrsacom_-- From kathleen.moriarty@emc.com Sun Jan 20 16:48:49 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DAA21F8754 for ; Sun, 20 Jan 2013 16:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgDp4NMBcPrn for ; Sun, 20 Jan 2013 16:48:48 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 82DB721F8749 for ; Sun, 20 Jan 2013 16:48:44 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0L0mg2S004856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jan 2013 19:48:43 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sun, 20 Jan 2013 19:48:26 -0500 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0L0mO2F007607; Sun, 20 Jan 2013 19:48:24 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Sun, 20 Jan 2013 19:48:24 -0500 From: "Moriarty, Kathleen" To: "Kent_Landfield@mcafee.com" , "takeshi_takahashi@nict.go.jp" , "pkampana@cisco.com" , "mile@ietf.org" Date: Sun, 20 Jan 2013 19:46:34 -0500 Thread-Topic: [mile] Question for malware file exchange using SCI draft Thread-Index: Ac3tubkX8RCJhpTiT+iimvYSUJTSbAACRuhAACpZnAAAC+pEAAI1N5Ra Message-ID: References: <006701cdee42$58bfa7e0$0a3ef7a0$@nict.go.jp>, <3CBA099FBA0AB843895D72474092B8CF0D043C@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF0D043C@MIVEXAMER1N1.corp.nai.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Question for malware file exchange using SCI draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jan 2013 00:48:49 -0000 Take, With your text additions, I think AttackPattern makes sense. I did hear fr= om a few other people who said they wanted this added, but did not have a s= trong preference as both options are reasonable. Any other opinions on where malware gets included via the SCI draft? If no= t, let's go ahead and put this in AttackPattern. Thank you! Kathleen ________________________________________ From: Kent_Landfield@mcafee.com [Kent_Landfield@mcafee.com] Sent: Wednesday, January 09, 2013 3:02 PM To: takeshi_takahashi@nict.go.jp; Moriarty, Kathleen; pkampana@cisco.com; m= ile@ietf.org Subject: Re: [mile] Question for malware file exchange using SCI draft Take, I too prefer the Attack Pattern class for the same reason you stated. Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Takeshi Takahashi > Date: Wednesday, January 9, 2013 2:21 AM To: Kathleen Moriarty >, "'Panos Kampanakis (pkampana)'" >, "mile@ietf.org" > Subject: Re: [mile] Question for malware file exchange using SCI draft Hi Panos, Kathleen, and all, Thank you very much for raising discussion. Let me join the discussion here. We were wondering what the community thinks is the best way to exchange malware in an IODEF document. To me it seems either EventReport or AttackPattern classes are adequate. Now, how will the malware file be exchanged is another question. I wanted to see if it is possible to add IEEE=92s MMDEF in one of SCI=92s =93Candida= te Specifications for the IANA Table=94. MMDEF would be for the exchange of malware files in a secure way. FYI, I believe MMDEF is used as that is posted right on the IEEE site by APWG with IODEF I personally think it would be very nice to register MMDEF in the SCI's IAN= A Table. IMHO, I slightly prefer the AttackPattern class since the MMDEF contains th= e samples (malware files) that tried to attack the user's asset. Does the MMDEF metadata XML itself contain actual file data or URI (or any other pointer)? I think no. (correct me please if I am wrong.) If so, I guess we could convey the MMDEF data by setting values as follows: SpecID <- namespace of MMDEF ver x.x RawData <- the XML metadata Reference <- pointer to the sample (malware file) I might have wrong understanding of MMDEF. So, please correct me if above is not suitable... Attack pattern Definition from SCI: The extension describes attack patterns of incidents or events. I think the definitions of the IODEF classes are fine, but the above SCI class definition could be modified to nicely support MMDEF here. For instance, it could be rewritten like this: "The extension describes attack patterns of incidents or events as well as their tools such as malware." Meanwhile, the SCI draft should note that the validation (and parsing) process should be careful if we actually carry a sample (of malware) instea= d of its pointer. Kind regards, Take From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Wednesday, January 09, 2013 2:34 AM To: Panos Kampanakis (pkampana); mile@ietf.org Subject: Re: [mile] Question for malware file exchange using SCI draft Hi Panos, Take, et al, Interesting=85 getting opinions from the list will be very helpful! I think if the group goes this route, we should pick which of those two classes make the most sense to embed MMDEF in IODEF using the SCI draft. I= f folks think this is the best way to include a malware sample (please post opinions!), it should be possible to put this directly in the SCI draft as the first entry for the selected class in the IANA table. More complex representations for malware could come in the IANA table method later if needed. The other way to include a file with malware is described in RFC5901, but if APWG has taken this path, it may be the better option. Copying Pat. If it is, we=92ll want to include this in the IODEF guidance document as well for use cases that require the exchange of malware. As for which class it belongs in, there are some considerations folks may want to weigh in on (and there may be more I don=92t list): EventReport is in the Record class of IODEF. Definition from IODEF Record Class: The Record class is a container class for log and audit data that provides supportive information about the incident. The source of this data will often be the output of monitoring tools. These logs should substantiate the activity described in the document. Definition of EventReport Class from SCI: The extension embeds structured event reports. AttackPattern is contained in the Method class of IODEF. Definition from IODEF of Method Class: The Method class describes the methodology used by the intruder to perpetrate the events of the incident. This class consists of a list of references describing the attack method and a free form description of the technique. Attack pattern Definition from SCI: The extension describes attack patterns of incidents or events. We can certainly change definitions of the classes in IODEF if that is the right thing to do as well. Or do folks think one of these is a better fit than the other? This seems like a solid use case of data commonly exchanged with a possible schema to reference in a standards organization, so maybe this is a candidate for our MTI for the SCI draft? MMDEF is not a formal standard though because of where it sits in IEEE, but it is a site that can be referenced and the schema is posted publicly. Thanks! Kathleen From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Panos Kampanakis (pkampana) Sent: Tuesday, January 08, 2013 11:06 AM To: mile@ietf.org Subject: [mile] Question for malware file exchange using SCI draft Hi Take et al, We were wondering what the community thinks is the best way to exchange malware in an IODEF document. To me it seems either EventReport or AttackPattern classes are adequate. Now, how will the malware file be exchanged is another question. I wanted t= o see if it is possible to add IEEE=92s MMDEF in one of SCI=92s =93Candidate Specifications for the IANA Table=94. MMDEF would be for the exchange of malware files in a secure way. FYI, I believe MMDEF is used as that is posted right on the IEEE site by APWG with IODEF Rgs, Panos _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Fri Jan 25 11:57:57 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E214221F87C3 for ; Fri, 25 Jan 2013 11:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.694 X-Spam-Level: X-Spam-Status: No, score=0.694 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4Tg6YEYJMUO for ; Fri, 25 Jan 2013 11:57:57 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3F78E21F863C for ; Fri, 25 Jan 2013 11:57:57 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0PJvp7v016123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jan 2013 14:57:54 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Fri, 25 Jan 2013 14:57:45 -0500 Received: from mxhub34.corp.emc.com (mxhub34.corp.emc.com [10.254.93.82]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0PJvi8R021046; Fri, 25 Jan 2013 14:57:45 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub34.corp.emc.com ([::1]) with mapi; Fri, 25 Jan 2013 14:57:44 -0500 From: "Moriarty, Kathleen" To: Takeshi Takahashi , "mile@ietf.org" Date: Fri, 25 Jan 2013 14:57:43 -0500 Thread-Topic: [mile] IOCs Thread-Index: AQEDdMJpat77Go03FnWbR/JpffItGJnYvIGwgBahcEA= Message-ID: References: <012901cdefd8$aadf0790$009d16b0$@nict.go.jp> In-Reply-To: <012901cdefd8$aadf0790$009d16b0$@nict.go.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jan 2013 19:57:58 -0000 Hi Take & all, Thank you for the detailed response and sorry about the delay in my respons= e! I like your examples and agree, there are a number of places where SCI alre= ady has the placeholders to add indicators that are not covered in the base= model. Some other examples may include specific fields of email messages = or if we want to extend using something that would let us express a combina= tion of indicators from higher level analysis tools (network, malware, host= -based, etc). For the discussion below, I was thinking more of combined se= t with relationships that may be included in a single extension point, so t= hat's why I was thinking about the EventData class, but there may be better= locations or a specific area within the EventData. Paul Stoecker had sugg= ested a "Detection" class as a consideration. We would need a way to connect the indicators in the base IODEF to the indi= cators included in other schemas. Someone had suggested the use of an attr= ibute on IODEF indicators, where we could include a unique ID or reference = number - maybe call it indicator_ID or something similar (this would have t= o be in the RFC5070-bis update if agreed). We may want this on IODEF inclu= ded IPs or other elements. It could correlate then with GUID or reference = IDs used in other indicator schemas that include IOCs not in the base IODEF= schema. Any opinions on an Indicator_ID attribute (or some other name) and the best= extension point for combined sets of indicators (AdditionalData off of Eve= ntData (change just in SCI) or a "Detection" class in the EventData class (= change in RFC5070-bis and SCI for this option))? Thanks, Kathleen -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]=20 Sent: Friday, January 11, 2013 3:50 AM To: Moriarty, Kathleen; mile@ietf.org Subject: RE: [mile] IOCs Hi Kathleen and all, Thank you very much for the comments. I agree that we should consider indicators of compromise that are not included in the base IODEF schema. At the same time, perhaps we could clarify what would be these indicators..= . If the indicators are something like an XML-based alert/warning of information leakage, it could be an event that are conveyed in the SCI's EventReport class, IMHO. If the indicators are something like an non-XML ones, I guess it could be conveyed without using SCI draft. For instance, we could use Impact class of the base IODEF to convey the indicators. We could for instance extend the list of indicators of the Impact class, if needed. If the indicators are something like the result of penetration test, or indicators of exposed vulnerabilities, I guess neither SCI classes nor basi= c IODEF classes have right place to fit them in at this moment. Could we elaborate what would be these indicators? I hope I am not missing the point. Kind regards, Take From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Thursday, January 10, 2013 7:09 AM To: mile@ietf.org Subject: [mile] IOCs Hi Take, et. al, =A0 In looking at SCI, I am not sure where you might include indicators of compromise that are not included in the base IODEF schema and would like to know what others think. =A0 To me, the logical place would be directly in the EventData class using the AdditionalData extension class, maybe using another SCI extension class called Detection. =A0 Is there a place where these would fit already that I am missing or do we need another container? =A0 Thank you! Kathleen =A0 From chatlga2000@yahoo.com Sat Jan 26 00:05:42 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FF821F84D1 for ; Sat, 26 Jan 2013 00:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.99 X-Spam-Level: *** X-Spam-Status: No, score=3.99 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lid2sVAO6MI1 for ; Sat, 26 Jan 2013 00:05:42 -0800 (PST) Received: from nm6-vm2.bullet.mail.ne1.yahoo.com (nm6-vm2.bullet.mail.ne1.yahoo.com [98.138.90.154]) by ietfa.amsl.com (Postfix) with ESMTP id CDF3A21F8487 for ; Sat, 26 Jan 2013 00:05:41 -0800 (PST) Received: from [98.138.90.55] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 26 Jan 2013 08:05:41 -0000 Received: from [98.138.89.249] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 26 Jan 2013 08:05:41 -0000 Received: from [127.0.0.1] by omp1041.mail.ne1.yahoo.com with NNFMP; 26 Jan 2013 08:05:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 2670.94217.bm@omp1041.mail.ne1.yahoo.com Received: (qmail 1360 invoked by uid 60001); 26 Jan 2013 08:05:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1359187540; bh=jWXjvHOWGRqqCt58pxMADM3No4z+Q/3N8Oa0kUMVA4w=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=LWoWJou350CYrBBYZeT/Zej+2MVGE06SAbe1L1elYUTlPCAQMp8Y7v2C+XpGuU6hsyaD4doDhm2A6QGBJHXm8W4Osagbpebmsmc/hIrpjIXljy+DlMNCKARDMZIGAT9Fjlsi51fJqXV4zaarfNriva8tRK3SmkJrxLaiyRZcfjo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=eDb/Guk4QgqGwzxYVOMzCslfB/Hrp2yjvlNoobb2Trl1dZKgwmAD+Uz+3gVwsKtqPguef/oFpvIotL67CwlaLDCQsOU72IdjJ5d1Ttuts3CNnvQaizapkfUL840Yi7IrDN4IchCVYl3iQ1DuEEXJxSZStJhDC0/o3tIeMIJvg4o=; X-YMail-OSG: yLffl7IVM1nvKT_QjzZHZhPSFDt.STtmkX3fpCjTX3jrrGv FcMRKZPo5tJI7ZztZZdCJhq8PJIW8L8HLtWeUEvAvsLUUXyBCkkO6a1QuGee gtcG4r8YhzR7aa8S2bIHVgY4pK0Gch_pCDxNzw2ThJGQ8VTE.Of4THANtork KkQrDiAwTQDVygwBJLFaCPNrWO2K4Ywsb21LXtX2TE4rsXNf2nP.xrmaK5.W QPuJn7sxAvjp.vSLY4BWsTpK2.miaz4dqXMpAl.gJQrzHSg93vqDTDzbwp.n GWDjcLaMZ6m_Q2eKGpnqPA0G_G38dusQLT9EJpR7Ns_fVes7Dn0PO08CvyTr vTP59IGRWJkGf.jJdp7wUs6DIqGGZpvpKONext5fvH1ljSMkWYylo8RKmQo3 aD9C_dLQ6mav0eX3LaM8EqGaPLNZ8j.QivOjWRHcZznC.2Ft91CADeHvyySS iA.0S674vqBBb4iQ1osElPk2_4H8YpRkeBMPoUO9vRbToiQge5MgAIHKUD00 mUg-- Received: from [71.22.243.36] by web121604.mail.ne1.yahoo.com via HTTP; Sat, 26 Jan 2013 00:05:40 PST X-Rocket-MIMEInfo: 001.001, R3JlZXRpbmdzIEV2ZXJ5b25lLA0KDQpUYWtlIG1lbnRpb25lZCB0d28gdHlwZXMgb2YgaW5kaWNhdG9ycyBiYXNlZCBvbiB0aGUgOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoxKSBJZiB0aGUgaW5kaWNhdG9ycyBhcmUgc29tZXRoaW5nIGxpa2UgYW4gWE1MLWJhc2VkIGFsZXJ0L3dhcm5pbmcgb2YNCmluZm9ybWF0aW9uIGxlYWthZ2UsIGl0IGNvdWxkIGJlIGFuIGUBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1359187540.424.YahooMailClassic@web121604.mail.ne1.yahoo.com> Date: Sat, 26 Jan 2013 00:05:40 -0800 (PST) From: "C. Henry Adams & BIE" To: mile@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-36511695-451135232-1359187540=:424" Cc: "C. Henry Adams" Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 26 Jan 2013 08:05:43 -0000 ---36511695-451135232-1359187540=:424 Content-Type: text/plain; charset=us-ascii Greetings Everyone, Take mentioned two types of indicators based on the : ------------------------------------------------------------------------------------------------------ 1) If the indicators are something like an XML-based alert/warning of information leakage, it could be an event that are conveyed in the SCI's EventReport class, IMHO. 2) If the indicators are something like an non-XML ones, I guess it could be conveyed without using SCI draft. For instance, we could use Impact class of the base IODEF to convey the indicators. We could for instance extend the list of indicators of the Impact class, if needed. ------------------------------------------------------------------------------------------------------ In doing so he pointed out the "Impact Class" Whereas, Kathleen stated, ----------------------------------------------------------------------------------------------------- For the discussion below, I was thinking more of combined set with relationships that may be included in a single extension point, so that's why I was thinking about the EventData class, but there may be better locations or a specific area within the EventData. Paul Stoecker had suggested a "Detection" class as a consideration. ---------------------------------------------------------------------------------------------------- Kathleen thoughts related yet still with other indicators and the EventData Class. Is there a possible way to create a new XML class which encompass combining the EventData, Detection and base IODEF classes to simplify this issue? C. Henry Adams chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited. ---36511695-451135232-1359187540=:424 Content-Type: text/html; charset=us-ascii
Greetings Everyone,

Take mentioned two types of indicators based on the :
------------------------------------------------------------------------------------------------------
1) If the indicators are something like an XML-based alert/warning of
information leakage, it could be an event that are conveyed in the SCI's
EventReport class, IMHO.

2) If the indicators are something like an non-XML ones, I guess it could be
conveyed without using SCI draft.
For instance, we could use Impact class of the base IODEF to convey the
indicators.
We could for instance extend the list of indicators of the Impact class, if
needed.
------------------------------------------------------------------------------------------------------

In doing so he pointed out the "Impact Class"

Whereas, Kathleen stated,

-----------------------------------------------------------------------------------------------------
For the discussion below, I was thinking more of combined set with relationships that may be included in a single extension point, so that's why I was thinking about the EventData class, but there may be better locations or a specific area within the EventData.

Paul Stoecker had suggested a "Detection" class as a consideration.
----------------------------------------------------------------------------------------------------

Kathleen thoughts related yet still with other indicators and the EventData Class.

Is there a possible way to create a new XML class which encompass combining the EventData, Detection and base IODEF classes to simplify this issue?


C. Henry Adams
chatlga2000@yahoo.com (Direct Email)
chenryadams@biemediagroup.com


The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited.
---36511695-451135232-1359187540=:424-- From kathleen.moriarty@emc.com Sat Jan 26 06:51:24 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB0E21F859C for ; Sat, 26 Jan 2013 06:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KgZSF1PEFuo for ; Sat, 26 Jan 2013 06:51:23 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7932721F8552 for ; Sat, 26 Jan 2013 06:51:23 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0QEpKn5002380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 26 Jan 2013 09:51:20 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Sat, 26 Jan 2013 09:51:17 -0500 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0QEpH4e003773 for ; Sat, 26 Jan 2013 09:51:17 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Sat, 26 Jan 2013 09:51:16 -0500 From: "Moriarty, Kathleen" To: "Stoecker, Paul" , "mile@ietf.org" Date: Sat, 26 Jan 2013 09:51:15 -0500 Thread-Topic: Errata Questions for RFC 5070 Thread-Index: Ac30u0Azi1JysA5qQfyK+hzPb1evrgHGGEyA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Errata Questions for RFC 5070 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 26 Jan 2013 14:51:24 -0000 Hi Paul, Thank you for getting RFC5070-bis ready for updates! As you make changes, please include a section that lists any updates from R= FC5070. You can look at RFC6545 or RFC6546 to see how it was done in those= documents. As for #17, yes, it looks like the wrong text was included for the errata, = but you noted the discrepancy correctly for which the errata was posted. W= hile it was correct for the errata to prefer the schema, it would be easier= for automated tools if the address category was required in the schema. I= f you make the change so that the schema is updated, please include that in= the updates section. If someone reviews the document later, they will see= the change in case they didn't weigh in now when it was first posted. For #21, I agree, just go ahead and correct the schema, just note the chang= e from the errata in the updates section. If you don't hear anything on list to the contrary, it is probably better t= o get the document out as a number of people will wait for that before star= ting to comment. =20 A few people have mentioned they will submit requested changes once the dra= ft is published from their use of IODEF. Thank you! Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Stoecker, = Paul [Paul.Stoecker@rsa.com] Sent: Thursday, January 17, 2013 9:02 AM To: mile@ietf.org Subject: [mile] Errata Questions for RFC 5070 Team, As I am going through the errata that has been submitted for RFC 5070 in pr= eparation for a draft of an update, I noticed 2 issues with the errata that= I wanted to get thoughts on: For #18, Section 3.16.2, in the Address Class, the attribute "category" is = listed in the schema as Optional, so the definition in the specification re= quires updating as follows. Change from: " category Required. ENUM. Classifies the role the host or network played in the incident. The possible values are:" To: " category Optional. ENUM. Classifies the role the host or network played in the incident. The possible values are:" In this one, the description of category is incorrect, it was carried over = from errata #17. However, I checked the schema and it is optional, so I ch= anged the UML to make it optional as indicated above. I just wanted to mak= e sure that we agree that it OK? I don't think I need to submit errata for= the errata ;-), but wanted everyone to be aware. #21, Section 3.17 Service Class, the UML diagram and text does not match th= e schema for the ProtoField element. Change from: " ProtoFlags Zero or one. INTEGER. A layer-4 protocol specific flag field." To: " ProtoField Zero or one. INTEGER. A layer-4 protocol specific flag field." AND update the UML diagram from: " +---------------------+ | Service | +---------------------+ | INTEGER ip_protocol |<>--{0..1}--[ Port ] | |<>--{0..1}--[ Portlist ] | |<>--{0..1}--[ ProtoCode ] | |<>--{0..1}--[ ProtoType ] | |<>--{0..1}--[ ProtoFlags ] | |<>--{0..1}--[ Application ] +---------------------+ Figure 31: The Service Class" To: " +---------------------+ | Service | +---------------------+ | INTEGER ip_protocol |<>--{0..1}--[ Port ] | |<>--{0..1}--[ Portlist ] | |<>--{0..1}--[ ProtoCode ] | |<>--{0..1}--[ ProtoType ] | |<>--{0..1}--[ ProtoField ] | |<>--{0..1}--[ Application ] +---------------------+ Figure 31: The Service Class" I understand that we didn't want to make changes to the schema at the time = that the errata was submitted, but for this one I really believe that it sh= ould be ProtoFlags and not ProtField. I understand that this could mean th= at there are issues with backward compatibility for those that have impleme= nted this RFC, but how do we handle other errors that occur in a schema? I= s it better to change the UML to match the schema? I believe that we shoul= d fix the schema and change it to ProtoFlags, what do others think? Regards, Paul Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com From kathleen.moriarty@emc.com Sat Jan 26 07:13:42 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C942A21F85EE for ; Sat, 26 Jan 2013 07:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMjGR7GxHQ+H for ; Sat, 26 Jan 2013 07:13:42 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0DB21F85DB for ; Sat, 26 Jan 2013 07:13:41 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0QFDai0022539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Jan 2013 10:13:40 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sat, 26 Jan 2013 10:13:23 -0500 Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0QFDKEP010821; Sat, 26 Jan 2013 10:13:20 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Sat, 26 Jan 2013 10:13:20 -0500 From: "Moriarty, Kathleen" To: "C. Henry Adams & BIE" , "mile@ietf.org" Date: Sat, 26 Jan 2013 10:13:19 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac37nAFBP3vbnfVxRP+UkwNEhyuP5gAOMYCf Message-ID: References: <1359187540.424.YahooMailClassic@web121604.mail.ne1.yahoo.com> In-Reply-To: <1359187540.424.YahooMailClassic@web121604.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 26 Jan 2013 15:13:42 -0000 Hello C. Henry & others, Thanks for taking a look at this. We have a few considerations in this ema= il thread I would like to hear thoughts on (and there may be more once RFC5= 070-bis is actively edited). The AdditionalData class and the RecordItem class both allow for non-XML ex= tensions. Where you place the extensions should be specific to the logical= grouping of the parent elements so you can understand more about the inclu= ded data in most cases. =20 The Impact class can be used to provide context information on the included= data of the report and also can include a confidence rating on the report = as a whole. Extensions related to impact would be one level higher (at the= moment) in the Assessment class using the AdditionalData extension point. = =20 Take asked about including vulnerability information, I would think that wo= uld fit under the Vulnerability extension point of the SCI draft in the Met= hod class. He did ask about non-XML. RecordItem or AdditionalData do allo= w for non-XML extension points, we could either have the SCI draft handle t= hese as well or have the extensions that are non-XML come directly off the = AdditionalData or RecordItem classes according to what makes sense from a l= ogical standpoint. As for my question, it was two-fold. Indicator based schemas have a reference number or a GUID for the various i= ndicators they share. If we are extending to embed other schemas that incl= ude such reference or GUID identifiers, do we want to add an attribute to t= he various elements in IODEF that could be indicators? Is this enough to m= ake the connections or is something else else needed? We could add somethi= ng like an Indicator_ID in RFC5070-bis which would then correlate to the re= ference or GUID identifiers. Then the other question was on how to include indicators that are not in th= e base schema that may be related or have language with "and" "or" to speci= fy the relationships. In some cases, you will want to group these indictor= s in one extension point, where they may fit logically in multiple places i= f the relationships did not need to be shown in the data format. If we hav= e cases like this where you need more complex representations, should we us= e one extension point via the SCI draft off of the EventData class Addition= alData extension point? Opinions are needed here....=20 A few people have mentioned wanting to include some commonly shared indicto= rs into the base IODEF document. We could have a catch-all class that does= this and has an extension point off of it in EventData or we could continu= e to group items in logical places as is done now in IODEF and then have th= e extension point for combined indicators via SCI. I think I like the latt= er approach. Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. Henry A= dams & BIE [chatlga2000@yahoo.com] Sent: Saturday, January 26, 2013 3:05 AM To: mile@ietf.org Cc: C. Henry Adams Subject: Re: [mile] IOCs Greetings Everyone, Take mentioned two types of indicators based on the : ---------------------------------------------------------------------------= --------------------------- 1) If the indicators are something like an XML-based alert/warning of information leakage, it could be an event that are conveyed in the SCI's EventReport class, IMHO. 2) If the indicators are something like an non-XML ones, I guess it could b= e conveyed without using SCI draft. For instance, we could use Impact class of the base IODEF to convey the indicators. We could for instance extend the list of indicators of the Impact class, if needed. ---------------------------------------------------------------------------= --------------------------- In doing so he pointed out the "Impact Class" Whereas, Kathleen stated, ---------------------------------------------------------------------------= -------------------------- For the discussion below, I was thinking more of combined set with relation= ships that may be included in a single extension point, so that's why I was= thinking about the EventData class, but there may be better locations or a= specific area within the EventData. Paul Stoecker had suggested a "Detection" class as a consideration. ---------------------------------------------------------------------------= ------------------------- Kathleen thoughts related yet still with other indicators and the EventData= Class. Is there a possible way to create a new XML class which encompass combining= the EventData, Detection and base IODEF classes to simplify this issue? C. Henry Adams chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com The information contained herein is for the exclusive use of the original r= ecipient. This information is granted for limited distribution within the r= ecipient's place of business for planning purposes only. Further disseminat= ion, whether private or public is prohibited. From chatlga2000@yahoo.com Sat Jan 26 15:17:16 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A7921F8626 for ; Sat, 26 Jan 2013 15:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.804 X-Spam-Level: *** X-Spam-Status: No, score=3.804 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DE+HXgSKl0ak for ; Sat, 26 Jan 2013 15:17:15 -0800 (PST) Received: from nm24-vm2.bullet.mail.ne1.yahoo.com (nm24-vm2.bullet.mail.ne1.yahoo.com [98.138.91.212]) by ietfa.amsl.com (Postfix) with ESMTP id 8483021F85EE for ; Sat, 26 Jan 2013 15:17:15 -0800 (PST) Received: from [98.138.90.49] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 26 Jan 2013 23:17:10 -0000 Received: from [98.138.89.196] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 26 Jan 2013 23:17:10 -0000 Received: from [127.0.0.1] by omp1054.mail.ne1.yahoo.com with NNFMP; 26 Jan 2013 23:17:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 167744.25369.bm@omp1054.mail.ne1.yahoo.com Received: (qmail 92023 invoked by uid 60001); 26 Jan 2013 23:17:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1359242229; bh=SD8sYEJnYaEVA9h/mmRvFng8P0aUkynt+srKaUkFWCs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=sdBVThaXU1hPXgtXW+0RIlgRcHeFpC/8Ti+eVkK65SoXOw2HnM3N6jWNC5FlV1GoR/XzqJdWEsRYAb/thzVWZ3iTJcYnYY867EP0AFFWJ7vybGpCVtdzQbQV+CE7fVjWffaGKK46lyOAIlhpbPJNafQTILdU63WdYT+SiB1Nrg0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QQ3U/uEYGTyeJ8cZGKIDZuKoGP2jtq5GjwqCSfI7qvGYjzptdLiHcXl4hPw6rSfJd5k+VOQVJmQj9AI2xfCRzeMcZH84PSVN3U2e5M8ai44fjBj6PaAOh2RzksesdGWsqJ/GgmnlATEs22lzrlmVbJ66jWUE6rxzUCXMmLNSZU8=; X-YMail-OSG: BpjPx5UVM1ngo3j2K22O1O1uKK6z5SoYGVRwep7E50ynnTF ZEIvVSmWO8Uwy_8Nael2qxe4T9XWS7wfA4lEPQ2AnXu0e5bwTdOmAG49NGPT KielJ6dT.oOIiERzcGgMNYhUXW1OXIjO3ZAkHGg_e_P9XsZlW94mBusyVP4A JVuBs808GW6vVEF.h8Hw1INCLqo11unOQYdtUHNK8cXO0a94n4zEFPOKyYC8 opqCeTQcFx8cA4rR_JRA69O5Zs4HBQjD8p.W_OjkhuyJQCId7.y2BjRB1bXd dfn.WF0YThremJOWj1klgcPjcep.EQKpAsnXQdjATS5otMZU_T808glnVukF ga_K.e7WAYjsGgp8mB6h46yrmn9yIfMz96keW.ICCiDFvaxd491x82hotwJn Xo2opV32u.x0PWaWDWFHlgJcgJYHH3ILnm8snS_2H0OZOkY9iacrtGzsU5FG IByh_qVMDTSuUwdBklqoglTa0By.PZkEcKjEYc5fFEOXrtVyZUsC0EKUiI12 CNCS3A0YFm5Im8OnHlh5AdeY- Received: from [65.82.192.67] by web121604.mail.ne1.yahoo.com via HTTP; Sat, 26 Jan 2013 15:17:09 PST X-Rocket-MIMEInfo: 001.001, R3JlZXRpbmdzIEthdGhsZWVuLA0KDQpZb3VyIGxvZ2ljIHN0aW11bGF0ZXMgbXkgdmlzaW9uYXJ5IGJyYWluIGJlY2F1c2UgSSdtIGFtYXplZCBhdCB0aGUgbWFueSBhdmVudWVzIHlvdSByZXZpZXcgd2l0aCB0aGlzIGFwcHJvYWNoIGF0IG9uY2UuwqAgSG93ZXZlcizCoCBjb3VsZCB5b3Ugc2hhcmUgYSBmZXcgYWR2YW50YWdlcyBhbmQgZGlzYWR2YW50YWdlcyB0byB0aGUgbGF0dGVyPw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0BMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1359242229.91664.YahooMailClassic@web121604.mail.ne1.yahoo.com> Date: Sat, 26 Jan 2013 15:17:09 -0800 (PST) From: "C. Henry Adams & BIE" To: KathleenMoriarty In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-36511695-1532438899-1359242229=:91664" Cc: mile@ietf.org Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 26 Jan 2013 23:17:16 -0000 ---36511695-1532438899-1359242229=:91664 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Greetings Kathleen, Your logic stimulates my visionary brain because I'm amazed at the many ave= nues you review with this approach at once.=A0 However,=A0 could you share = a few advantages and disadvantages to the latter? ---------------------------------------------------------------------------= ----------------------------------------------- "we could continue to group items in logical places as is done now in =0AIO= DEF and then have the extension point for combined indicators via SCI." ---------------------------------------------------------------------------= ---------------------------------------------- You pointed out what you consider to be logical places, but if I wanted to = protect information from parties capable of ascertaining it from your logic= al places, perhaps we should also consider to a degree what appears to be i= llogical in brilliant minds in some instances. C. Henry Adams =0Achatlga2000@yahoo.com (Direct Email) =0Achenryadams@biemediagroup.com =0A =0AThe information contained herein is for the exclusive use of the origina= l recipient. This information is granted for limited distribution within th= e recipient's place of business for planning purposes only. Further dissemi= nation, whether private or public is prohibited. --- On Sat, 1/26/13, Moriarty, Kathleen wrote: From: Moriarty, Kathleen Subject: RE: [mile] IOCs To: "C. Henry Adams & BIE" , "mile@ietf.org" Date: Saturday, January 26, 2013, 10:13 AM Hello C. Henry & others, Thanks for taking a look at this.=A0 We have a few considerations in this e= mail thread I would like to hear thoughts on (and there may be more once RF= C5070-bis is actively edited). The AdditionalData class and the RecordItem class both allow for non-XML ex= tensions.=A0 Where you place the extensions should be specific to the logic= al grouping of the parent elements so you can understand more about the inc= luded data in most cases.=A0=20 The Impact class can be used to provide context information on the included= data of the report and also can include a confidence rating on the report = as a whole.=A0 Extensions related to impact would be one level higher (at t= he moment) in the Assessment class using the AdditionalData extension point= .=A0=20 Take asked about including vulnerability information, I would think that wo= uld fit under the Vulnerability extension point of the SCI draft in the Met= hod class.=A0 He did ask about non-XML.=A0 RecordItem or AdditionalData do = allow for non-XML extension points, we could either have the SCI draft hand= le these as well or have the extensions that are non-XML come directly off = the AdditionalData or RecordItem classes according to what makes sense from= a logical standpoint. As for my question, it was two-fold. Indicator based schemas have a reference number or a GUID for the various i= ndicators they share.=A0 If we are extending to embed other schemas that in= clude such reference or GUID identifiers, do we want to add an attribute to= the various elements in IODEF that could be indicators?=A0 Is this enough = to make the connections or is something else else needed?=A0 We could add s= omething like an Indicator_ID in RFC5070-bis which would then correlate to = the reference or GUID identifiers. Then the other question was on how to include indicators that are not in th= e base schema that may be related or have language with "and" "or" to speci= fy the relationships.=A0 In some cases, you will want to group these indict= ors in one extension point, where they may fit logically in multiple places= if the relationships did not need to be shown in the data format.=A0 If we= have cases like this where you need more complex representations, should w= e use one extension point via the SCI draft off of the EventData class Addi= tionalData extension point?=A0 Opinions are needed here....=20 A few people have mentioned wanting to include some commonly shared indicto= rs into the base IODEF document.=A0 We could have a catch-all class that do= es this and has an extension point off of it in EventData or we could conti= nue to group items in logical places as is done now in IODEF and then have = the extension point for combined indicators via SCI.=A0 I think I like the = latter approach. Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. Henry A= dams & BIE [chatlga2000@yahoo.com] Sent: Saturday, January 26, 2013 3:05 AM To: mile@ietf.org Cc: C. Henry Adams Subject: Re: [mile] IOCs Greetings Everyone, Take mentioned two types of indicators based on the : ---------------------------------------------------------------------------= --------------------------- 1) If the indicators are something like an XML-based alert/warning of information leakage, it could be an event that are conveyed in the SCI's EventReport class, IMHO. 2) If the indicators are something like an non-XML ones, I guess it could b= e conveyed without using SCI draft. For instance, we could use Impact class of the base IODEF to convey the indicators. We could for instance extend the list of indicators of the Impact class, if needed. ---------------------------------------------------------------------------= --------------------------- In doing so he pointed out the "Impact Class" Whereas, Kathleen stated, ---------------------------------------------------------------------------= -------------------------- For the discussion below, I was thinking more of combined set with relation= ships that may be included in a single extension point, so that's why I was= thinking about the EventData class, but there may be better locations or a= specific area within the EventData. Paul Stoecker had suggested a "Detection" class as a consideration. ---------------------------------------------------------------------------= ------------------------- Kathleen thoughts related yet still with other indicators and the EventData= Class. Is there a possible way to create a new XML class which encompass combining= the EventData, Detection and base IODEF classes to simplify this issue? C. Henry Adams chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com The information contained herein is for the exclusive use of the original r= ecipient. This information is granted for limited distribution within the r= ecipient's place of business for planning purposes only. Further disseminat= ion, whether private or public is prohibited. ---36511695-1532438899-1359242229=:91664 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Greetings Kathleen,

Your logic stimula= tes my visionary brain because I'm amazed at the many avenues you review wi= th this approach at once.  However,  could you share a few advant= ages and disadvantages to the latter?

------------------------------= ---------------------------------------------------------------------------= -----------------
"we could continue to group items in logical places as= is done now in =0AIODEF and then have the extension point for combined ind= icators via SCI."

--------------------------------------------------= -----------------------------------------------------------------------
=
You pointed out what you consider to be logical places, but if I wanted= to protect information from parties capable of ascertaining it from your l= ogical places, perhaps we should also consider to a degree what appears to = be illogical in brilliant minds in some instances.



C. Henry = Adams
=0Achatlga2000@yahoo.com (Direct Email)
=0Achenryadams@biemedia= group.com
=0A
=0AThe information contained herein is for the exclusiv= e use of the original recipient. This information is granted for limited di= stribution within the recipient's place of business for planning purposes o= nly. Further dissemination, whether private or public is prohibited.
--- On Sat, 1/26/13, Moriarty, Kathleen <kathleen.moriarty@emc.co= m> wrote:

From: Moriarty, Kathle= en <kathleen.moriarty@emc.com>
Subject: RE: [mile] IOCs
To: "C.= Henry Adams & BIE" <chatlga2000@yahoo.com>, "mile@ietf.org" <= mile@ietf.org>
Date: Saturday, January 26, 2013, 10:13 AM

Hello C. Henry & others,

Thanks for taking = a look at this.  We have a few considerations in this email thread I w= ould like to hear thoughts on (and there may be more once RFC5070-bis is ac= tively edited).

The AdditionalData class and the RecordItem class both all= ow for non-XML extensions.  Where you place the extensions should be s= pecific to the logical grouping of the parent elements so you can understan= d more about the included data in most cases. 

The Impact clas= s can be used to provide context information on the included data of the re= port and also can include a confidence rating on the report as a whole.&nbs= p; Extensions related to impact would be one level higher (at the moment) i= n the Assessment class using the AdditionalData extension point. 
=
Take asked about including vulnerability information, I would think tha= t would fit under the Vulnerability extension point of the SCI draft in the= Method class.  He did ask about non-XML.  RecordItem or Addition= alData do allow for non-XML extension points, we could either have the SCI = draft handle these as well or have the extensions that are non-XML come directly off the AdditionalData or RecordItem classes according to wh= at makes sense from a logical standpoint.

As for my question, it was= two-fold.

Indicator based schemas have a reference number or a GUID= for the various indicators they share.  If we are extending to embed = other schemas that include such reference or GUID identifiers, do we want t= o add an attribute to the various elements in IODEF that could be indicator= s?  Is this enough to make the connections or is something else else n= eeded?  We could add something like an Indicator_ID in RFC5070-bis whi= ch would then correlate to the reference or GUID identifiers.

Then t= he other question was on how to include indicators that are not in the base= schema that may be related or have language with "and" "or" to specify the= relationships.  In some cases, you will want to group these indictors= in one extension point, where they may fit logically in multiple places if the relationships did not need to be shown in the data format.&n= bsp; If we have cases like this where you need more complex representations= , should we use one extension point via the SCI draft off of the EventData = class AdditionalData extension point?  Opinions are needed here....
A few people have mentioned wanting to include some commonly shared i= ndictors into the base IODEF document.  We could have a catch-all clas= s that does this and has an extension point off of it in EventData or we co= uld continue to group items in logical places as is done now in IODEF and t= hen have the extension point for combined indicators via SCI.  I think= I like the latter approach.

Thank you,
Kathleen
_____________= ___________________________
From: mile-bounces@ietf.org= [mile-bounces@ietf.org]= On Behalf Of C. Henry Adams & BIE [chatlga2000@yahoo.= com]
Sent: Saturday, January 26, 2013 3:05 AM
To: mile@ietf.org<= /a>
Cc: C. Henry Adams
Subject: Re: [mile] IOCs

Greetings Ever= yone,

Take mentioned two types of indicators based on the :
-----= ---------------------------------------------------------------------------= ----------------------
1) If the indicators are something like an XML-ba= sed alert/warning of
information leakage, it could be an event that are = conveyed in the SCI's
EventReport class, IMHO.

2) If the indicato= rs are something like an non-XML ones, I guess it could be
conveyed with= out using SCI draft.
For instance, we could use Impact class of the base= IODEF to convey the
indicators.
We could for instance extend the list of indi= cators of the Impact class, if
needed.
------------------------------= ------------------------------------------------------------------------
In doing so he pointed out the "Impact Class"

Whereas, Kathleen= stated,

-----------------------------------------------------------= ------------------------------------------
For the discussion below, I w= as thinking more of combined set with relationships that may be included in= a single extension point, so that's why I was thinking about the EventData= class, but there may be better locations or a specific area within the Eve= ntData.

Paul Stoecker had suggested a "Detection" class as a conside= ration.
----------------------------------------------------------------= ------------------------------------

Kathleen thoughts related yet s= till with other indicators and the EventData Class.

Is there a possible way to create a new XML class which encompass combining the Eve= ntData, Detection and base IODEF classes to simplify this issue?

C. Henry Adams
chatlga2000@yahoo.com (Direct Email= )
chenryadams@biemediagroup.com
=

The information contained herein is for the exclusive use of the or= iginal recipient. This information is granted for limited distribution with= in the recipient's place of business for planning purposes only. Further di= ssemination, whether private or public is prohibited.
---36511695-1532438899-1359242229=:91664-- From Paul.Stoecker@rsa.com Sun Jan 27 17:53:06 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DB921F84DE for ; Sun, 27 Jan 2013 17:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAiHAu1lyTz8 for ; Sun, 27 Jan 2013 17:53:05 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id AD66721F8809 for ; Sun, 27 Jan 2013 17:53:05 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0S1r5M1025507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 27 Jan 2013 20:53:05 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Sun, 27 Jan 2013 20:53:01 -0500 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0S1r04i010209 for ; Sun, 27 Jan 2013 20:53:00 -0500 Received: from mx33a.corp.emc.com ([169.254.1.154]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Sun, 27 Jan 2013 20:53:00 -0500 From: "Stoecker, Paul" To: "mile@ietf.org" Date: Sun, 27 Jan 2013 20:52:58 -0500 Thread-Topic: [mile] IOCs Thread-Index: Ac38+jNHDwnvgc7QTPq2mKQUzLHGYA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jan 2013 01:53:06 -0000 I would like to look at this from a slightly different perspective=8Alet's say I get an XML document that tells me about an incident. This document has source IP and destination IP that is being shared. However, what I don't know is which IP address is my indicator and which is just a contextual piece of information. This means that my detection product isn't going to know which one to use either, because there is nothing to tell me which IP is the one, even if the roles are set it still might not be enough to tell my system which one I should use as the indicator. If we had something like indicator_id as an attribute, it would allow us to easily identify indicators from contextual data. I do admit to being biased as I have spent much of my career working on the monitoring and detection side of these things, so I am just thinking of ways to make it very clear what the indicators are in the XML document and the other data that may be important as I investigate activity that I have detected off of those indicators. I did suggest the detection class, but I think we may get more flexibility with the indicator_uid. One thing that I haven't considered is the UID portion of this=8Ahow do we use that UID? How is the UID created? Are there standards for UIDs? Regards, Paul Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com On 1/25/13 2:57 PM, "Moriarty, Kathleen" wrote: >Hi Take & all, > >Thank you for the detailed response and sorry about the delay in my >response! > >I like your examples and agree, there are a number of places where SCI >already has the placeholders to add indicators that are not covered in >the base model. Some other examples may include specific fields of email >messages or if we want to extend using something that would let us >express a combination of indicators from higher level analysis tools >(network, malware, host-based, etc). For the discussion below, I was >thinking more of combined set with relationships that may be included in >a single extension point, so that's why I was thinking about the >EventData class, but there may be better locations or a specific area >within the EventData. Paul Stoecker had suggested a "Detection" class as >a consideration. > >We would need a way to connect the indicators in the base IODEF to the >indicators included in other schemas. Someone had suggested the use of >an attribute on IODEF indicators, where we could include a unique ID or >reference number - maybe call it indicator_ID or something similar (this >would have to be in the RFC5070-bis update if agreed). We may want this >on IODEF included IPs or other elements. It could correlate then with >GUID or reference IDs used in other indicator schemas that include IOCs >not in the base IODEF schema. > >Any opinions on an Indicator_ID attribute (or some other name) and the >best extension point for combined sets of indicators (AdditionalData off >of EventData (change just in SCI) or a "Detection" class in the EventData >class (change in RFC5070-bis and SCI for this option))? > >Thanks, >Kathleen > >-----Original Message----- >From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >Sent: Friday, January 11, 2013 3:50 AM >To: Moriarty, Kathleen; mile@ietf.org >Subject: RE: [mile] IOCs > >Hi Kathleen and all, > >Thank you very much for the comments. >I agree that we should consider indicators of compromise that are not >included in the base IODEF schema. >At the same time, perhaps we could clarify what would be these >indicators... > >If the indicators are something like an XML-based alert/warning of >information leakage, it could be an event that are conveyed in the SCI's >EventReport class, IMHO. > >If the indicators are something like an non-XML ones, I guess it could be >conveyed without using SCI draft. >For instance, we could use Impact class of the base IODEF to convey the >indicators. >We could for instance extend the list of indicators of the Impact class, >if >needed. > >If the indicators are something like the result of penetration test, or >indicators of exposed vulnerabilities, I guess neither SCI classes nor >basic >IODEF classes have right place to fit them in at this moment. > >Could we elaborate what would be these indicators? >I hope I am not missing the point. > >Kind regards, >Take > > > >From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >Moriarty, Kathleen >Sent: Thursday, January 10, 2013 7:09 AM >To: mile@ietf.org >Subject: [mile] IOCs > >Hi Take, et. al, >=20 >In looking at SCI, I am not sure where you might include indicators of >compromise that are not included in the base IODEF schema and would like >to >know what others think. >=20 >To me, the logical place would be directly in the EventData class using >the >AdditionalData extension class, maybe using another SCI extension class >called Detection. >=20 >Is there a place where these would fit already that I am missing or do we >need another container? >=20 >Thank you! >Kathleen >=20 > > >_______________________________________________ >mile mailing list >mile@ietf.org >https://www.ietf.org/mailman/listinfo/mile > From chatlga2000@yahoo.com Mon Jan 28 16:39:20 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197DF21E8049 for ; Mon, 28 Jan 2013 16:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.69 X-Spam-Level: ** X-Spam-Status: No, score=2.69 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juVMxWs4nWV0 for ; Mon, 28 Jan 2013 16:39:18 -0800 (PST) Received: from nm6-vm0.bullet.mail.ne1.yahoo.com (nm6-vm0.bullet.mail.ne1.yahoo.com [98.138.91.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8840B21E8042 for ; Mon, 28 Jan 2013 16:39:18 -0800 (PST) Received: from [98.138.90.57] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jan 2013 00:39:18 -0000 Received: from [98.138.226.162] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jan 2013 00:39:18 -0000 Received: from [127.0.0.1] by omp1063.mail.ne1.yahoo.com with NNFMP; 29 Jan 2013 00:39:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 16515.58870.bm@omp1063.mail.ne1.yahoo.com Received: (qmail 10651 invoked by uid 60001); 29 Jan 2013 00:39:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1359419957; bh=QPD8YkPwJxe6Mcg1tdbMz8CgAJhwPPEnMCzPlaSMuuc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kL8dGyqEVGpDhnIbM6UE/CKet0ZYy3RTw3QmtjFYoKge8Q4YDe0jId4nnzj4nJ9kWMP6oZTRrVJKWKn6ZGQGEGGcaBExdJQf4Vpm0mHKjRgQKGwqwQOkFeEkme3fDsxoMzAhxygD8UDRBXFKwh0xnPf5F+jKVVQAimmOCXBz85g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=UXVZSNRs0ry+YhQaap0c5MHku8XAtGHHi77eWhMTou+98J6s1KN/PbdAdW39Hu1R5ctL0pQu8xtZQIc9krVl7yVcQyl3FEtNMkRftPrVmjEhRO09JvWR9iEaMhHx0++bCSHVOqr009XgrJikxktg2pyjwsQ5PnCppVfi3s3j1pg= ; X-YMail-OSG: fJPlsAEVM1kUEMStpuUOWz.KQdQKxviw.fOEor6L_FtxSyI O.NqYgab1Yf9KAKE.5rN1lPPrOlgjYPGSa1dM_SdmqddQNURn4.RbEW.rbIp 7MsNuROJ5fuJJ1syQMSRWNhBF4jiGTnC_Fh8nqaNgGePy_KjgOvKWHkVJr_9 s5R1w5M05GlDE9hxDhuX_OFmz7BXJ_GhrdVy9Rs4m.CwbO2MFVRd9xS4hDg7 Lnw889eyA5sDOEvn02iTp7p5R5X2TjAdOX2geXdpZIoeYmpCQ2zbmGFhMVi0 zTs_CPeZmGwC5HmdHdVSFKCietGKKokfccO86f9Fv5RpKtlioQGW6CVH0oBk 6eEMBxvPFQvU5P1IzSJwwp4YT2eQXA2K..CiAzggZRjnpJDWnWl0CJHXmibw L0XgiVyJmt7JCGz38R9LgnQuH0Jf.rMF_Q5DbLPCvf0fYsTaPZXaObUGeWpt S1k8ZlsjMdbsPf8vv4SiXTjnh7QgpNgvx__rJj3ezkh_gNhYGCu.82jA9pbZ GDHVwKBEx3y8USMHCzRfQodOYvel.RcepvwbK0WTJ.6x5lx2f1Nj_1df65A2 PfZ_EsDf6hm2XSmrUHJxPCYYM.uOT4jZQecTy7Mj8Ayq.EWvIZqewtfzsyjE UrKBk0g8kd1hQB4QwmOdfMhlH6pIHcFQQ63iA.Nyw45Yo52DH4DNCbdFyiPL 6 Received: from [71.22.243.36] by web121606.mail.ne1.yahoo.com via HTTP; Mon, 28 Jan 2013 16:39:17 PST X-Rocket-MIMEInfo: 001.001, U2VyaWFsaXphdGlvbiBvZiBhIHBhcnRpY3VsYXIgTGlzdHMgb2YgWE1MIENsYXNzZXMgaW4gYSB1bmlxdWUgd2F5IHdhcyBjbG9zZWx5IHJlbGF0ZWQgdG8gd2hhdCBJIGF0dGVtcHRlZCB0byBleHByZXNzIHdoZW4gSSBzdGF0ZWQsICJjb25zaWRlciB0byBhIGRlZ3JlZSB3aGF0IGFwcGVhcnMgdG8gYmUgaWxsb2dpY2FsIGluIGJyaWxsaWFudCBtaW5kcyBpbiBzb21lIGluc3RhbmNlcy4iDQoNCkhvd2V2ZXIsIEkgc2VlIERyLiBTdG9lY2tlcidzIHBvaW50IGEgbGl0dGxlIGNsZWFyZXIuwqAgSG93ZXZlciwBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.131.499 Message-ID: <1359419957.97199.YahooMailClassic@web121606.mail.ne1.yahoo.com> Date: Mon, 28 Jan 2013 16:39:17 -0800 (PST) From: "C. Henry Adams & BIE" To: "C. Henry Adams & BIE" In-Reply-To: <1359242229.91664.YahooMailClassic@web121604.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458340343-31112976-1359419957=:97199" Cc: MILE IETF Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jan 2013 00:39:20 -0000 --1458340343-31112976-1359419957=:97199 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Serialization of a particular Lists of XML Classes in a unique way was clos= ely related to what I attempted to express when I stated, "consider to a de= gree what appears to be illogical in brilliant minds in some instances." However, I see Dr. Stoecker's point a little clearer.=C2=A0 However, it wou= ld be nice if the UID was in some way disguised from those who study this S= ecurity Art Form in a negative way. C. Henry Adams =0Achatlga2000@yahoo.com (Direct Email) =0Achenryadams@biemediagroup.com =0A =0A =0AThe information contained herein is for the exclusive use of the origina= l recipient. This information is granted for limited distribution within th= e recipient's place of business for planning purposes only. Further dissemi= nation, whether private or public is prohibited. Re: [mile] IOCs=0A =09Sunday, January 27, 2013 8:52 PM=0A =09= =0A =0A =0A From: =0A "Stoecker= , Paul" =0A =09=0A =09=0A = =09=0A =09To: =0A =09"mile@ietf.org" I = would like to look at this from a slightly different perspective=C5=A0let's say I get an XML document that tells me about an incident.=C2=A0 This docum= ent has source IP and destination IP that is being shared.=C2=A0 However, what = I don't know is which IP address is my indicator and which is just a contextual piece of information.=C2=A0 This means that my detection product isn't going to know which one to use either, because there is nothing to tell me which IP is the one, even if the roles are set it still might not be enough to tell my system which one I should use as the indicator. If we had something like indicator_id as an attribute, it would allow us to easily identify indicators from contextual data.=C2=A0 I do admit to bei= ng biased as I have spent much of my career working on the monitoring and detection side of these things, so I am just thinking of ways to make it very clear what the indicators are in the XML document and the other data that may be important as I investigate activity that I have detected off of those indicators. I did suggest the detection class, but I think we may get more flexibility with the indicator_uid.=C2=A0 One thing that I haven't considered is the UI= D portion of this=C5=A0how do we use that UID?=C2=A0 How is the UID created?= =C2=A0 Are there standards for UIDs? Regards, Paul Paul W. Stoecker, Ph.D. SMC Lead Content Architect RSA, The Security Division of EMC cell: 302.379.3375 | e: paul.stoecker@rsa.com --- On Sat, 1/26/13, C. Henry Adams & BIE wrote: From: C. Henry Adams & BIE Subject: RE: [mile] IOCs To: "KathleenMoriarty" Cc: mile@ietf.org Date: Saturday, January 26, 2013, 6:17 PM Greetings Kathleen, Your logic stimulates my visionary brain because I'm amazed at the many ave= nues you review with this approach at once.=C2=A0 However,=C2=A0 could you = share a few advantages and disadvantages to the latter? ---------------------------------------------------------------------------= ----------------------------------------------- "we could continue to group items in logical places as is done now in =0AIO= DEF and then have the extension point for combined indicators via SCI." ---------------------------------------------------------------------------= ---------------------------------------------- You pointed out what you consider to be logical places, but if I wanted to = protect information from parties capable of ascertaining it from your logic= al places, perhaps we should also consider to a degree what appears to be i= llogical in brilliant minds in some instances. C. Henry Adams =0Achatlga2000@yahoo.com (Direct Email) =0Achenryadams@biemediagroup.com =0A =0AThe information contained herein is for the exclusive use of the origina= l recipient. This information is granted for limited distribution within th= e recipient's place of business for planning purposes only. Further dissemi= nation, whether private or public is prohibited. --- On Sat, 1/26/13, Moriarty, Kathleen wrote: From: Moriarty, Kathleen Subject: RE: [mile] IOCs To: "C. Henry Adams & BIE" , "mile@ietf.org" Date: Saturday, January 26, 2013, 10:13 AM Hello C. Henry & others, Thanks for taking a look at this.=C2=A0 We have a few considerations in thi= s email thread I would like to hear thoughts on (and there may be more once= RFC5070-bis is actively=0A edited). The AdditionalData class and the RecordItem class both allow for non-XML ex= tensions.=C2=A0 Where you place the extensions should be specific to the lo= gical grouping of the parent elements so you can understand more about the = included data in most cases.=C2=A0=20 The Impact class can be used to provide context information on the included= data of the report and also can include a confidence rating on the report = as a whole.=C2=A0 Extensions related to impact would be one level higher (a= t the moment) in the Assessment class using the AdditionalData extension po= int.=C2=A0=20 Take asked about including vulnerability information, I would think that wo= uld fit under the Vulnerability extension point of the SCI draft in the Met= hod class.=C2=A0 He did ask about non-XML.=C2=A0 RecordItem or AdditionalDa= ta do allow for non-XML extension points, we could either have the SCI draf= t handle these as well or have the extensions that are non-XML=0A come dire= ctly off the AdditionalData or RecordItem classes according to what makes s= ense from a logical standpoint. As for my question, it was two-fold. Indicator based schemas have a reference number or a GUID for the various i= ndicators they share.=C2=A0 If we are extending to embed other schemas that= include such reference or GUID identifiers, do we want to add an attribute= to the various elements in IODEF that could be indicators?=C2=A0 Is this e= nough to make the connections or is something else else needed?=C2=A0 We co= uld add something like an Indicator_ID in RFC5070-bis which would then corr= elate to the reference or GUID identifiers. Then the other question was on how to include indicators that are not in th= e base schema that may be related or have language with "and" "or" to speci= fy the relationships.=C2=A0 In some cases, you will want to group these ind= ictors in one extension point, where they may fit logically in multiple=0A = places if the relationships did not need to be shown in the data format.=C2= =A0 If we have cases like this where you need more complex representations,= should we use one extension point via the SCI draft off of the EventData c= lass AdditionalData extension point?=C2=A0 Opinions are needed here....=20 A few people have mentioned wanting to include some commonly shared indicto= rs into the base IODEF document.=C2=A0 We could have a catch-all class that= does this and has an extension point off of it in EventData or we could co= ntinue to group items in logical places as is done now in IODEF and then ha= ve the extension point for combined indicators via SCI.=C2=A0 I think I lik= e the latter approach. Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. Henry A= dams & BIE [chatlga2000@yahoo.com] Sent: Saturday, January 26, 2013 3:05 AM To: mile@ietf.org Cc: C. Henry Adams Subject: Re: [mile] IOCs Greetings Everyone, Take mentioned two types of indicators based on the : ---------------------------------------------------------------------------= --------------------------- 1) If the indicators are something like an XML-based alert/warning of information leakage, it could be an event that are conveyed in the SCI's EventReport class, IMHO. 2) If the indicators are something like an non-XML ones, I guess it could b= e conveyed without using SCI draft. For instance, we could use Impact class of the base IODEF to=0A convey the indicators. We could for instance extend the list of indicators of the Impact class, if needed. ---------------------------------------------------------------------------= --------------------------- In doing so he pointed out the "Impact Class" Whereas, Kathleen stated, ---------------------------------------------------------------------------= -------------------------- For the discussion below, I was thinking more of combined set with relation= ships that may be included in a single extension point, so that's why I was= thinking about the EventData class, but there may be better locations or a= specific area within the EventData. Paul Stoecker had suggested a "Detection" class as a consideration. ---------------------------------------------------------------------------= ------------------------- Kathleen thoughts related yet still with other indicators and the EventData= Class. Is there=0A a possible way to create a new XML class which encompass combin= ing the EventData, Detection and base IODEF classes to simplify this issue? C. Henry Adams chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com The information contained herein is for the exclusive use of the original r= ecipient. This information is granted for limited distribution within the r= ecipient's place of business for planning purposes only. Further disseminat= ion, whether private or public is prohibited. --1458340343-31112976-1359419957=:97199 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Serialization of a particular Lists of XML Cl= asses in a unique way was closely related to what I attempted to express wh= en I stated, "consider to a degree what appears to be illogical in brillian= t minds in some instances."

However, I see Dr. Stoecker's point a little clearer.  However, it would be nice if the = UID was in some way disguised from those who study this Security Art Form i= n a negative way.

C. Henry Adams
=0Achatlga2000@yahoo.com = (Direct Email)
=0Achenryadams@biemediagroup.com
=0A
=0A
=0AThe = information contained herein is for the exclusive use of the original recip= ient. This information is granted for limited distribution within the recip= ient's place of business for planning purposes only. Further dissemination,= whether private or public is prohibited.

<= div class=3D"subjectbar">

Re: [mile] IO= Cs

=0A =09
Sun= day, January 27, 2013 8:52 PM
=0A =09
=0A =
=0A
=0A =
From:
=0A
<= div class=3D"abook">"Stoecker, Paul" <Paul.Stoecke= r@rsa.com>
=0A =09
=0A =09=0A = =09
=0A =09
To: =
=0A =09
"mile@ietf.org" <mile@ietf.or= g>
I would like to look at this from a slightly d= ifferent perspective=C5=A0let's
say I get an XML document that tells me = about an incident.  This document
has source IP and destination IP = that is being shared.  However, what I
don't know is which IP addre= ss is my indicator and which is just a
contextual piece of information.&= nbsp; This means that my detection product
isn't going to know which one= to use either, because there is nothing to
tell me which IP is the one,= even if the roles are set it still might not
be enough to tell my syste= m which one I should use as the indicator.

If we had something like = indicator_id as an attribute, it would allow us
to easily identify indic= ators from contextual data.  I do admit to being
biased as I have s= pent much of my career working on the monitoring and
detection side of t= hese things, so I am just thinking of ways to make it
very clear what the in= dicators are in the XML document and the other data
that may be importan= t as I investigate activity that I have detected off
of those indicators= .


I did suggest the detection class, but I think we may get more= flexibility
with the indicator_uid.  One thing that I haven't cons= idered is the UID
portion of this=C5=A0how do we use that UID?  How= is the UID created?  Are
there standards for UIDs?

Regards,=

Paul



Paul W. Stoecker, Ph.D.
SMC Lead Content Arc= hitect
RSA, The Security Division of EMC
cell: 302.379.3375 | e: paul.stoecker@rsa.com

--- On Sat, 1/26/13, C. Henry Adams = & BIE <chatlga2000@yahoo.com> wrote:

From: C. Henry Adams & BIE <chatlga2000@yah= oo.com>
Subject: RE: [mile] IOCs
To: "KathleenMoriarty" <kathle= en.moriarty@emc.com>
Cc: mile@ietf.org
Date: Saturday, January 26,= 2013, 6:17 PM

Greetings Kathleen,

Your logic stimulates my visionary brai= n because I'm amazed at the many avenues you review with this approach at o= nce.  However,  could you share a few advantages and disadvantage= s to the latter?

---------------------------------------------------= -----------------------------------------------------------------------
= "we could continue to group items in logical places as is done now in =0AIO= DEF and then have the extension point for combined indicators via SCI."
=
-----------------------------------------------------------------------= --------------------------------------------------

You pointed out w= hat you consider to be logical places, but if I wanted to protect informati= on from parties capable of ascertaining it from your logical places, perhap= s we should also consider to a degree what appears to be illogical in brill= iant minds in some instances.



C. Henry Adams
=0Achatlga20= 00@yahoo.com (Direct Email)
=0Achenryadams@biemediagroup.com
=0A
= =0AThe information contained herein is for the exclusive use of the origina= l recipient. This information is granted for limited distribution within th= e recipient's place of business for planning purposes only. Further dissemi= nation, whether private or public is prohibited.

--- On Sat, 1/26= /13, Moriarty, Kathleen <kathleen.moriarty@emc.com> wrote:=

From: Moriarty, Kathleen <kathleen.moriarty@= emc.com>
Subject: RE: [mile] IOCs
To: "C. Henry Adams & BIE" &= lt;chatlga2000@yahoo.com>, "mile@ietf.org" <mile@ietf.org>
Date= : Saturday, January 26, 2013, 10:13 AM

Hello C. Henry & others,

Thanks for taking a look at thi= s.  We have a few considerations in this email thread I would like to = hear thoughts on (and there may be more once RFC5070-bis is actively=0A edi= ted).

The AdditionalData class and the RecordItem class both allow f= or non-XML extensions.  Where you place the extensions should be speci= fic to the logical grouping of the parent elements so you can understand mo= re about the included data in most cases. 

The Impact class ca= n be used to provide context information on the included data of the report= and also can include a confidence rating on the report as a whole.  E= xtensions related to impact would be one level higher (at the moment) in th= e Assessment class using the AdditionalData extension point. 

= Take asked about including vulnerability information, I would think that wo= uld fit under the Vulnerability extension point of the SCI draft in the Met= hod class.  He did ask about non-XML.  RecordItem or AdditionalDa= ta do allow for non-XML extension points, we could either have the SCI draf= t handle these as well or have the extensions that are non-XML=0A come dire= ctly off the AdditionalData or RecordItem classes according to what makes s= ense from a logical standpoint.

As for my question, it was two-fold.=

Indicator based schemas have a reference number or a GUID for the v= arious indicators they share.  If we are extending to embed other sche= mas that include such reference or GUID identifiers, do we want to add an a= ttribute to the various elements in IODEF that could be indicators?  I= s this enough to make the connections or is something else else needed?&nbs= p; We could add something like an Indicator_ID in RFC5070-bis which would t= hen correlate to the reference or GUID identifiers.

Then the other q= uestion was on how to include indicators that are not in the base schema th= at may be related or have language with "and" "or" to specify the relations= hips.  In some cases, you will want to group these indictors in one ex= tension point, where they may fit logically in multiple=0A places if the re= lationships did not need to be shown in the data format.  If we have c= ases like this where you need more complex representations, should we use o= ne extension point via the SCI draft off of the EventData class AdditionalD= ata extension point?  Opinions are needed here....

A few peopl= e have mentioned wanting to include some commonly shared indictors into the= base IODEF document.  We could have a catch-all class that does this = and has an extension point off of it in EventData or we could continue to g= roup items in logical places as is done now in IODEF and then have the exte= nsion point for combined indicators via SCI.  I think I like the latte= r approach.

Thank you,
Kathleen
______________________________= __________
From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. Henry Adams & = BIE [chatlga2000@yahoo.com]
Sent: Saturday, January 26,= 2013 3:05 AM
To: mile@ietf.org
Cc: C. Henry = Adams
Subject: Re: [mile] IOCs

Greetings Everyone,

Take me= ntioned two types of indicators based on the :
-------------------------= ---------------------------------------------------------------------------= --
1) If the indicators are something like an XML-based alert/warning of=
information leakage, it could be an event that are conveyed in the SCI'= s
EventReport class, IMHO.

2) If the indicators are something lik= e an non-XML ones, I guess it could be
conveyed without using SCI draft.=
For instance, we could use Impact class of the base IODEF to=0A convey = the
indicators.
We could for instance extend the list of indicators o= f the Impact class, if
needed.
--------------------------------------= ----------------------------------------------------------------

In = doing so he pointed out the "Impact Class"

Whereas, Kathleen stated,=

-------------------------------------------------------------------= ----------------------------------
For the discussion below, I was think= ing more of combined set with relationships that may be included in a singl= e extension point, so that's why I was thinking about the EventData class, = but there may be better locations or a specific area within the EventData.<= br>
Paul Stoecker had suggested a "Detection" class as a consideration.<= br>------------------------------------------------------------------------= ----------------------------

Kathleen thoughts related yet still wit= h other indicators and the EventData Class.

Is there=0A a possible w= ay to create a new XML class which encompass combining the EventData, Detec= tion and base IODEF classes to simplify this issue?


C. Henry Ada= ms
chatlga2000@yahoo.com (Direct Email)
chenryadams@biemediagroup.com


The information= contained herein is for the exclusive use of the original recipient. This = information is granted for limited distribution within the recipient's plac= e of business for planning purposes only. Further dissemination, whether pr= ivate or public is prohibited.
--1458340343-31112976-1359419957=:97199-- From chatlga2000@yahoo.com Mon Jan 28 20:24:59 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD9721E8089 for ; Mon, 28 Jan 2013 20:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.34 X-Spam-Level: *** X-Spam-Status: No, score=3.34 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, FRT_STOCK2=3.988, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LQ7dv0Qm+0B for ; Mon, 28 Jan 2013 20:24:58 -0800 (PST) Received: from nm34-vm0.bullet.mail.ne1.yahoo.com (nm34-vm0.bullet.mail.ne1.yahoo.com [98.138.229.80]) by ietfa.amsl.com (Postfix) with ESMTP id C760221E8083 for ; Mon, 28 Jan 2013 20:24:57 -0800 (PST) Received: from [98.138.90.49] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jan 2013 04:24:57 -0000 Received: from [98.138.87.3] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jan 2013 04:24:57 -0000 Received: from [127.0.0.1] by omp1003.mail.ne1.yahoo.com with NNFMP; 29 Jan 2013 04:24:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 385652.23306.bm@omp1003.mail.ne1.yahoo.com Received: (qmail 21629 invoked by uid 60001); 29 Jan 2013 04:24:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1359433497; bh=j19uEEx8bOs1FSG9WECGQZZKa8aUPW+LRZOqSZJWcac=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=6osEP1qW0neP0r6WXwJ3+65iBT4zPPbb3r4j43D4X4Kt/OybV66HOMm+iAENIhsVs0uRRe6AZJFqHoGLAL3FwVlkleyvtqRbQQpGRCzW4L3ykqduuLF5dRBHqv7ESrZg+jHCcSZShqlzQii39TPUIcQRqezJwph3rJ/MQD7mwMc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=wBFwtrZIVJUnksTYtYCyXhfonYa4eVcyTvqygI/Jw78ZqFC40TJHmPkvBeM/jDAmj3KnkySKVm/uE8mDiQoOxYCft+MbSvdRSofY5cWopwIJfKOjzUT0ei1XAPIBhXzO2cygK3EwkblZSWLLWo97Zjrl+y9IL0X1opoohsva+5o= ; X-YMail-OSG: xHYk8.UVM1l9QV81QAX4CFRebyQJp4eZDcK01nlxDGk5_5K q8vO0OEjj51T12OygraNTGqQ2lnn8Hq6xSqe9PhKVMOexLi25iykitgJc2RP WCs7Zi4rnWHm5CVXlzaH4mbC9MSDjFLnmJKokLSLORw7t_WIHNiDA0Vo.AgE XsH1dMPJKyGoEOxl5eeyZ7rwyLrWXRmOOrwNvAIEj9J2Y65jwXacdZphwr_u .jeclYfz5ACBi.ym.5uEwInwk.EwZPaXTzKkpY5nSNiuqecVEn6opp1jNL_c 2Un7vje_rWH2taQc20Cr_CyY3APIo9tFR4Xpmdm5.mNlpfDx64_r_n3Ye181 wxjcGgAyfbCGRJicANveQ76IqeGvdXwMDrmP.Q5nz.z_Lqop4y8PI4zUb_oG 9b.0b1aZ0JFIOs.pUO2dcFsdTxHbH3m___xwOjCGFV_Ci76JOrdwlVdTAWkR WI8VsdmsA2v1nbXCdDGSw4SOx50PIHNxhqxQBH1mGg5VYSq_KyGEHWL9Nlfa 0JDG2ukuQaf1xc1zb2UywErqyPCx1wo8CVWR_KOddChz2ofaN89Ao2fAdIt_ zi4K2vICGPX9Ir9AmMlzwq4s95sRd39IhJw-- Received: from [71.22.243.36] by web121604.mail.ne1.yahoo.com via HTTP; Mon, 28 Jan 2013 20:24:57 PST X-Rocket-MIMEInfo: 001.001, VGVtcG9yYWwgRGVwZW5kZW5jeSBzb3VuZHMgaW50ZXJlc3RpbmcuwqAgSSByZW1lbWJlciB3aGVuIEkgZmlyc3QgcmFuIGFjcm9zcyB0aGlzIHBhcnRpY3VsYXIgY3JhZnQsIGFuIGV4cGVyaWVuY2VkIGNvbGxlYWd1ZSBhc2tlZCBtZSBhIHBlY3VsaWFyIHF1ZXN0aW9uLsKgIEhlIHNhaWQsICIgSG93IGRvIHlvdSBzdG9wIHNvbWVvbmUgZnJvbSB0cmFja2luZyB0aGUgSVAgQWRkcmVzcyB0byB5b3VyIGNvbXB1dGVyPyLCoCANCg0KSSByZXBsaWVkLCAiSSBkb24ndCBrbm93LCBob3c_IiANCg0KVGhlbiBoZSABMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.131.499 Message-ID: <1359433497.20429.YahooMailClassic@web121604.mail.ne1.yahoo.com> Date: Mon, 28 Jan 2013 20:24:57 -0800 (PST) From: "C. Henry Adams & BIE" To: MILE IETF In-Reply-To: <71238F9C-AD03-44B9-A065-541351FB4087@bcs.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-36511695-1034663839-1359433497=:20429" Subject: Re: [mile] IOCs X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jan 2013 04:24:59 -0000 ---36511695-1034663839-1359433497=:20429 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Temporal Dependency sounds interesting.=C2=A0 I remember when I first ran a= cross this particular craft, an experienced colleague asked me a peculiar q= uestion.=C2=A0 He said, " How do you stop someone from tracking the IP Addr= ess to your computer?"=C2=A0=20 I replied, "I don't know, how?"=20 Then he said, "Cut the dog-gone thing off=C2=A0 and the modem that it is co= nnected- which is constantly on!"=C2=A0=C2=A0 LOL Here's my point (Hypothetical Situation) :=C2=A0 There is a 1st Responder s= earching a Neighborhood for Survivors which were hit by a Disaster or let's= just say "Live" Terrorist Situation.=C2=A0 He /or She needs to communicati= on back to other Officials that he /or somehow is in Danger.=C2=A0 The devi= ce used to communicate has been captured by the great minds of the enemy.= =C2=A0 It's only a matter of time before they utilize reverse engineering t= o figure out how it functions.=C2=A0 However, their pride comes before a fa= ll when seeking the location of other similar devices to attack.=C2=A0 Why?= Perhaps the less thought of concepts that makes the device function proper= ly, saves the day by disguise or cutting it off (figuratively speaking). Just a visionary thought. C. Henry Adams =0Achenryadams@biemediagroup.com =0Ahttp://biemediagroup.com =0A =0A =0AThe information contained herein is for the exclusive use of the origina= l recipient. This information is granted for limited distribution within th= e recipient's place of business for planning purposes only. Further dissemi= nation, whether private or public is prohibited. --- On Mon, 1/28/13, Dave Misell wrote: From: Dave Misell Subject: Re: [mile] IOCs To: "C. Henry Adams & BIE" Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS SEC a pemanent and temporal key, with a temp= oral Id? Yours Faithfully, Dave Misell MSc CISSP SilentCircle=C2=A0 dsm 07710 380044 david.misell@bcs.org On 29 Jan 2013, at 00:39, C. Henry Adams & BIE wrot= e: > Serialization of a particular Lists of XML Classes in a unique way was cl= osely related to what I attempted to express when I stated, "consider to a = degree what appears to be illogical in brilliant minds in some instances." >=20 > However, I see Dr. Stoecker's point a little clearer.=C2=A0 However, it w= ould be nice if the UID was in some way disguised from those who study this= Security Art Form in a negative way. >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the original= recipient. This information is granted for limited distribution within the= recipient's place of business for planning purposes only. Further dissemin= ation, whether private or public is prohibited. >=20 > Re: [mile] IOCs >=20 > Sunday, January 27, 2013 8:52 PM > From: > "Stoecker, Paul" > To: > "mile@ietf.org" > I would like to look at this from a slightly different perspective=C5=A0l= et's > say I get an XML document that tells me about an incident.=C2=A0 This doc= ument > has source IP and destination IP that is being shared.=C2=A0 However, wha= t I > don't know is which IP address is my indicator and which is just a > contextual piece of information.=C2=A0 This means that my detection produ= ct > isn't going to know which one to use either, because there is nothing to > tell me which IP is the one, even if the roles are set it still might not > be enough to tell my system which one I should use as the indicator. >=20 > If we had something like indicator_id as an attribute, it would allow us > to easily identify indicators from contextual data.=C2=A0 I do admit to b= eing > biased as I have spent much of my career working on the monitoring and > detection side of these things, so I am just thinking of ways to make it > very clear what the indicators are in the XML document and the other data > that may be important as I investigate activity that I have detected off > of those indicators. >=20 >=20 > I did suggest the detection class, but I think we may get more flexibilit= y > with the indicator_uid.=C2=A0 One thing that I haven't considered is the = UID > portion of this=C5=A0how do we use that UID?=C2=A0 How is the UID created= ?=C2=A0 Are > there standards for UIDs? >=20 > Regards, >=20 > Paul >=20 >=20 >=20 > Paul W. Stoecker, Ph.D. > SMC Lead Content Architect > RSA, The Security Division of EMC > cell: 302.379.3375 | e: paul.stoecker@rsa.com >=20 > --- On Sat, 1/26/13, C. Henry Adams & BIE wrote: >=20 > From: C. Henry Adams & BIE > Subject: RE: [mile] IOCs > To: "KathleenMoriarty" > Cc: mile@ietf.org > Date: Saturday, January 26, 2013, 6:17 PM >=20 > Greetings Kathleen, >=20 > Your logic stimulates my visionary brain because I'm amazed at the many a= venues you review with this approach at once.=C2=A0 However,=C2=A0 could yo= u share a few advantages and disadvantages to the latter? >=20 > -------------------------------------------------------------------------= ------------------------------------------------- > "we could continue to group items in logical places as is done now in IOD= EF and then have the extension point for combined indicators via SCI." >=20 > -------------------------------------------------------------------------= ------------------------------------------------ >=20 > You pointed out what you consider to be logical places, but if I wanted t= o protect information from parties capable of ascertaining it from your log= ical places, perhaps we should also consider to a degree what appears to be= illogical in brilliant minds in some instances. >=20 >=20 >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 > The information contained herein is for the exclusive use of the original= recipient. This information is granted for limited distribution within the= recipient's place of business for planning purposes only. Further dissemin= ation, whether private or public is prohibited. >=20 > --- On Sat, 1/26/13, Moriarty, Kathleen wrote= : >=20 > From: Moriarty, Kathleen > Subject: RE: [mile] IOCs > To: "C. Henry Adams & BIE" , "mile@ietf.org" > Date: Saturday, January 26, 2013, 10:13 AM >=20 > Hello C. Henry & others, >=20 > Thanks for taking a look at this.=C2=A0 We have a few considerations in t= his email thread I would like to hear thoughts on (and there may be more on= ce RFC5070-bis is actively edited). >=20 > The AdditionalData class and the RecordItem class both allow for non-XML = extensions.=C2=A0 Where you place the extensions should be specific to the = logical grouping of the parent elements so you can understand more about th= e included data in most cases.=C2=A0=20 >=20 > The Impact class can be used to provide context information on the includ= ed data of the report and also can include a confidence rating on the repor= t as a whole.=C2=A0 Extensions related to impact would be one level higher = (at the moment) in the Assessment class using the AdditionalData extension = point.=C2=A0=20 >=20 > Take asked about including vulnerability information, I would think that = would fit under the Vulnerability extension point of the SCI draft in the M= ethod class.=C2=A0 He did ask about non-XML.=C2=A0 RecordItem or Additional= Data do allow for non-XML extension points, we could either have the SCI dr= aft handle these as well or have the extensions that are non-XML come direc= tly off the AdditionalData or RecordItem classes according to what makes se= nse from a logical standpoint. >=20 > As for my question, it was two-fold. >=20 > Indicator based schemas have a reference number or a GUID for the various= indicators they share.=C2=A0 If we are extending to embed other schemas th= at include such reference or GUID identifiers, do we want to add an attribu= te to the various elements in IODEF that could be indicators?=C2=A0 Is this= enough to make the connections or is something else else needed?=C2=A0 We = could add something like an Indicator_ID in RFC5070-bis which would then co= rrelate to the reference or GUID identifiers. >=20 > Then the other question was on how to include indicators that are not in = the base schema that may be related or have language with "and" "or" to spe= cify the relationships.=C2=A0 In some cases, you will want to group these i= ndictors in one extension point, where they may fit logically in multiple p= laces if the relationships did not need to be shown in the data format.=C2= =A0 If we have cases like this where you need more complex representations,= should we use one extension point via the SCI draft off of the EventData c= lass AdditionalData extension point?=C2=A0 Opinions are needed here....=20 >=20 > A few people have mentioned wanting to include some commonly shared indic= tors into the base IODEF document.=C2=A0 We could have a catch-all class th= at does this and has an extension point off of it in EventData or we could = continue to group items in logical places as is done now in IODEF and then = have the extension point for combined indicators via SCI.=C2=A0 I think I l= ike the latter approach. >=20 > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of C. Henry= Adams & BIE [chatlga2000@yahoo.com] > Sent: Saturday, January 26, 2013 3:05 AM > To: mile@ietf.org > Cc: C. Henry Adams > Subject: Re: [mile] IOCs >=20 > Greetings Everyone, >=20 > Take mentioned two types of indicators based on the : > -------------------------------------------------------------------------= ----------------------------- > 1) If the indicators are something like an XML-based alert/warning of > information leakage, it could be an event that are conveyed in the SCI's > EventReport class, IMHO. >=20 > 2) If the indicators are something like an non-XML ones, I guess it could= be > conveyed without using SCI draft. > For instance, we could use Impact class of the base IODEF to convey the > indicators. > We could for instance extend the list of indicators of the Impact class, = if > needed. > -------------------------------------------------------------------------= ----------------------------- >=20 > In doing so he pointed out the "Impact Class" >=20 > Whereas, Kathleen stated, >=20 > -------------------------------------------------------------------------= ---------------------------- > For the discussion below, I was thinking more of combined set with relati= onships that may be included in a single extension point, so that's why I w= as thinking about the EventData class, but there may be better locations or= a specific area within the EventData. >=20 > Paul Stoecker had suggested a "Detection" class as a consideration. > -------------------------------------------------------------------------= --------------------------- >=20 > Kathleen thoughts related yet still with other indicators and the EventDa= ta Class. >=20 > Is there a possible way to create a new XML class which encompass combini= ng the EventData, Detection and base IODEF classes to simplify this issue? >=20 >=20 > C. Henry Adams > chatlga2000@yahoo.com (Direct Email) > chenryadams@biemediagroup.com >=20 >=20 > The information contained herein is for the exclusive use of the original= recipient. This information is granted for limited distribution within the= recipient's place of business for planning purposes only. Further dissemin= ation, whether private or public is prohibited. > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile ---36511695-1034663839-1359433497=:20429 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= /tr>
Temporal Dependency sounds interesting. = I remember when I first ran across this particular craft, an experienced c= olleague asked me a peculiar question.  He said, " How do you stop som= eone from tracking the IP Address to your computer?" 

I replie= d, "I don't know, how?"

Then he said, "Cut the dog-gone thing off&n= bsp; and the modem that it is connected- which is constantly on!" &nbs= p; LOL

Here's my point (Hypothetical Situation) :  There is a 1= st Responder searching a Neighborhood for Survivors which were hit by a Dis= aster or let's just say "Live" Terrorist Situation.  He /or She needs = to communication back to other Officials that he /or somehow is in Danger.&= nbsp; The device used to communicate has been captured by the great minds o= f the enemy.  It's only a matter of time before they utilize reverse engineering to figure out how it functions.  However, their pride com= es before a fall when seeking the location of other similar devices to atta= ck.  Why? Perhaps the less thought of concepts that makes the device f= unction properly, saves the day by disguise or cutting it off (figuratively= speaking).

Just a visionary thought.

C. Henry Adams
=0Ach= enryadams@biemediagroup.com
=0Ahttp://biemediagroup.com
=0A
=0A=0AThe information contained herein is for the exclusive use of the origin= al recipient. This information is granted for limited distribution within t= he recipient's place of business for planning purposes only. Further dissem= ination, whether private or public is prohibited.

--- On Mon, 1/2= 8/13, Dave Misell <david.misell@bcs.org> wrote:

From: Dave Misell <david.misell@bcs.org>
Sub= ject: Re: [mile] IOCs
To: "C. Henry Adams & BIE" <chatlga2000@yah= oo.com>
Date: Monday, January 28, 2013, 9:25 PM

UID could be mirrored with DNS SEC a pemanent and temporal key, = with a temporal Id?

Yours Faithfully,

Dave Misell MSc CISSPSilentCircle  dsm
07710 380044
david.misell@bcs.org

On 29 Jan 2013, at 00:39, C. Henry Adams & BIE <chatlga2000@yahoo.com> wrote:

> Serialization of a = particular Lists of XML Classes in a unique way was closely related to what= I attempted to express when I stated, "consider to a degree what appears t= o be illogical in brilliant minds in some instances."
>
> Howe= ver, I see Dr. Stoecker's point a little clearer.  However, it would b= e nice if the UID was in some way disguised from those who study this Secur= ity Art Form in a negative way.
>
> C. Henry Adams
> chatlga2000@yahoo.com (Direct Email)
> chenryadams@biemed= iagroup.com
>
>
> The information contained herein = is for the exclusive use of the original recipient. This information is gra= nted for limited distribution within the recipient's place of business for = planning purposes only. Further dissemination, whether private or public is= prohibited.
>
> Re: [mile] IOCs
>
> Sunday, Janu= ary 27, 2013 8:52 PM
> From:
> "Stoecker, Paul" <Paul.Stoecker@rsa.com>
> To:
> "mile@ietf.org" <mile@ietf.org>
> I would like to look at this from a s= lightly different perspective=C5=A0let's
> say I get an XML document = that tells me about an incident.  This document
> has source IP and destination IP = that is being shared.  However, what I
> don't know is which IP = address is my indicator and which is just a
> contextual piece of inf= ormation.  This means that my detection product
> isn't going to= know which one to use either, because there is nothing to
> tell me = which IP is the one, even if the roles are set it still might not
> b= e enough to tell my system which one I should use as the indicator.
>=
> If we had something like indicator_id as an attribute, it would a= llow us
> to easily identify indicators from contextual data.  I= do admit to being
> biased as I have spent much of my career working= on the monitoring and
> detection side of these things, so I am just= thinking of ways to make it
> very clear what the indicators are in = the XML document and the other data
> that may be important as I investigate activity that I have detected off
> of those indicator= s.
>
>
> I did suggest the detection class, but I think= we may get more flexibility
> with the indicator_uid.  One thin= g that I haven't considered is the UID
> portion of this=C5=A0how do = we use that UID?  How is the UID created?  Are
> there stan= dards for UIDs?
>
> Regards,
>
> Paul
> >
>
> Paul W. Stoecker, Ph.D.
> SMC Lead Content Ar= chitect
> RSA, The Security Division of EMC
> cell: 302.379.337= 5 | e: paul.stoecker@rsa.com
>
> --- On= Sat, 1/26/13, C. Henry Adams & BIE <chatlga2000@ya= hoo.com> wrote:
>
> From: C. Henry Adams & BIE <= chatlga2000@yahoo.com>
> Subject: RE: [mile] IO= Cs
> To: "KathleenMoriarty" <kathleen.mor= iarty@emc.com>
> Cc: mile@ietf.org
> Date: Saturda= y, January 26, 2013, 6:17 PM
>
> Greetings Kathleen,
> <= br>> Your logic stimulates my visionary brain because I'm amazed at the = many avenues you review with this approach at once.  However,  co= uld you share a few advantages and disadvantages to the latter?
> > ---------------------------------------------------------------------= -----------------------------------------------------
> "we could con= tinue to group items in logical places as is done now in IODEF and then hav= e the extension point for combined indicators via SCI."
>
> -------= ---------------------------------------------------------------------------= ---------------------------------------
>
> You pointed out wh= at you consider to be logical places, but if I wanted to protect informatio= n from parties capable of ascertaining it from your logical places, perhaps= we should also consider to a degree what appears to be illogical in brilli= ant minds in some instances.
>
>
>
> C. Henry Ad= ams
> chatlga2000@yahoo.com (Direct Email)
&g= t; chenryadams@biemediagroup.com
&g= t;
> The information contained herein is for the exclusive use of th= e original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Furth= er dissemination, whether private or public is prohibited.
>
>= --- On Sat, 1/26/13, Moriarty, Kathleen <kathl= een.moriarty@emc.com> wrote:
>
> From: Moriarty, Kathle= en <kathleen.moriarty@emc.com>
> S= ubject: RE: [mile] IOCs
> To: "C. Henry Adams & BIE" <chatlga2000@yahoo.com>, "mile@ietf.org" <mile@ietf= .org>
> Date: Saturday, January 26, 2013, 10:13 AM
> > Hello C. Henry & others,
>
> Thanks for taking a look at this.  We = have a few considerations in this email thread I would like to hear thought= s on (and there may be more once RFC5070-bis is actively edited).
> <= br>> The AdditionalData class and the RecordItem class both allow for no= n-XML extensions.  Where you place the extensions should be specific t= o the logical grouping of the parent elements so you can understand more ab= out the included data in most cases. 
>
> The Impact cla= ss can be used to provide context information on the included data of the r= eport and also can include a confidence rating on the report as a whole.&nb= sp; Extensions related to impact would be one level higher (at the moment) = in the Assessment class using the AdditionalData extension point.  >
> Take asked about including vulnerability information, I woul= d think that would fit under the Vulnerability extension point of the SCI draft in the Method class.  He did ask about non-XML.  R= ecordItem or AdditionalData do allow for non-XML extension points, we could= either have the SCI draft handle these as well or have the extensions that= are non-XML come directly off the AdditionalData or RecordItem classes acc= ording to what makes sense from a logical standpoint.
>
> As f= or my question, it was two-fold.
>
> Indicator based schemas h= ave a reference number or a GUID for the various indicators they share.&nbs= p; If we are extending to embed other schemas that include such reference o= r GUID identifiers, do we want to add an attribute to the various elements = in IODEF that could be indicators?  Is this enough to make the connect= ions or is something else else needed?  We could add something like an= Indicator_ID in RFC5070-bis which would then correlate to the reference or= GUID identifiers.
>
> Then the other question was on how to include indicators that are not in the base schema that may be rela= ted or have language with "and" "or" to specify the relationships.  In= some cases, you will want to group these indictors in one extension point,= where they may fit logically in multiple places if the relationships did n= ot need to be shown in the data format.  If we have cases like this wh= ere you need more complex representations, should we use one extension poin= t via the SCI draft off of the EventData class AdditionalData extension poi= nt?  Opinions are needed here....
>
> A few people have = mentioned wanting to include some commonly shared indictors into the base I= ODEF document.  We could have a catch-all class that does this and has= an extension point off of it in EventData or we could continue to group it= ems in logical places as is done now in IODEF and then have the extension p= oint for combined indicators via SCI.  I think I like the latter approach.
>
> Thank you,
> Kathleen
> ____= ____________________________________
> From: mile-bo= unces@ietf.org [mile-bounces@ietf.org] On Behalf O= f C. Henry Adams & BIE [chatlga2000@yahoo.com]
= > Sent: Saturday, January 26, 2013 3:05 AM
> To: mile@ietf.org
> Cc: C. Henry Adams
> Subject: Re: [mile] IOCs
>
&= gt; Greetings Everyone,
>
> Take mentioned two types of indica= tors based on the :
> -----------------------------------------------= -------------------------------------------------------
> 1) If the i= ndicators are something like an XML-based alert/warning of
> information leakage, = it could be an event that are conveyed in the SCI's
> EventReport cla= ss, IMHO.
>
> 2) If the indicators are something like an non-X= ML ones, I guess it could be
> conveyed without using SCI draft.
&= gt; For instance, we could use Impact class of the base IODEF to convey the=
> indicators.
> We could for instance extend the list of indic= ators of the Impact class, if
> needed.
> ---------------------= ---------------------------------------------------------------------------= ------
>
> In doing so he pointed out the "Impact Class"
&g= t;
> Whereas, Kathleen stated,
>
> --------------------= ---------------------------------------------------------------------------= ------
> For the discussion below, I was thinking more of combined se= t with relationships that may be included in a single extension point, so that's why I was thinking about the EventData class, but there m= ay be better locations or a specific area within the EventData.
> > Paul Stoecker had suggested a "Detection" class as a consideration.> --------------------------------------------------------------------= --------------------------------
>
> Kathleen thoughts related= yet still with other indicators and the EventData Class.
>
> = Is there a possible way to create a new XML class which encompass combining= the EventData, Detection and base IODEF classes to simplify this issue?>
>
> C. Henry Adams
> chatlga2000= @yahoo.com (Direct Email)
> chen= ryadams@biemediagroup.com
>
>
> The information contained herein is for the exclusive use of the original recipient. This = information is granted for limited distribution within the recipient's plac= e of business for planning purposes only. Further dissemination, whether pr= ivate or public is prohibited.
> ____________________________________= ___________
> mile mailing list
> mile@ietf.org
> http= s://www.ietf.org/mailman/listinfo/mile

---36511695-1034663839-1359433497=:20429--