Re: [mile] re-charter re-boot

["Waltermire, David A." <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Eric Burger
Sent: Tuesday, June 04, 2013 8:18 PM
To: [e-mail] IETF
Subject: Re: [mile] re-charter re-boot

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, [e-mail]<mailto:[e-mail]> wrote:


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

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

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

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Monday, June 03, 2013 2:10 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [mile] re-charter re-boot

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: [phone]
Web: www.mcafee.com<http://www.mcafee.com/>

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

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: [e-mail]<mailto:[e-mail]> [[e-mail]<mailto:[e-mail]>] On Behalf Of Sean Turner [[e-mail]<mailto:[e-mail]>]
Sent: Wednesday, May 01, 2013 9:04 PM
To: [e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mile

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

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