Subject: [mile] I-D Action: draft-ietf-mile-iodef-guidance-03.txt

From: [email-masked]
Date: Thu, 01 May 2014 13:10:46 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Managed Incident Lightweight Exchange Working Group of the IETF.

        Title           : IODEF Usage Guidance
        Author          : Panos Kampanakis
	Filename        : draft-ietf-mile-iodef-guidance-03.txt
	Pages           : 26
	Date            : 2014-05-01

Abstract:
   The Incident Object Description Exchange Format [RFC5070] defines a
   data representation that provides a framework for sharing information
   commonly exchanged by Computer Security Incident Response Teams
   (CSIRTs) about computer security incidents.  Since the IODEF model
   includes a wealth of available options that can be used to describe a
   security incident or issue, it can be challenging for implementers to
   develop tools that can Leverage IODEF for incident sharing.  This
   document provides guidelines for IODEF implementers.  It will also
   address how common security indicators can be represented in IODEF
   and use-cases of how IODEF is being used so far.The goal of this
   document is to make IODEF's adoption by vendors easier and encourage
   faster and wider adoption of the model by Computer Security Incident
   Response Teams (CSIRTs) around the world.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mile-iodef-guidance-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mile-iodef-guidance-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 1 May 2014 20:19:51 +0000

Hello,

This is the -03 version of the IODEF guidance draft incorporating Roman's, Kathleen's, Trevor's and David's comments so far. The updated made from -02 version are 
   (1)  Added "Updates" section.
   (2)  Added details about the flow of information exchanges in "Inter-
        vendor and Service Provider Exercise" section.  Also updated the
        usecases with more background information.
   (3)  Added future use-cases in the "Collective Intelligence
        Framework" section
   (4)  Updated Perl and Python references with the actual module names.
        Added IODEF implementation reference "implementations".
   (5)  Added Predicate logic section
   (6)  Updated Logic of watchlist of indicators section to simplify the
        logic and include examples.
   (7)  Renamed Externally defined indicators section to Indicator
        reference and elaborated on the use of indicator-uid and
        indicator-set-uid attribute use.

It is still not complete and some sections need to be expanded. I will now work on -04 and hopefully will have a more complete version in a couple of months.

Feedback and reviews are welcome.

Regards,
Panos

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, May 01, 2014 4:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: [mile] I-D Action: draft-ietf-mile-iodef-guidance-03.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

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

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Thu, 22 May 2014 21:50:56 +0900

Hello Panos,

Thank you for updating the draft.
I am wondering if we could use the following texts as a starting point of
the section 4.3.

---------------------------------------
IODEF data model is designed to be extensible.
We can extend the enumerated values of the attributes by using the "ext-*"
fields, whereas we can extend the classes by using the AdditionalData and
RecordItem classes.
Please see RFC 5070 for details.
Some of these AdditionalData extensions were documented as standard
specifications.
Please see RFC5901 for the phishing extension.

On the other hand, IODEF can borrow existing schemata by using an extension
framework defined in RFC 7203.
The framework enables us to embed xml documents and identifiers whose
schemata or structure are defined by external specifications inside IODEF
document.
In this way, the capability of IODEF data model is extended, but users do
not have to extend IODEF itself. Users simply need to use schemata that were
defined outside IODEF data model.
Please see RFC 7203 for details.
---------------------------------------

This is just a basis for discussion and revision, but I hope the above
understanding is roughly aligned with you.

Take

> From: mile [mailto:[email-masked]] On Behalf Of Panos 
> Kampanakis
> (pkampana)
> Sent: Friday, May 2, 2014 5:20 AM
> To: [email-masked]
> Subject: Re: [mile] I-D Action: draft-ietf-mile-iodef-guidance-03.txt
> 
> Hello,
> 
> This is the -03 version of the IODEF guidance draft incorporating 
> Roman's, Kathleen's, Trevor's and David's comments so far. The updated 
> made from
> -02 version are
> It is still not complete and some sections need to be expanded. I will 
> now work on -04 and hopefully will have a more complete version in a 
> couple of months.
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at
tools.ietf.org.

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 22 May 2014 20:34:38 +0000

Thank you for the suggestion Take. 

I rephrased it a little. It will be in the next iteration of the document and will read something like 
------
	[...]
	The IODEF data model (RFC5070) is extensible. Many class 
	attributes and their values can be extended using using the "ext-*" prefix. 
	Additional classed can also be defined by using the AdditionalData and RecordItem 
	classes. An extension to the AdditionalData class for reporting Phishing emails 
	is defined in RFC5901.

	Additionally, IODEF can import existing schemata by using an extension framework 
	defined in RFC7203. The framework enables IODEF users to embed 
	XML data inside an IODEF document using external schemata or structures defined by external 
	specifications. Examples include CVE, CVRF and OVAL. Thus, RFC7203 
	enhances the IODEF capabilities without further extending the data model.

	IODEF implementers should consider using their own IODEF extensions only for data 
	that cannot be described using existing standards or importing them in and IODEF 
	document using RFC7203 is not a suitable option.
	[...]
------

Panos

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]] 
Sent: Thursday, May 22, 2014 8:35 AM
To: Panos Kampanakis (pkampana); [email-masked]
Subject: RE: [mile] I-D Action: draft-ietf-mile-iodef-guidance-03.txt

Hello Panos,

Thank you for updating the draft.
I am wondering if we could use the following texts as a starting point of the section 4.3.

---------------------------------------
IODEF data model is designed to be extensible.
We can extend the enumerated values of the attributes by using the "ext-*"
fields, whereas we can extend the classes by using the AdditionalData and RecordItem classes.
Please see RFC 5070 for details.
Some of these AdditionalData extensions were documented as standard specifications.
Please see RFC5901 for the phishing extension.

On the other hand, IODEF can borrow existing schemata by using an extension framework defined in RFC 7203.
The framework enables us to embed xml documents and identifiers whose schemata or structure are defined by external specifications inside IODEF document.
In this way, the capability of IODEF data model is extended, but users do not have to extend IODEF itself. Users simply need to use schemata that were defined outside IODEF data model.
Please see RFC 7203 for details.
---------------------------------------

This is just a basis for discussion and revision, but I hope the above understanding is roughly aligned with you.

Take

> Please note that it may take a couple of minutes from the time of
submission