Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence

From: "Roman D. Danyliw" <[email-masked]>
Date: Fri, 23 Aug 2013 20:55:40 +0000

Hello,

In increase readability, I removed the top portions of the post and created a legend below to track the source of the comment.  I'd recommend that future replies add themselves to this list.

Legend:
PK> = Panos Kampanakis
KM> = Kathleen Moriarty
LD> = Luc Dandurand
RD> = Roman Danyliw

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: Monday, August 05, 2013 4:38 PM
To: [email-masked]
Subject: [mile] 5070bis-scoping discussion #1: Cyber Intelligence

Hello!

Per the earlier announcement in [1], this note initiates topic discussion #1 on the 5070bis scope discussion.  A power-point formatted version of this text can be found in slides 4 and 5 of [2].  If you have a feelings on the matter, please provide input by August 26th.  To repeat, the intent here is to assess interest in including the information listed below in the 5070bis data model.  Opinions to add it in or explicitly avoid it are welcome.  In the case of the former, proposals are welcome but not required.

(1) How much cyber intelligence information should be represented?
**(a)** Description of the source and target of the event
PK> Yes, I think we can provide that already.
KM> I am not aware of requests for additional information to be represented above what is there.
RD> Beyond what's already in the Issue tracker or on the mailing list, I concur.

**(b)** Description of the technical pattern of a given tactic used in an attack (e.g., indicators or signatures)
**(c)** Description of the actors perpetrating the attack?
PK> A summary description in text would beneficial. But I don't think 
PK> such description would make a difference for an automated content 
PK> consumer
KM> I agree with Panos.  When I asked the question of one group, they said they didn't get enough of this data to worry about a standard format, text should be okay for now.
RD> For (c), I concur that we don't want to provide a lot of structured data here.  I would recommend free form text to the majority of the description, some means to provide a machine-readable label, the ability to convey confidence, and a defined means for extension

**(d)** Description of the capabilities and  intent of the actors?
PK> A summary description in text would beneficial. But I don't think 
PK> such description would make a difference for an automated content 
PK> consumer
KM> +1
RD> +1

(2) What other indicator data fields should be add?
**(a)** File information (e.g., size, attributes, ACLs, ADS, PE information)
**(b)** Process information (e.g., pids, chains, loaded libraries)
PK> I think that would bloat the IODEF data model.
KM> I agree, SCI could be used or if there is interest, would the forensic extension be helpful and should that be revived to keep the core data model smaller?
RD> The recent changes in the RFC5070-bis already include file name and file size.  Issue #20 (http://tools.ietf.org/wg/mile/trac/ticket/20) is tracking how these classes need to be modified.  I concur that the 5070-bis shouldn't represent more of the items in (a).  More thinking on this is required, but in whatever thinking is done in redefining a list of files (again, per Issue #20), perhaps adding '<xs:element name="FileAttributes"               type="iodef:ExtensionType"/>' as a means to extend with an outside schema additional properties of the file.
RD> As to the items in (b), I concur that we don't want to represent in into 5070-bis, but I think we need to provide guidance on how we'd like someone to provide an extension.

**(c)** Mutex names
**(d)** Device state (e.g., ARP or routing table, disk geometry, BIOS, network settings)
PK> I think that would bloat the IODEF data model.
KM> I think you can already include ARP information?  Would some of this just be extensions through recordItem perhaps - if people say they need it and not inthe core data model?
RD> The only way one can specify ARP information would be to provide two Address classes, one with Address@category={ipv4-addr,ipv6=addr} and another with Address@category="mac".  I look to the community to comment on whether that's clean enough.
RD> I concur that this system state information isn't appropriate in 5070-bis, but again I think we need to think through where an implementer should add the extension.  Should we be prescriptive to add a '<xs:element name="SystemState" type="iodef:ExtensionType"/>' to Flow/System?

**(e)** Email (e.g., arbitrary headers, structure of contents)
KM> This can be done through RFC5901 or by using SCI and including ARF, right?  I think that may be sufficient unless others feel strongly.
RD> Could an example be provided to demonstrate how IODEF+SCI+ARF could be chained together to provide this representation.  For example, if I wanted an indicator to be a specific value in a Return-Path header, how would I do that?

**(f)** Currently already support From, Subject, X-Mailer
**(g)** HTTP (e.g., arbitrary headers)
**(h)** Currently already support URL and UserAgent

RD> I feel like we might be "future proofing" ourselves if we can provide a means to generically capture application layer headers.  For example,

<Layer7Hdr proto="http" field="Accept-Language">en-US</Layer7Hdr>
Or 
<Layer7Hdr proto="sip" field="method">INVITE</Layer7Hdr>

**(i)** TLS Certificate or certificate chains
PK> not sure we need them
KM> f-i were requested to meet soem specific use cases of commonly shared items.  Our CIRC wanted them.
RD> I believe this would be helpful to have.  We should finish the discussion started on this matter in http://www.ietf.org/mail-archive/web/mile/current/msg01164.html, question #6.

**(j)** External signatures languages (e.g., Yara, snort, Bro)
PK> I think that would bloat the IODEF data model.
KM> Would this just be through RecordItem or AdditionalData extensions 
KM> anyway, so is bloat an issue?  I think these should just be handled 
KM> through the extensibility mechanisms
RD> I believe we should consider this for inclusion.  I'd envision utility in something no more complicated than:

<Signature platform="snort">
alert tcp $EXTERNAL_NET any -> $HOME_NET 139
(flow:to_server,established;
content:"|eb2f 5feb 4a5e 89fb 893e 89f2|";
msg:"EXPLOIT x86 linux samba overflow";)
</Signature>

(3) Explicitly express a relationships between indicators? e.g., "(From: Email1 and Email1) OR (X-Mailer)"
PK> I am not sure what changes in IODEF that would entail
KM> Can't we do that through the predicate logic already without needing to put in the words?  This should be machine readable to be useable/get adoption anyway.  We don't have a way to say a value provided contains, starts or ends with, etc. is that needed? 
RD> Agreed.  There is already discussion underway about predicate logic.  See Issue #14 (http://tools.ietf.org/wg/mile/trac/ticket/14).

(4) Absence of an indicator?
KM> Would like to hear other opinions on the usefulness of this.
RD> Agreed.  It seems like this should be added to the predicate logic discussion.

(5) Valid time to apply the indicator (EventData/StartTime and EndTime?)
PK> that will be useful I think
KM> +1
RD> +1

PK> In general, I do not think that expanding IODEF to be an all-inclusive data model is within the scope of this work. I was under the impression that the bis doc would adopt some changes in IODEF that came for real-world exercises. IODEF should still be simple and functional and be able to describe real-world incidents in a simple manner. But adding things like process ids I think expands its scope extensively and I am not sure this WG will be able to provide an all-inclusive solution. I think for more advanced descriptions there is the SCI draft that could leverage other outside languages.
KM> I agree with Panos.  For some of the items, would RecordItem and AdditionalData be the right extension mechanisms to allow that data to be exchanged and in other cases that require data models, SCI could help.
LD> +1
LD> I can't provide a recommendation on which extension mechanism would be most appropriate, but I also don't believe in a single, global data model, but rather the ability to easily correlate many different ones that evolve independently. I therefore think that the IODEF data model and specification should continue to cover key areas with human readable text fields, and use IODEF-SCI for the structured information to allow any of the structured information standards to be used.
LD> Once again I state this with only preliminary knowledge of IODEF, hopefully to expand very soon.

PK> Rgs
PK> Panos

KM> Thank you, Kathleen

Regards,
Roman

[1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html
[2] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf
_______________________________________________