Subject: [mile] RFC 5070 updates and guidance

From: <[email-masked]>
Date: Thu, 1 Mar 2012 10:23:59 -0500

Hello all,

MILE has in the charter an item to provide guidance on IODEF, to change it where needed to enable lightweight exchanges.  Many capabilities are enabled through IODEF to enable lightweight exchanges, such as the use of the pre-negotiated ‘formatid’ in exchanges to reduce the context shared in each incident exchange, and flexibility inherent in the schema itself.  Several items have been raised in terms of things that either need to be fixed in IODEF or guidance that needs to be created.

1)	From both the review of RID (RFC6045-bis)  and the IODEF Template for Extensions review by the IESG, issues in IODEF were identified in how internationalization is handled.  In IODEF, we need to review and fix in several areas including the use of MLSTRING, add internationalization of the NodeName element of the Node class, and possibly other locations.
2)	Review existing guidance in IODEF for sharing watch lists of data and other data types commonly shared.  Is there interest in adding more attribute enumeration values to indicate a list of sources in the system class for this purpose?  Are there other guidance changes that will assist with effective exchanges?
3)	Although the schema is extensible for attribute enumeration values and the ability to extend classes, the WG may want to consider the creation of a registry through IANA to enable the update of attributes without the need to update the schema.  This could be requested in an update to RFC 5070.
4)	There may be other updates needed after several years of operational experience, either through guidance or updates to the schema.
5)	Guidance for including reference information for structured data types where only the enumeration value and a reference is required for exchange.  This guidance is needed to ensure consistency in how the enumerations are exchanged to ensure successful parsing of the values.  Guidance should also be provided to delineate when it is appropriate to share this information via the IODEF Reference class or when the SCI draft and the enabled extensions may be necessary to share richer information contained in XML schemas.  One example may be when enumeration values are sent outside of an area where those values are typically used to ensure full context is provided.  This example comes from Japan where they have their own registry based on the Common Vulnerability Enumeration format.
6)	Guidance is needed to provide consistent interpretations of when an item should be shared via IODEF and when an extension is needed.  If there is overlap between the supported data sets, where does the information reside to ensure consistency between implementations?
7)	Guidance for the use of ‘formatid’ may be very helpful to enable the ability to exchange some common data sets with reduced context to reduce the size of exchanges.  The WG could explore setting a few formatid’s that make sense and leave others up to be decided by groups that share data in preset arrangements as is suggested in RFC5070.  

As a WG, we need to determine what will be required for an update to IODEF and what may be contained in a separate IODEF Guidance document.  I believe the updates will be split between two documents and we will need volunteer editors for each.  These updates will require a lot of WG collaboration.

Best regards,
Kathleen

---

From: Jeff Reed <[email-masked]>
Date: Fri, 2 Mar 2012 08:43:05 -0800

Kathleen,

   I would like to assist in the IODEF Guidance effort as one of the
editors.  Please let me know how to proceed from here.

Jeff Reed
InfoSec Office
Cambia Health Solutions

2012/3/1 <[email-masked]>

> Hello all,
>
> MILE has in the charter an item to provide guidance on IODEF, to change it
> where needed to enable lightweight exchanges.  Many capabilities are
> enabled through IODEF to enable lightweight exchanges, such as the use of
> the pre-negotiated ‘formatid’ in exchanges to reduce the context shared in
> each incident exchange, and flexibility inherent in the schema itself.
>  Several items have been raised in terms of things that either need to be
> fixed in IODEF or guidance that needs to be created.
>
> 1)      From both the review of RID (RFC6045-bis)  and the IODEF Template
> for Extensions review by the IESG, issues in IODEF were identified in how
> internationalization is handled.  In IODEF, we need to review and fix in
> several areas including the use of MLSTRING, add internationalization of
> the NodeName element of the Node class, and possibly other locations.
> 2)      Review existing guidance in IODEF for sharing watch lists of data
> and other data types commonly shared.  Is there interest in adding more
> attribute enumeration values to indicate a list of sources in the system
> class for this purpose?  Are there other guidance changes that will assist
> with effective exchanges?
> 3)      Although the schema is extensible for attribute enumeration values
> and the ability to extend classes, the WG may want to consider the creation
> of a registry through IANA to enable the update of attributes without the
> need to update the schema.  This could be requested in an update to RFC
> 5070.
> 4)      There may be other updates needed after several years of
> operational experience, either through guidance or updates to the schema.
> 5)      Guidance for including reference information for structured data
> types where only the enumeration value and a reference is required for
> exchange.  This guidance is needed to ensure consistency in how the
> enumerations are exchanged to ensure successful parsing of the values.
>  Guidance should also be provided to delineate when it is appropriate to
> share this information via the IODEF Reference class or when the SCI draft
> and the enabled extensions may be necessary to share richer information
> contained in XML schemas.  One example may be when enumeration values are
> sent outside of an area where those values are typically used to ensure
> full context is provided.  This example comes from Japan where they have
> their own registry based on the Common Vulnerability Enumeration format.
> 6)      Guidance is needed to provide consistent interpretations of when
> an item should be shared via IODEF and when an extension is needed.  If
> there is overlap between the supported data sets, where does the
> information reside to ensure consistency between implementations?
> 7)      Guidance for the use of ‘formatid’ may be very helpful to enable
> the ability to exchange some common data sets with reduced context to
> reduce the size of exchanges.  The WG could explore setting a few
> formatid’s that make sense and leave others up to be decided by groups that
> share data in preset arrangements as is suggested in RFC5070.
>
> As a WG, we need to determine what will be required for an update to IODEF
> and what may be contained in a separate IODEF Guidance document.  I believe
> the updates will be split between two documents and we will need volunteer
> editors for each.  These updates will require a lot of WG collaboration.
>
>
> Best regards,
> Kathleen
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
>

---

From: <[email-masked]>
Date: Mon, 5 Mar 2012 11:14:29 -0500

Hi Jeff,

Excellent!  I think others will also volunteer to help as interest was expressed in the past to work on this document, so you should have help from an editor standpoint.  If you would like to pick one of the topics and lead discussions on the topics listed and anything else that may be relevant to a guidance document, that would be helpful.  

My responses may be a little delayed over the next few days as I am taking a few days off after a crazy travel schedule over the past two weeks.

Thank you,
Kathleen
________________________________________
From: Jeff Reed [[email-masked]]
Sent: Friday, March 02, 2012 11:43 AM
To: Moriarty, Kathleen
Cc: [email-masked]; Jeff Reed; Jeffrey A Reed
Subject: Re: [mile] RFC 5070 updates and guidance

Kathleen,

   I would like to assist in the IODEF Guidance effort as one of the editors.  Please let me know how to proceed from here.

Jeff Reed
InfoSec Office
Cambia Health Solutions

2012/3/1 <[email-masked]<mailto:[email-masked]>>
Hello all,

Best regards,
Kathleen
_______________________________________________
mile mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mile