Subject: Re: [mile] re-charter re-boot

From: Sean Turner <[email-masked]>
Date: Mon, 03 Jun 2013 13:30:28 -0400

Comments from anybody else?

spt

On 5/25/13 9:11 AM, Moriarty, Kathleen wrote:
> Hi,
>
> Sorry for the delay in updating the charter.  There is a lot of activity in this space right now as you all know.  I took Sean's suggested content and updated it to reflect some of the activity and drivers for additional work in MILE.  Several people have mentioned an interest in submitting extensions based on their current work, some in virtualized environments, some for indicator specific formats, some industry specific extensions, etc.  There is also work developing by other groups who have mentioned that they will transition their work to an international standards body once it is mature, so room has been left in the charter to accommodate that work.  The need for guidance on the transport options has surfaced so that implementers understand when they may choose a specific transport option to enable interoperable interfaces between products.  The guidance may be use case specific where tighter security is needed (RID +HTTP/TLS with the object level security options enab
 led) or w
here ease of access is the driver (ROLIE) with no client requirements necessary (can use a browser).
>
> We will follow up with the mile stones, here the the re-write:
>
> <intro>
>
> The Managed Incident Lightweight Exchange (MILE) working group
> develops standards to support computer and network security
> incident management; an incident is an unplanned event that
> occurs in an information technology (IT) infrastructure. An
> incident could be a benign configuration issue, IT incident, an
> infraction to a service level agreement (SLA), a system
> compromise, socially engineered phishing attack, or a
> denial-of-service (DoS) attack, etc.  When an incident is
> detected, or suspected, there may be a need for organizations to
> collaborate. This collaboration effort may take several forms
> including joint analysis, information dissemination, and/or a
> coordinated operational response.  Examples of the response may
> include filing a report, notifying the source of the incident,
> requesting that a third party resolve/mitigate the incident,
> sharing select indicators of compromise, or requesting that the
> source be located. By sharing indicators of compromise associated
> with an incident or possible threat, the information becomes a
> proactive defense for others that may include mitigation options.
> The Incident Object Description Exchange Format (IODEF) defines
> an information framework to represent computer and network
> security incidents; IODEF is defined in RFC 5070 and
> has been extended by RFC 5091 to support phishing reports; RFC
> 6484 provides a template for defining extensions to IODEF.
> Real-time Inter-network Defense (RID) defines a protocol to
> facilitate sharing computer and network security incidents;
> RID is defined in RFC 6545, and RID over HTTPS is defined in RFC
> 6546.
>
> </intro>
>
> The MILE WG is focused on two areas, IODEF the data format and
> extensions to represent incident and indicator data and RID,
> the policy and transport for structured data.  With respect to
> IODEF, the working group will:
>
> - Revise the IODEF document to incorporate enhancements and
> extensions based on operational experience; use by Computer
> Security Incident Response Teams (CSIRTs) and others has
> exposed the need to extend IODEF to support industry specific
> extensions, use case specific content, and representations to
> associate information related to represented threats (system,
> threat actors, campaigns, etc.).  The value of information
> sharing has been demonstrated and highlighted at an increasing
> rate through the success of the Information Sharing and
> Analysis Centers (ISACs) and the recent cyber security Executive
> Order in the US.  International groups, such as the Multinational
> Association for Collaborative Cyber Situational Awareness (CCSA)
> have been running experiments to determine what data is useful to
> exchange between industries and nations to effectively mitigate
> threats.  The work of these and other groups have identified or
> are working to develop data representations relevant to their use
> cases that may compliment/extend IODEF or be useful to exchange
> using RID and related transport protocols.
>
> - Provide guidance on the implementation and use of IODEF to aid
> implementers in developing interoperable specifications.
>
> With respect to RID, the working group will:
>
> - Define a resource-oriented approach to cyber security
> information sharing that follows the REST architectural style.
> This mechanism will allow CSIRTS to be more dynamic and agile in
> collaborating with a broader, and varying constituency.
>
> - Provide guidance on the implementation and use of RID transports
> based on use cases.  The guidance document will show the relationship
> between transport options (RID + RID transport and IODEF/RID + ROLIE)
> and may identify the need for additional transport bindings.
>
> - RID may require modifications to address data provenance, additional
> policy options, or other changes now that there are multiple
> interoperable implementations of RFC6545 and RFC6546.  With the
> RID implementations in the open source community, increased use and
> experimentation may demonstrate the need for a revision.
>
> <milestones>
>
> </milestones>
>
>
> Thank you!
> Kathleen
>
> ________________________________________
> From: [email-masked] [[email-masked]] On Behalf Of Sean Turner [[email-masked]]
> Sent: Wednesday, May 01, 2013 9:04 PM
> To: [email-masked]
> Subject: [mile] re-charter re-boot
>
> Hi,
>
> I'd like to propose a significant re-write of the proposed charter.  I
> think there's too much history that's not really needed any more and
> there's some repetition that's unneeded.  I also think it's a little
> open ended wrt what's actually going to get done. Based on recent
> experience, I have a strong feeling that the current charter wouldn't
> get through the process.
>
> I'm proposing four sections: intro, iodef-related work, rid-related
> work, milestones.
>
> The intro should:
>
> - explain what the WG does: develop standards to do foo.
> - summarize what foo is.
> - highlight existing RFCs that are part of the space:
>     IODEF: 5070/5091/6848 & RID: 6545/6546.
>
> Then we talk about what drafts the WG will produce for the two topic areas.
>
> How about this (or something like this):
>
> <intro>
>
> The Managed Incident Lightweight Exchange (MILE) working group
> develops standards to support computer and network security
> incident management; an incident is an unplanned event that
> occurs in an information technology (IT) infrastructure. An
> incident could be a benign configuration issue, IT incident, an
> infraction to a service level agreement (SLA), a system
> compromise, socially engineered phishing attack, or a
> denial-of-service (DoS) attack, etc.  When an incident is
> detected, or suspected, there may be a need for organizations to
> collaborate. This collaboration effort may take several forms
> including joint analysis, information dissemination, and/or a
> coordinated operational response.  Examples of the response may
> include filing a report, notifying the source of the incident,
> requesting that a third party resolve/mitigate the incident,
> sharing indicators of compromise, or requesting that the source
> be located. The Incident Object Description Exchange Format
> (IODEF) defines an information framework to represent computer
> and network security incidents; IODEF is defined in RFC 5070 and
> has been extended by RFC 5091 to support phishing reports; RFC
> 6484 provides a template for defining extensions to IODEF.
> Real-time Inter-network Defense (RID) defines a protocol to
> facilitate sharing computer and network security incidents;
> RID is defined in RFC 6545, and RID over HTTPS is defined in RFC
> 6546.
>
> </into>
>
> This working group does two things IODEF and RID; we should be clear
> about that and then list the actual documents we're going to produce
> that relate to each one.  For the list of deliverables it looks like
> there's three 5070bis, a reference/guidance draft, and a
> resource-oriented indicator exchange?
>
> Questions:
>
> Are the GRC and Forensic drafts dead-dead?  I assume they'd not be
> included in the milestone list.
>
> Is there going to only be one 5070bis draft or will there be a 5070bis +
> other optional extension drafts?  I assume it's just a 5070bis based on
> the milestones but thought I'd ask.
>
> Are we only extending IODEF based on use or is there something else we
> need to consider?
>
> How about something along the lines of (need some help filling in the
> blanks):
>
> <iodef>
>
> With respect to IODEF, the working group will:
>
> - Revise the IODEF document to incorporate enhancements and
> extensions based on operational experience; use by Computer
> Security Incident Response Teams (CSIRTs) and others has
> exposed the need to extend IODEF to support x, y, z (need to have
> some idea what's missing) base on a, b, c (need to know a bit
> more about why stuff is missing did something new pop up?).
>
> - Provide guidance on the implementation and use of IODEF to aid
> implementers in developing interoperable specifications.
>
> </iodef>
>
> For RID:
>
> Are we also doing defining guidance for RID as well or is that
> incorporated in the IODEF guidance?
>
> Is RID itself going to be untouched and we're just producing a new
> "transport"?
>
> Is it just for indicators or is it for the whole incident?  Or has
> "indicators" over taken "incident"?
>
> <rid>
>
> With respect to RID, the working group will:
>
> - Define a resource-oriented approach to cyber security
> information sharing that follows the REST architectural style.
> This mechanism will allow CSIRTS to be more dynamic and agile in
> collaborating with a broader, and varying constituency.
>
> </rid>
>
> <milestones>
>
> These looked fine, but I'd like some actual dates for the TBDs ;)
>
> </milestones>
>
> spt
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
>

---

From: <[email-masked]>
Date: Mon, 3 Jun 2013 18:10:00 +0000

I have no problem with the revised charter as is but I think there is something missing.  It would be good to have as a milestone a document that described use cases for these protocols.  I rather see this separated out since we are in a situation now of addressing the transport (RID) , the data model for exchange (IODEF) and query/reporting capabilities (ROLIE).  We need to tie the three together and a document such as this would help lay a foundation for usage in multiple areas.

FWIW…

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Sean Turner <[email-masked]<mailto:[email-masked]>>
Date: Monday, June 3, 2013 12:30 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mile] re-charter re-boot

spt

<intro>

</intro>

<milestones>

</milestones>

Thank you!
Kathleen

________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of Sean Turner [[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, May 01, 2013 9:04 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [mile] re-charter re-boot

Hi,

The intro should:

<intro>

</into>

Questions:

<iodef>

</iodef>

For RID:

<rid>

</rid>

<milestones>

</milestones>

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

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

---

From: Sean Turner <[email-masked]>
Date: Tue, 04 Jun 2013 08:29:58 -0400

Is that you volunteering to write such a draft ;)

spt

On 6/3/13 2:10 PM, [email-masked] wrote:
> I have no problem with the revised charter as is but I think there is
> something missing.  It would be good to have as a milestone a document
> that described use cases for these protocols.  I rather see this
> separated out since we are in a situation now of addressing the
> transport (RID) , the data model for exchange (IODEF) and
> query/reporting capabilities (ROLIE).  We need to tie the three together
> and a document such as this would help lay a foundation for usage in
> multiple areas.
>
> FWIW…
>
> *Kent Landfield*
>
> *McAfee | An Intel Company*
> Direct: +1.972.963.7096
> Mobile: +1.817.637.8026
> *Web: *www.mcafee.com <http://www.mcafee.com/>
>
> From: Sean Turner <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
>         Sorry for the delay in updating the charter.  There is a lot of
>         activity in this space right now as you all know.  I took Sean's
>         suggested content and updated it to reflect some of the activity
>         and drivers for additional work in MILE.  Several people have
>         mentioned an interest in submitting extensions based on their
>         current work, some in virtualized environments, some for
>         indicator specific formats, some industry specific extensions,
>         etc.  There is also work developing by other groups who have
>         mentioned that they will transition their work to an
>         international standards body once it is mature, so room has been
>         left in the charter to accommodate that work.  The need for
>         guidance on the transport options has surfaced so that
>         implementers understand when they may choose a specific
>         transport option to enable interoperable interfaces between
>         products.  The guidance may be use case specific where tighter
>         security is needed (RID +HTTP/TLS with the object level security
>         options enab
>
>     led) or w
>     here ease of access is the driver (ROLIE) with no client
>     requirements necessary (can use a browser).
>
>
>         From: [email-masked] <mailto:[email-masked]>
>         [[email-masked] <mailto:[email-masked]>] On Behalf
>         Of Sean Turner [[email-masked] <mailto:[email-masked]>]
>         To: [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Tue, 4 Jun 2013 14:59:16 +0000

:-) Something told me you would ask that….  ;-)

Let me see if I can find someone to help with it. Volunteers?  I could use some help I am sure.

Kent Landfield

From: Sean Turner <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 4, 2013 7:29 AM
To: Kent Landfield <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mile] re-charter re-boot

spt

On 6/3/13 2:10 PM, [email-masked]<mailto:[email-masked]> wrote:

FWIW…

*Kent Landfield*

From: Sean Turner <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
Date: Monday, June 3, 2013 12:30 PM
To: "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>>
Subject: Re: [mile] re-charter re-boot

     spt

         Hi,

     led) or w

         <intro>

         </intro>

         - Provide guidance on the implementation and use of RID transports
         based on use cases.  The guidance document will show the
         relationship
         between transport options (RID + RID transport and IODEF/RID +
         ROLIE)
         and may identify the need for additional transport bindings.

         - RID may require modifications to address data provenance,
         additional

         <milestones>

         </milestones>

         Thank you!
         Kathleen

         ________________________________________
         From: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
         [[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>] On Behalf
         Of Sean Turner [[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>]
         Sent: Wednesday, May 01, 2013 9:04 PM
         To: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
         Subject: [mile] re-charter re-boot

         Hi,

         I'd like to propose a significant re-write of the proposed
         charter.  I
         think there's too much history that's not really needed any more and
         there's some repetition that's unneeded.  I also think it's a little
         open ended wrt what's actually going to get done. Based on recent
         experience, I have a strong feeling that the current charter
         wouldn't
         get through the process.

         The intro should:

         Then we talk about what drafts the WG will produce for the two
         topic areas.

         <intro>

         </into>

         Questions:

         Is there going to only be one 5070bis draft or will there be a
         5070bis +
         other optional extension drafts?  I assume it's just a 5070bis
         based on
         the milestones but thought I'd ask.

         Are we only extending IODEF based on use or is there something
         else we
         need to consider?

         How about something along the lines of (need some help filling
         in the
         blanks):

         <iodef>

         </iodef>

         For RID:

         <rid>

         </rid>

         <milestones>

         </milestones>

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

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

---

From: Eric Burger <[email-masked]>
Date: Tue, 4 Jun 2013 15:28:10 -0400

It will take more than a week :-)

On Jun 4, 2013, at 10:59 AM, [email-masked] wrote:

> Web: www.mcafee.com
> From: Sean Turner <[email-masked]>
> To: Kent Landfield <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>

---

From: Sean Turner <[email-masked]>
Date: Tue, 04 Jun 2013 16:40:57 -0400

Well unless I'm hearing any violent objections I think adding it would 
make sense actually.  It's also an easy for somebody who is using this 
technology to get their feet wet in the WG.

spt

On 6/4/13 10:59 AM, [email-masked] wrote:
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
>     On 6/3/13 2:10 PM, [email-masked]
>     <mailto:[email-masked]> wrote:
>
>         From: Sean Turner <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]>>
>         To: "[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]>>
>                   From: [email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]>
>                   [[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]>] On Behalf
>                   Of Sean Turner [[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]>]
>         <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 4 Jun 2013 22:24:09 +0000

The charter looks good to me.

Kent,
A clarification. Would the doc you are suggesting be different of what Kathleen had in the charter "Provide guidance on the implementation and use of RID transports
based on use cases.  The guidance document will show the relationship between transport options (RID + RID transport and IODEF/RID + ROLIE) and may identify the need for additional transport bindings." Or did you have something similar in mind?

Rgs,
Panos

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, June 03, 2013 2:10 PM
To: [email-masked]; [email-masked]
Subject: Re: [mile] re-charter re-boot

FWIW...

Kent Landfield

spt

<intro>

</intro>

<milestones>

</milestones>

Thank you!
Kathleen

Hi,

The intro should:

<intro>

</into>

Questions:

<iodef>

</iodef>

For RID:

<rid>

</rid>

<milestones>

</milestones>

spt

---

From: <[email-masked]>
Date: Tue, 4 Jun 2013 23:14:51 +0000

Hi Panos,

I was expecting that to be more of a proper use of the specifications and specification integration document and not an overview of the higher level uses cases of the area these protocols are supporting.  If I am wrong then I would love to hear it.  If someone has volunteered to be the author for that mile(stone) could they please clarify?  If what I am considering is already covered then I am good. ;-)

Kent Landfield

From: "Panos Kampanakis (pkampana)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 4, 2013 5:24 PM
To: Kent Landfield <[email-masked]<mailto:[email-masked]>>, Sean Turner <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [mile] re-charter re-boot

Kent,
A clarification. Would the doc you are suggesting be different of what Kathleen had in the charter “Provide guidance on the implementation and use of RID transports
based on use cases.  The guidance document will show the relationship between transport options (RID + RID transport and IODEF/RID + ROLIE) and may identify the need for additional transport bindings.” Or did you have something similar in mind?

Rgs,
Panos

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, June 03, 2013 2:10 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mile] re-charter re-boot

FWIW…

Kent Landfield

spt

<intro>

</intro>

<milestones>

</milestones>

Thank you!
Kathleen

Hi,

The intro should:

<intro>

</into>

Questions:

<iodef>

</iodef>

For RID:

<rid>

</rid>

<milestones>

</milestones>

spt

---

From: Eric Burger <[email-masked]>
Date: Tue, 4 Jun 2013 20:17:47 -0400

What is really missing, but I am not sure it belongs as a work group document, is a requirements document for the protocol and markup itself. The only thing I could find was RFC 3067. However, those were requirements for a specific network operator with specific needs.

On Jun 4, 2013, at 7:14 PM, [email-masked] wrote:

> From: "Panos Kampanakis (pkampana)" <[email-masked]>
> To: Kent Landfield <[email-masked]>, Sean Turner <[email-masked]>, "[email-masked]" <[email-masked]>
>> To: "[email-masked]" <[email-masked]>

---

From: Sean Turner <[email-masked]>
Date: Thu, 06 Jun 2013 13:31:46 -0400

Kent and this dawned on me too last night ... don't let it being a WG 
item stop you or anybody really from writing an individual draft that 
could be considered for wg acceptance.

My plan is to circle the wagons on Monday with the chairs with the use 
case draft as an item and start the re-chartering process.

spt

---

From: <[email-masked]>
Date: Thu, 6 Jun 2013 17:36:15 +0000

Understand. Sounds good to me.

Kent Landfield
McAfee Labs
[email-masked]
+1.817.637.8026 

On Jun 6, 2013, at 12:31 PM, "Sean Turner" <[email-masked]> wrote:

> Kent and this dawned on me too last night ... don't let it being a WG item stop you or anybody really from writing an individual draft that could be considered for wg acceptance.
> 
> My plan is to circle the wagons on Monday with the chairs with the use case draft as an item and start the re-chartering process.
> 
> spt
>

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 7 Jun 2013 10:40:50 -0400

Eric,

I couldn't agree more. It hasn't been clear what the requirements are that the WG is trying to address. I think we need this higher-level requirements document to help crystalize what work the work group needs to accomplish for this re-chartering cycle. Absent that, I don't see how we can gauge what enhancements are in scope to make to IODEF and what other protocol modifications/additions are needed.

Sincerely,
Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Burger
Sent: Tuesday, June 04, 2013 8:18 PM
To: [email-masked] IETF
Subject: Re: [mile] re-charter re-boot

On Jun 4, 2013, at 7:14 PM, [email-masked]<mailto:[email-masked]> wrote:

Hi Panos,

Kent Landfield

Kent,

Rgs,
Panos

FWIW...

Kent Landfield

spt

<intro>

</intro>

<milestones>

</milestones>

Thank you!
Kathleen

Hi,

The intro should:

<intro>

</into>

Questions:

<iodef>

</iodef>

For RID:

<rid>

</rid>

<milestones>

</milestones>

spt

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Fri, 7 Jun 2013 10:44:54 -0400

Hi,

The intent of the text that Panos pointed out was the same as what Kent described.  Does the text need to be adjusted?  Any suggestions?

FYI- I am off this week and may not respond until Monday.

Thanks,
Kathleen

Sent from my iPhone

---

From: <[email-masked]>
Date: Fri, 7 Jun 2013 18:07:42 +0000

The revised draft charter states

  *
Provide guidance on the implementation and use of RID transports
based on use cases.  The guidance document will show the relationship
between transport options (RID + RID transport and IODEF/RID + ROLIE)
and may identify the need for additional transport bindings.

I was looking at an overview document that described an architectural view of the problem and how MILE protocols could be integrated to support the various community uses. In retrospect, if this is what you envisioned, we could incorporate this into the document.  Guidance of implementation targeted at RID does not sound like what I was thinking about.  I volunteer to be a part of the document's development if it makes sense to incorporate the larger perspective. If not, we can make it a separate document.

Kent Landfield

From: <Moriarty>, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 7, 2013 9:44 AM
To: Kent Landfield <[email-masked]<mailto:[email-masked]>>
Cc: Sean Turner <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mile] re-charter re-boot

Hi,

Thanks,
Kathleen

Sent from my iPhone

On Jun 6, 2013, at 1:40 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Kent Landfield
McAfee Labs
[email-masked]<mailto:[email-masked]>
+1.817.637.8026

On Jun 6, 2013, at 12:31 PM, "Sean Turner" <[email-masked]<mailto:[email-masked]>> wrote:

spt

spt

On 6/4/13 10:59 AM, [email-masked]<mailto:[email-masked]> wrote:
:-) Something told me you would ask that….  ;-)

Let me see if I can find someone to help with it. Volunteers?  I could
use some help I am sure.

*Kent Landfield*

From: Sean Turner <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
Date: Tuesday, June 4, 2013 7:29 AM
To: Kent Landfield <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>>
Subject: Re: [mile] re-charter re-boot

   spt

   On 6/3/13 2:10 PM, [email-masked]<mailto:[email-masked]>
   <mailto:[email-masked]> wrote:

       I have no problem with the revised charter as is but I think
       there is
       something missing.  It would be good to have as a milestone a
       document
       that described use cases for these protocols.  I rather see this
       separated out since we are in a situation now of addressing the
       transport (RID) , the data model for exchange (IODEF) and
       query/reporting capabilities (ROLIE).  We need to tie the three
       together
       and a document such as this would help lay a foundation for
usage in
       multiple areas.

       FWIW…

       *Kent Landfield*

       From: Sean Turner <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
       <mailto:[email-masked]>>
       Date: Monday, June 3, 2013 12:30 PM
       To: "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
       <mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
       <mailto:[email-masked]>>
       Subject: Re: [mile] re-charter re-boot

             spt

                 Hi,

                 Sorry for the delay in updating the charter.  There is
       a lot of
                 activity in this space right now as you all know.  I
       took Sean's
                 suggested content and updated it to reflect some of
       the activity
                 and drivers for additional work in MILE.  Several
       people have
                 mentioned an interest in submitting extensions based
       on their
                 current work, some in virtualized environments, some
for
                 indicator specific formats, some industry specific
       extensions,
                 etc.  There is also work developing by other groups
       who have
                 mentioned that they will transition their work to an
                 international standards body once it is mature, so
       room has been
                 left in the charter to accommodate that work.  The
       need for
                 guidance on the transport options has surfaced so that
                 implementers understand when they may choose a specific
                 transport option to enable interoperable interfaces
       between
                 products.  The guidance may be use case specific where
       tighter
                 security is needed (RID +HTTP/TLS with the object
       level security
                 options enab

             led) or w

                 We will follow up with the mile stones, here the the
       re-write:

                 <intro>

                 The Managed Incident Lightweight Exchange (MILE)
       working group
                 develops standards to support computer and network
       security
                 incident management; an incident is an unplanned event
       that
                 occurs in an information technology (IT)
       infrastructure. An
                 incident could be a benign configuration issue, IT
       incident, an
                 infraction to a service level agreement (SLA), a system
                 compromise, socially engineered phishing attack, or a
                 denial-of-service (DoS) attack, etc.  When an
incident is
                 detected, or suspected, there may be a need for
       organizations to
                 collaborate. This collaboration effort may take
       several forms
                 including joint analysis, information dissemination,
       and/or a
                 coordinated operational response.  Examples of the
       response may
                 include filing a report, notifying the source of the
       incident,
                 requesting that a third party resolve/mitigate the
       incident,
                 sharing select indicators of compromise, or requesting
       that the
                 source be located. By sharing indicators of compromise
       associated
                 with an incident or possible threat, the information
       becomes a
                 proactive defense for others that may include
       mitigation options.
                 The Incident Object Description Exchange Format
       (IODEF) defines
                 an information framework to represent computer and
network
                 security incidents; IODEF is defined in RFC 5070 and
                 has been extended by RFC 5091 to support phishing
       reports; RFC
                 6484 provides a template for defining extensions to
IODEF.
                 Real-time Inter-network Defense (RID) defines a
       protocol to
                 facilitate sharing computer and network security
       incidents;
                 RID is defined in RFC 6545, and RID over HTTPS is
       defined in RFC
                 6546.

                 </intro>

                 The MILE WG is focused on two areas, IODEF the data
       format and
                 extensions to represent incident and indicator data
       and RID,
                 the policy and transport for structured data.  With
       respect to
                 IODEF, the working group will:

                 - Revise the IODEF document to incorporate
       enhancements and
                 extensions based on operational experience; use by
       Computer
                 Security Incident Response Teams (CSIRTs) and others
has
                 exposed the need to extend IODEF to support industry
       specific
                 extensions, use case specific content, and
       representations to
                 associate information related to represented threats
       (system,
                 threat actors, campaigns, etc.).  The value of
information
                 sharing has been demonstrated and highlighted at an
       increasing
                 rate through the success of the Information Sharing and
                 Analysis Centers (ISACs) and the recent cyber security
       Executive
                 Order in the US.  International groups, such as the
       Multinational
                 Association for Collaborative Cyber Situational
       Awareness (CCSA)
                 have been running experiments to determine what data
       is useful to
                 exchange between industries and nations to effectively
       mitigate
                 threats.  The work of these and other groups have
       identified or
                 are working to develop data representations relevant
       to their use
                 cases that may compliment/extend IODEF or be useful to
       exchange
                 using RID and related transport protocols.

                 - Provide guidance on the implementation and use of
       IODEF to aid
                 implementers in developing interoperable
specifications.

                 - Define a resource-oriented approach to cyber security
                 information sharing that follows the REST
       architectural style.
                 This mechanism will allow CSIRTS to be more dynamic
       and agile in
                 collaborating with a broader, and varying constituency.

                 - Provide guidance on the implementation and use of
       RID transports
                 based on use cases.  The guidance document will show
the
                 relationship
                 between transport options (RID + RID transport and
       IODEF/RID +
                 ROLIE)
                 and may identify the need for additional transport
       bindings.

                 - RID may require modifications to address data
       provenance,
                 additional
                 policy options, or other changes now that there are
       multiple
                 interoperable implementations of RFC6545 and
       RFC6546.  With the
                 RID implementations in the open source community,
       increased use and
                 experimentation may demonstrate the need for a
revision.

                 <milestones>

                 </milestones>

                 Thank you!
                 Kathleen

                 ________________________________________
                 From: [email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]> <mailto:[email-masked]>
                 [[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
       <mailto:[email-masked]>] On Behalf
                 Of Sean Turner [[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]> <mailto:[email-masked]>]
                 Sent: Wednesday, May 01, 2013 9:04 PM
                 To: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
       <mailto:[email-masked]>
                 Subject: [mile] re-charter re-boot

                 Hi,

                 I'd like to propose a significant re-write of the
proposed
                 charter.  I
                 think there's too much history that's not really
       needed any more and
                 there's some repetition that's unneeded.  I also think
       it's a little
                 open ended wrt what's actually going to get done.
       Based on recent
                 experience, I have a strong feeling that the current
       charter
                 wouldn't
                 get through the process.

                 I'm proposing four sections: intro, iodef-related
       work, rid-related
                 work, milestones.

                 The intro should:

                 - explain what the WG does: develop standards to do
foo.
                 - summarize what foo is.
                 - highlight existing RFCs that are part of the space:
                       IODEF: 5070/5091/6848 & RID: 6545/6546.

                 Then we talk about what drafts the WG will produce for
       the two
                 topic areas.

                 <intro>

                 The Managed Incident Lightweight Exchange (MILE)
       working group
                 develops standards to support computer and network
       security
                 incident management; an incident is an unplanned event
       that
                 occurs in an information technology (IT)
       infrastructure. An
                 incident could be a benign configuration issue, IT
       incident, an
                 infraction to a service level agreement (SLA), a system
                 compromise, socially engineered phishing attack, or a
                 denial-of-service (DoS) attack, etc.  When an
incident is
                 detected, or suspected, there may be a need for
       organizations to
                 collaborate. This collaboration effort may take
       several forms
                 including joint analysis, information dissemination,
       and/or a
                 coordinated operational response.  Examples of the
       response may
                 include filing a report, notifying the source of the
       incident,
                 requesting that a third party resolve/mitigate the
       incident,
                 sharing indicators of compromise, or requesting that
       the source
                 be located. The Incident Object Description Exchange
       Format
                 (IODEF) defines an information framework to represent
       computer
                 and network security incidents; IODEF is defined in
       RFC 5070 and
                 has been extended by RFC 5091 to support phishing
       reports; RFC
                 6484 provides a template for defining extensions to
IODEF.
                 Real-time Inter-network Defense (RID) defines a
       protocol to
                 facilitate sharing computer and network security
       incidents;
                 RID is defined in RFC 6545, and RID over HTTPS is
       defined in RFC
                 6546.

                 </into>

                 This working group does two things IODEF and RID; we
       should be clear
                 about that and then list the actual documents we're
       going to produce
                 that relate to each one.  For the list of deliverables
       it looks like
                 there's three 5070bis, a reference/guidance draft,
and a
                 resource-oriented indicator exchange?

                 Questions:

                 Are the GRC and Forensic drafts dead-dead?  I assume
       they'd not be
                 included in the milestone list.

                 Is there going to only be one 5070bis draft or will
       there be a
                 5070bis +
                 other optional extension drafts?  I assume it's just a
       5070bis
                 based on
                 the milestones but thought I'd ask.

                 Are we only extending IODEF based on use or is there
       something
                 else we
                 need to consider?

                 How about something along the lines of (need some help
       filling
                 in the
                 blanks):

                 <iodef>

                 - Revise the IODEF document to incorporate
       enhancements and
                 extensions based on operational experience; use by
       Computer
                 Security Incident Response Teams (CSIRTs) and others
has
                 exposed the need to extend IODEF to support x, y, z
       (need to have
                 some idea what's missing) base on a, b, c (need to
       know a bit
                 more about why stuff is missing did something new pop
       up?).

                 - Provide guidance on the implementation and use of
       IODEF to aid
                 implementers in developing interoperable
specifications.

                 </iodef>

                 For RID:

                 Are we also doing defining guidance for RID as well or
       is that
                 incorporated in the IODEF guidance?

                 Is RID itself going to be untouched and we're just
       producing a new
                 "transport"?

                 Is it just for indicators or is it for the whole
       incident?  Or has
                 "indicators" over taken "incident"?

                 <rid>

                 - Define a resource-oriented approach to cyber security
                 information sharing that follows the REST
       architectural style.
                 This mechanism will allow CSIRTS to be more dynamic
       and agile in
                 collaborating with a broader, and varying constituency.

                 </rid>

                 <milestones>

                 These looked fine, but I'd like some actual dates for
       the TBDs ;)

                 </milestones>

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

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

---

From: John Field <[email-masked]>
Date: Fri, 7 Jun 2013 14:54:26 -0400

I agree with Panos that the text we have in the draft charter provides the
right initial context, but Kent and David have a point, and there is never
any harm in getting even more specific.   Referring back to the current
draft charter text, we've recently added the following sentences into the
intro section....

"When an incident is detected, or suspected, there may be a need for
organizations to
collaborate. This collaboration effort may take several forms including
joint analysis,
information dissemination, and/or a coordinated operational response".

I think this does identify the core use cases, and could serve as the basis
of elaborating more detailed requirements.   When I first started thinking
about the ROLIE draft, I was motivated by the differences I saw in the
requirements for these three aspects, or use cases:

- cross-organization cyber information sharing
- cross-organization joint analysis
- cross-organization joint operational response

Here is a really quick "swag" at how these might differ in requirements:

- cross-organization information sharing (i.e. essentially a write-only
operation)
   -- requirements:
         -- minimize resource consumption on provider side, to encourage
broad support/participation.
         -- enable easy support for opt-in eventing, and historical inquiry
         -- allow support for multiple schemas, multiple representations,
e.g. for format, or redaction....
         -- support individual user-based AAA, avoiding inter-org trust
management....

- cross-organization collaboration for purposes of performing joint
analysis (i.e. essentially asynchronous read-write)
   -- requirements:
       -- minimize latency
       -- enable support for continued use of existing analyst
tools/workbenches
       -- leverage existing org-to-org trust relationships, if present
       -- support for communities of interest / distribution groups

- cross-organization collaboration for purposes of conducting a joint
operational response.  (i.e. essentially synchronous read-write)
    --requirements
        -- integrity and confidentiality assurance essential
        -- full support for org-to-org trust management.
        -- support positive/negative acknowledgement
        -- support explicit prioritization

Of course, this is just "shooting from the hip".  But, if we look at the
use case problem in this way, that may help us to scope things
appropriately, and enumerate specific requirements for each use case, or
provide guidance on what combinations of message formats and protocols are
optimal for each situation.  This would not be appropriate for the charter,
but could be covered in a separate document, as alluded to by Kent, and
(IIRC) Eric.

HTH.

Regards,
John

On Fri, Jun 7, 2013 at 10:44 AM, Moriarty, Kathleen <
[email-masked]> wrote:

> Hi,
>
> The intent of the text that Panos pointed out was the same as what Kent
> described.  Does the text need to be adjusted?  Any suggestions?
>
> item stop you or anybody really from writing an individual draft that could
> be considered for wg acceptance.
> >>

-- 

John P. Field | Security Architect | Pivotal

Direct: (908) 962-3394 | [email-masked]

**
*goPivotal.com <http://www.goPivotal.com>*