Subject: [mile] considerations on RFC5070

From: Rossella Mattioli <[email-masked]>
Date: Fri, 4 May 2012 17:23:26 +0300

Greetings all,

considering the recent drafts and the thread regarding IODEF enumerations I would like to submit to the list some considerations related to RFC 5070.

My name is Rossella Mattioli and I recently joined this working group.
I am currently completing my MSc in Cyber Security at Tallinn University of Technology in Estonia with a thesis on a framework for CERTs incident information exchange.
This will be also my PhD research due to the extension of this topic . Prior to join the academic world I worked for 9 years as the intranet manager of a major italian financial group where I was also in charge of content management and coordination of over two hundred contributors and a very articulated restriction based content policy.

I joined MILE because IODEF is an important part of my research where I am investigating how to use it as a baseline for an interoperability framework.
I am still learning how this working group operates but at the same time I would like to raise some questions.

My initial research included mapping all solutions available, analyzing 100 publicly available data feeds and try to use IODEF as a parsing model.
In doing this I developed some considerations which I try to summarize here and that I would like to share with you:

- Would you consider beneficial to have some classes with enumerated category values regarding attack and malware type in IODEF ? This could give at first sight a high level categorization of the attack/malware type to the handler and prompt to future aggregation for comparison and statistics. 

- Domain data is usually an important part of an incident and I wonder if a IODEF document could not benefit on how this information is handled in RFC5901? Considering the DomainData, DomainContacts and Nameservers elements, maybe it could be useful to insert  this information also in IODEF as a more generic class regarding domain data.

- It is not straightforward how to use IODEF to describe some important threats that are subjected to everyday data exchange like sinkholes and C&C data feeds. How would you express this kind of data with the current data schema ? I give you a short example taken from http://www.shadowserver.org/wiki/pmwiki.php/Services/Sinkhole-HTTP-Referer.
From RFC5070 it is clear how to describe  
ReportTime - 2010-06-10 23:55:29
Address category=ipv4-addr - 200.234.220.51
Address category=ASN - 27715
but it is not straightforward how to describe the following data:
Infection type - iframe exploit 
The URL or http host visited  - ww.robint.us 
The actual referral URL  - http://www.maispaulista.com.br/visualizar.asp?idMenu=22&idSubMenu=115
Country where the IP is located  - BR

- last but not least, I was wondering if the WG has statistics or has done a survey regarding the actual usage of IODEF by CSIRTs around the world. This could show which classes are considered more/less fulfilling the everyday needs of response teams and also eventual gaps/evolution they would underline.

Any suggestion/ comment/advice is more than appreciated since I am totally new to the IETF environment .

Best regards,
Rossella Mattioli

---

From: <[email-masked]>
Date: Fri, 4 May 2012 10:37:48 -0500

Welcome aboard!

One of the things I hope to do in this WG - time permitting - is to contribute to a guidance draft to advance the potential adoption of IODEF and your questions are all good ones to start the conversation around what RFC 5070 currently lacks.

>> Would you consider beneficial to have some classes with enumerated category values regarding attack and malware type in IODEF ? This could give at first sight a high level categorization of the attack/malware type to the handler and prompt to future aggregation for comparison and statistics. 
	
TM: I think that there is certainly room for some additional guidance about utilizing the Method class of IODEF to indicate these types of characteristics. 

The trick is that there are not (and may never will be) globally accepted taxonomies for attack types and malware characterization, so this would have to be a pointer to a local registry of enumerations and definitions - hopefully tailored from a common framework like CAPEC, but every CSIRT and CSIRT-like organization has need for individualized vocabularies. The Reference class under Method allows for a solution to this, but it seems like adopters want to include their name for the kind of attack or malware inline as an attribute, like the Impact class does with type.
	
I would also humbly suggest that conflating things by including attack vectors or types as enumerated values under the Impact class - as 5070 does - creates confusion in this area.

>> Domain data is usually an important part of an incident and I wonder if a IODEF document could not benefit on how this information is handled in RFC5901? Considering the DomainData, DomainContacts and Nameservers elements, maybe it could be useful to insert  this information also in IODEF as a more generic class regarding domain data.

TM: I do not disagree. The issue may be where to put it. At first glance I would think those classes would look nice under the System or Node classes but that is not how 5901 does it.

>> It is not straightforward how to use IODEF to describe some important threats that are subjected to everyday data exchange like sinkholes and C&C data feeds. How would you express this kind of data with the current data schema ? I give you a short example taken from http://www.shadowserver.org/wiki/pmwiki.php/Services/Sinkhole-HTTP-Referer.
>From RFC5070 it is clear how to describe ReportTime - 2010-06-10 23:55:29 Address category=ipv4-addr - 200.234.220.51 Address category=ASN - 27715 but it is not straightforward how to describe the following data:
Infection type - iframe exploit
The URL or http host visited  - ww.robint.us The actual referral URL  - http://www.maispaulista.com.br/visualizar.asp?idMenu=22&idSubMenu=115
Country where the IP is located  - BR

TM: Agreed. There are various places those things could be placed but it is not clear from 5070 on which class or where they should be put. It seems like this is something important enough that there should be some additional guidance on it rather than leaving it for local definition.

>> last but not least, I was wondering if the WG has statistics or has done a survey regarding the actual usage of IODEF by CSIRTs around the world. This could show which classes are considered more/less fulfilling the everyday needs of response teams and also eventual gaps/evolution they would underline.

TM: I am not aware of any such statistics but I agree that they would be useful. I am aware of only a very small number of operational implementations of IODEF "in the wild" and I believe the APWG's version, incorporating the 5901 extensions, is probably the most comprehensive in terms of the number of classes it actually utilizes.

 - Tom Millar, US-CERT

[email-masked]
BB: [email-masked] / 202-631-1915
24x7: [email-masked] / 888-282-0870

---

From: <[email-masked]>
Date: Fri, 4 May 2012 14:14:23 -0400

Rosella, welcome and thank you for kicking off this conversation!  It sounds like your experience will be very helpful to the WG!

I'll keep my response light and hope other list participants, implementers, or CSIRT operators chime in.  We could see if we need to open up IODEF in an RFC5070-bis in addition to a separate guidance document.  This would let us correct issues like the ones you have identified and then develop guidance that may go deeper than what is needed in the base structure document separately (just a thought).

It would be great to have a survey of implementations, I am not aware of one either.  Other international CSIRTs use IODEF, such as JPCERT, the Brazil CERT, Aus CERT (I think), and some in Europe (Terena started IODEF).  Additionally DFLabs has a product that is based on IODEF and it looks like HP Arcsite supports IODEF.  There was also a recent effort to include IODEF for incident exchange via XMPP via IODEF.  There are probably others and it would be really nice to have their collective input on any proposed improvements to the format or guidance.

Thank you!
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, May 04, 2012 11:38 AM
To: [email-masked]; [email-masked]
Subject: Re: [mile] considerations on RFC5070

Welcome aboard!

	

 - Tom Millar, US-CERT

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

---

From: SM <[email-masked]>
Date: Fri, 04 May 2012 13:56:05 -0700

Hi Rossella,
At 07:23 04-05-2012, Rossella Mattioli wrote:
>- last but not least, I was wondering if the WG has statistics or 
>has done a survey regarding the actual usage of IODEF by CSIRTs 
>around the world. This could show which classes are considered 
>more/less fulfilling the everyday needs of response teams and also 
>eventual gaps/evolution they would underline.

I recall that there was some research being done in a country in 
Latin America.  I don't know whether IODEF was being used.

Regards,
-sm

---

From: Rossella Mattioli <[email-masked]>
Date: Sat, 5 May 2012 13:53:35 +0300

Thank you so much Kathleen, Thomas and SM.

I grouped the answers and put my comments inline.

> TM: I think that there is certainly room for some additional guidance about utilizing the Method class of IODEF to indicate these types of characteristics. 

I agree with you, I believe that further implementing this class could be helpful considering the importance of these indicators.
> The trick is that there are not (and may never will be) globally accepted taxonomies for attack types and malware characterization, so this would have to be a pointer to a local registry of enumera…

I agree, there will be always internal vocabularies and if allowed, users will always put their own names as attributes. This is why it could be useful to have a high level enumerations and definitions which CSIRTs can use to map their own dictionaries and insert their internal characterizations and names as a subset.
A general registry could be seen as a first effort in the direction of a standardized high level characterization for attack and malware. This could be then linked both to more organized frameworks and also proprietary implementations.
Considering the volume of these events, having not globally accepted categories hampers the alignment of incident categorization. It also doesn't easily allow to compare statistics between different CSIRTs and have a global view on the real numbers. Implementing a general characterization in IODEF could help as a first step in this direction. 

> I would also humbly suggest that conflating things by including attack vectors or types as enumerated values under the Impact class - as 5070 does - creates confusion in this area.

If you are referring at the current impact@type values: 
1.   admin.  Administrative privileges were attempted.
2.   dos.  A denial of service was attempted.
3.   file.  An action that impacts the integrity of a file or database was attempted.
4.   info-leak.  An attempt was made to exfiltrate information.
5.   misconfiguration.  An attempt was made to exploit a mis-configuration in a system.
6.   policy.  Activity violating site's policy was attempted.
7.   recon.  Reconnaissance activity was attempted.
8.   social-engineering.  A social engineering attack was attempted
9.   user.  User privileges were attempted.
10.  unknown.  The classification of this activity is unknown.
11.  ext-value.  An escape value used to extend this attribute.
I agree with you.

> TM: I do not disagree. The issue may be where to put it. At first glance I would think those classes would look nice under the System or Node classes but that is not how 5901 does it.

Yes, System or Node are probably the places where to put it. I only used the RFC5901 example to show which elements could be useful to describe.

> TM: Agreed. There are various places those things could be placed but it is not clear from 5070 on which class or where they should be put. It seems like this is something important enough that the…

I totally agree, perhaps including the high level characterization I was mentioning above and implementing the domain data could be considered in defining this information.

> TM: I am not aware of any such statistics but I agree that they would be useful. I am aware of only a very small number of operational implementations of IODEF "in the wild" and I believe the APWG'…

On May 4, 2012, at 9:14 PM, <[email-masked]> wrote:
...
> It would be great to have a survey of implementations, I am not aware of one either.  Other international CSIRTs use IODEF, such as JPCERT, the Brazil CERT, Aus CERT (I think), and some in Europe (…
...

On May 4, 2012, at 11:56 PM, SM wrote:
....
> I recall that there was some research being done in a country in Latin America.  I don't know whether IODEF was being used.

...

Thank you so much. I noted APWG,  JPCERT, the Brazil CERT, Aus CERT, Terena and the vendors. I will look for the research in Latin America.
Are these CERTs/orgs and vendors members of the MILE?

Best regards,
Rossella Mattioli