Subject: [mile] re-charter re-boot

From: Sean Turner <[email-masked]>
Date: Wed, 01 May 2013 19:04:35 -0600

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

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 2 May 2013 17:56:48 -0400

Sean,

Thank you for the detailed review!

We also have the enumeration and SCI drafts as part of MILE.  I have heard from users of IODEF that some extensions may be needed.  We may need to keep the option open for extensions to come in as the current plan is for IODEF to exchange only the most commonly used indicators, then extend out when something more specific is needed to meet the needs of a use case.  The extension may be through an extension draft or another standard that is referenced in the IANA registry for the SCI draft.

I am not sure if GRC-Exchange and the Forensic drafts are dead or were on a break and soon to be revived.  :-)

We have tested interoperability between at least 2 implementations of RID now and there was errata filed to correct a couple of small issues, so I am not sure if guidance is needed.  However, an XMPP binding is desired by a few groups over RID.  That may require a binding draft.

Thank you,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Wednesday, May 01, 2013 9:05 PM
To: [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]
https://www.ietf.org/mailman/listinfo/mile

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Sat, 25 May 2013 09:11:05 -0400

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 enabled) or where 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 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,

The intro should:

<intro>

</into>

Questions:

<iodef>

</iodef>

For RID:

<rid>

</rid>

<milestones>

</milestones>

spt