Re: [mile] Updated charter for review

Sean Turner <turners@ieca.com> Tue, 30 April 2013 16:25 UTC

Return-Path: <turners@ieca.com>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A9E21F9A30 for <mile@ietfa.amsl.com>; Tue, 30 Apr 2013 09:25:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level:
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDUkJ2j86FeV for <mile@ietfa.amsl.com>; Tue, 30 Apr 2013 09:25:31 -0700 (PDT)
Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.56.176.23]) by ietfa.amsl.com (Postfix) with ESMTP id A5C3D21F98CA for <mile@ietf.org>; Tue, 30 Apr 2013 09:25:14 -0700 (PDT)
Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 2737A1C5F151B; Tue, 30 Apr 2013 11:25:08 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 1AF801C5F14F6 for <mile@ietf.org>; Tue, 30 Apr 2013 11:25:08 -0500 (CDT)
Received: from [198.180.150.142] (port=50536 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <turners@ieca.com>) id 1UXDMe-0003wh-1i; Tue, 30 Apr 2013 11:25:12 -0500
Message-ID: <517FF065.8050703@ieca.com>
Date: Tue, 30 Apr 2013 10:25:09 -0600
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
References: <F5063677821E3B4F81ACFB7905573F24DA7FE28C@MX15A.corp.emc.com> <F5063677821E3B4F81ACFB7905573F24DA7FE2C9@MX15A.corp.emc.com>
In-Reply-To: <F5063677821E3B4F81ACFB7905573F24DA7FE2C9@MX15A.corp.emc.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: (thunderfish.local) [198.180.150.142]:50536
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 1
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Cc: "mile@ietf.org" <mile@ietf.org>
Subject: Re: [mile] Updated charter for review
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mile>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2013 16:25:37 -0000

I've got a couple of questions:

On 3/26/13 5:59 PM, Moriarty, Kathleen wrote:

..snip

>
> Description of Working Group:
>
>      The Managed Incident Lightweight Exchange (MILE) working group develops
>      standards for the purpose of improving incident and indicator
> information
>      sharing and handling capabilities. The Incident Object
>      Description Exchange Format (IODEF) in RFC5070 and Real-time
> Inter-network
>      Defense (RID) in RFC6045 were developed in the INCH working group by
>      international Computer Security Incident Response Teams (CSIRTs) and
>      industry to meet the needs of a global community interested in sharing,
>      handling, and exchanging incident and indicator information.

When reading this, I need to know when the WG can declare success.  For 
the next item how will that happen and when can we say we're done 
defining enhancements?  Do we need some kind of requirements document to 
say what's being considering for inclusion?

>      The working group will define enhancements and extensions to IODEF
> and RID
>      and provide guidance for applying them.

This I understand, one implementation did foo and one did bar.  Is there 
a list of these somewhere?  Are we planning on doing bake-offs to find 
them out?

>      It will also focus on
> improving the
>      interoperability of existing and new IODEF implementations,

What does this mean and how will this be done?  What are the related 
information sharing standards?

>      and the
>      interoperation of IODEF and its extensions and enhancements with
> related
>      standards for information sharing.

Isn't the last sentence advertising?  I mean the guidance might 
certainly provide guidance if those groups use them, but if not then it 
won't right?  Are members from the communities going to come and speak 
up wrt to whether they think the guidance provided is actually useful?

>      The extensions and guidance
> created by
>      the MILE working group assist with the daily operations of CSIRTs at an
>      organization, service providers, law enforcement, and at the
> national level.

The following makes it seem like we need a document that lists different 
communities and their requirements - no?  Can we give an example of 
another community?

>      The working group has completed Proposed Standard revisions of RID
> (RFC 6545)
>      and RID transport (RFC 6546). This transport was designed to meet
> specific usage
>      requirements of CSIRTs and related industry groups. In order to
> meet different
>      usage requirements for other communities, the working
>      group will consider
>      alternate transport or bindings for RID and IODEF information.

I think we need to move what an incident is earlier, but we'll do that 
after I figure somethings out.

>      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, the response may include
>      simply filing a report, notification to the source of the incident, a
>      request to a third party for resolution/mitigation,

I think we need to define what information sharing is somewhere.  I 
think I know what it means and I bet a lot of people on this list know 
what it means, but I very much doubt some of my fellow ADs will know 
what's it's supposed to be.  How's "information sharing" different than 
submitting a report - I shared some information right?

>      information sharing
>      on identified indicators of compromise,

>      or a request to
>      locate the source.  IODEF defines a data representation that provides a
>      standard format for sharing information commonly exchanged about
>      computer security incidents, which includes indicators with or
> without the
>      relevant context information.

Is there a document that's going to specify what the requirements are 
for the future needs?

>      IODEF will be updated to meet the
> current and
>      future needs, maintaining the built in extensibility, of
> information sharing
>      where indicators with rich context for actionable sharing is provided.
>      RID enables the secure exchange of incident related information in
> an IODEF
>      format providing options for security, privacy, and policy setting.

There's some duplication below that we could work on removing, but 
getting the earlier questions answered first is more important.

>      MILE leverages collaboration and sharing experiences with prior work
>      including the IODEF data model detailed in the IODEF, existing
> extensions
>      to the IODEF for Anti-phishing (RFC5901), and RID (RFC6545,
> RFC6546) for
>      the secure exchange of information.  MILE will also leverage the
> experience
>      gained in using IODEF and RID in operational contexts.
>
>      The MILE working group provides coordination for IODEF and RID
> extensions that
>      improve capabilities for exchanging indicator and incident information.
>      MILE's objectives include the update of IODEF coupled with guidance
> information
>      to enhance interoperability, deployment ease, and applicability to
> current
>      information security data sharing use cases. MILE will also describe a
>      generalization of RID for secure exchange of other
> security-relevant XML
>      formats. MILE will produce additional guidance needed for the
> successful
>      exchange of indicator and incident information for new use cases
> according to policy,
>      security, and privacy requirements. Finally, MILE produced a document
>      template with guidance for defining IODEF extensions to be followed
> when
>      producing extensions to IODEF as appropriate.

Agreed a lesson learned is to include the names of the drafts on which 
your work will be listed, but we really need to include the

>      [Removed laundry list of drafts -- outdated. We should update the
> milestones below as well]
>
> Goals and Milestones:
>
>    Done     - WGLC Real-time Inter-network Defense (RID)
>
>    Done     - WGLC Transport for Real-time Inter-network Defense (RID)
>
>    Done     - Submit Real-time Inter-network Defense (RID) to IESG for
> consideration as Standards Track document
>
>    Done     - Submit Transport Real-time Inter-network Defense (RID) to
> IESG for consideration as Standards Track document
>
>    Done     - WGLC Template for extensions to IODEF
>
>    Done     - WGLC IODEF Extensions in IANA XML Registry
>
>    Apr 2013 - WGLC IODEF Extension to support structured cybersecurity
> information
>
>    Done     - Submit Template for extensions to IODEF to IESG for
> consideration as Informational document
>
>    Done     - Submit IODEF Extensions in IANA XML Registry to IESG for
> consideration as Standards Track document
>
>    Jun 2013 - Submit IODEF Extension to support structured cybersecurity
> information to IESG for consideration as Standards Track document.
>
>    TBD      - WGLC RFC 5070bis
>
>    TBD      - Submit RFC 5070bis to IESG for consideration as a
> Standards Track document
>
>    TBD      - WGLC IODEF Reference Format
>
>    TBD      - Submit IODEF Reference Format to IESG for consideration as
> a Standards Track document
>
>    TBD      - WGLC Resource-Oriented Indicator Exchange
>
>    TBD      - Submit Resource-Oriented Indicator Exchange to IESG for
> consideration as a Standards Track document
>
>    [ old milestone bits below ]
>
>    [no doc]- WGLC IODEF Guidance
>
>    [no doc] - Submit IODEF Extension Labeling for data protection,
> retention, policies, and regulations to IESG for consideration as
> Standards Track document
>
>    [no doc] - Submit WGLC IODEF Guidance to IESG for consideration as
> Informational document
>
>    May 2012 - WGLC GRC Report Exchange [stalled]
>
>    Jun 2012 - Submit GRC Report Exchange to IESG for consideration as
> Standards Track document [stalled]
>
>    Jun 2012 - WGLC Forensics extension [stalled]
>
>    Jul 2012 - Submit IODEF Forensics extension to IESG for consideration
> as Standards Track document [stalled]
>
> *From:*mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] *On Behalf
> Of *Moriarty, Kathleen
> *Sent:* Tuesday, March 26, 2013 4:48 PM
> *To:* mile@ietf.org
> *Subject:* [mile] Updated charter for review
>
> As discussed at the MILE meeting, we need to revise the charter.  Brian
> and I updated the charter and it is attached for review and comment to
> the list.
>
> Thank you in advance!
>
> Best regards,
>
> Kathleen & Brian
>
> [Outdated draft charter deleted]
>
>
>
> _______________________________________________
> mile mailing list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile
>