Subject: Re: [mile] considerations for IETF 84 guidance / updating IODEF discussion

From: Rossella Mattioli <[email-masked]>
Date: Wed, 1 Aug 2012 18:23:09 +0200

Hi Pat,

thank you so much for your comments.
My replies are inline.

On Jul 31, 2012, at 5:07 PM, Pat Cain wrote:

> Hi,
> 
> I have a couple of comments.
> They should be prefaced by a  pc>
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rossella Mattioli
> Sent: Thursday, July 26, 2012 12:42 PM
> To: [email-masked]
> Subject: [mile] considerations for IETF 84 guidance / updating IODEF
> discussion
> 
> Hi all,
> 
> considering the agenda of IETF 84 I would like to submit to the list some
> thoughts on the guidance / updating IODEF discussion.
> These gaps and overlaps emerged during the data set analysis of 89 publicly
> available data feeds for response teams I made for my research.
> Hope they can be of help for next week meeting.
> 
> 	Pc> I am interested in the output of your research - paper, thesis,
> web page, etc. is it's available?

You can find the abstract on my website http://www.07011979.org/post/26825136212/information-exchange-framework-for-cyber-security
I'll send you the entire thesis in a direct mail. In case somebody else is interested, please let me know.

> 
> Contact class: IODEF covers most of the available information within
> contact@role. There are some values that are not directly mapping with
> popular type of role such as sensor but this can be done via cross reference
> with the system@category for what concerns the sensor value. For what
> concerns LEA and vulnerability reporter there are two ways of
> implementation:
> 
> 	. implement the escape value to extend this attribute;
> 
> 	. foster the adoption of these values within the official data
> schema.
> 
> Moreover since PGP is widely used within the security community an ad-hoc
> element should be considered for future implementation.
> 
> 	Pc>	The PGP attribute you may want is the KeyID. I don't know
> how you guarantee integrity protection over the Incident Report, but having
> a modifyable KeyId value there when a report is forwarded could be
> entertaining.
I see your point.

> 	Pc> I don't understand the sensor issue. The Contact class is to
> identify the person or organization submitting the Incident. A 'sensor' is
> probably not a legal entity. The "sensor's operator" is what would go into
> the Contact element, no?

Exactly, the sensor operator as for example Shadowserver

> Time: the time classes offered by IODEF cover most of the values
> encountered.There is one value that occurred in the data I analyzed which
> was not covered: next validation time. This gap can be fulfilled with escape
> value.
> 
> 	Pc>	This could be useful.

In your experience, do you see the need of any other value?
From the data I analyzed, this is the only one I encountered which was not mappable with available values.

> 
> Address: to define an address IODEF already includes all the granularity to
> define IPv4, IPv6 and ASN numbers in the system and node classes. At the
> moment only domain data is not fully covered by the current data schema and
> in order to fulfill this gap two possible actions can be evaluated:
> 
> 	. to use the definition of the class from RFC 5901 and describe the
> information with the DomainData, DomainContacts and Nameservers elements;
> 
> 	. to implement a new class regarding the domain data with an update
> of the IODEF data schema. 
> 
> 	Pc> 	You really don't want to do this. We made the DomainData
> class since nobody had defined a way of expressing domain registration data
> in XML. Now that I'm populating that field out, I'm starting to hate it. You
> want to use whatever the WEIRDS WG ends up with. Although their spec is
> currently JSON, it could be used as is or XML-ed, but that is the structured
> domain data format of the future.
> 
Thank you so much for the feedback :) and also for the suggestion!
I am going through WEIRDS drafts http://tools.ietf.org/wg/weirds/

> [snip]
> ... All the enumeration discussion...
> [snip]
> 
> 	Pc> So IODEF was completed a while back. And attacks and eCrime have
> evolved. IODEF is trying but has not kept up. Almost *all* of the enumerated
> lists have major deficiencies. Instead of just taking in new values, a way
> needs to be defined that allows IODEF to evolve with the attacks and
> eCrimes. This may just mean making the enumerations 'open' so values can be
> added as necessary. Or maybe there's a "current list of enumerations"
> informational RFC or website or something. But as soon as we define new
> enumerations we find that we need another one. I don't see a need to
> standardize all the enumerated lists, tho.

What about a very generic one, high level, which can be mapped with all different vocabularies and/ or taxonomies?
I am thinking about your http://repoman.apwg.org/research/wiki/taxonomy4?version=6 and the VERIS https://github.com/veris-opensource/verisc for example

> 
> Malware: IODEF does not include any specific class to malware samples. The
> reference class can be used to refer to a particular sample but there are no
> related enumeration or specific classes to identify which kind of malware
> infections occurs in the incident. In the RFC 5901 a first attempt is made
> both with the fraud@type value "malware distribution" and also with the
> relative class "included malware" and the subclass data, the
> "FilesDownloaded" and "WindowsRegistryKeyModified" class. Considering the
> importance and the volume of these threats in the current scenario it should
> be discussed :
> 
> 	. improving the guidance of the current IODEF data model and related
> extensions;
> 
> 	. implementing a high level taxonomy of malware types and leave
> further characterization to the interoperability with other cyber security
> formats.
> 
> The malware indicators should be hashes (MD5 or SHA1), the filetype and the
> version. As it can be noticed I do not refer to the name of the file. Naming
> a file can be not straightforward, where possible the name of the malware
> should be defined using the CARO Malware Naming Scheme, which even if not
> updated, is the most popular guideline among anti virus companies. In this
> respect, the need to a high level characterization arises to help the
> handler in quickly identify the threat. Moreover IODEF Fraud extension is
> too generic for a complete in-depth categorization of the sample and lacks
> of detailed information regarding behaviors and other characteristics that
> could be of help in response of the threat.  This effort could help in
> understanding the infection and can be neighborly in the foreseen
> integration with other cyber security exchange formats regarding malware.
> 
> 	Pc>	People who are slopping malware data around - bot in XML and
> in IODEF - are using the IEEE Malware schemas. You should use them, too.

This is exactly the point. The suggestion is to put a high level characterization inside the incident document:
- to allow the handler to quickly recognize the threat at first sight, before digging into the MAEC, MMDEF, Cybox or other data
- and to have a common baseline which could enable to compare statistics between different organizations/regions etc.

> 
> 
> 	Pc> A lot of your comments say "improving the guidance of the
> current IODEF data model and related extensions".  You should write a draft.
> Many people would be happy.

I made the reference in order to insert these suggestions into the discussion at IETF84.
If this thread is considered interesting by the mailing list, I will be happy to work on it.

Regarding IETF84, I am trying to download yesterday meeting (sorry I was not able to attend) but I get 404.
Does anybody know when will be the recordings available?

Thank you so much and looking forward to other comments,
Rossella

---

From: <[email-masked]>
Date: Wed, 1 Aug 2012 12:38:21 -0400

Thank you both for the comments.  Others- please chime in!

I will just add an option for the enumeration lists.  I think a registry that lets us add values between data model updates could go a long way.  We set one up for RFC6545 so we could add sharing groups or other enumerated values to the lists without having to update the RFC.  The registry can be found here:
http://www.iana.org/assignments/rid/rid.xml
and is set up for any of the lists in the RID schema.  The format is specified in the IANA section of RFC6545, you specify the list, the value and a definition.  Expert review is required to add a value.

Thanks,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Rossella Mattioli [[email-masked]]
Sent: Wednesday, August 01, 2012 12:23 PM
To: Pat Cain
Cc: [email-masked]
Subject: Re: [mile] considerations for IETF 84 guidance / updating      IODEF   discussion

Hi Pat,

I see your point.

_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile