2.7.4 Extended Incident Handling (inch)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-09-20

Chair(s):

Roman Danyliw <rdd@cert.org>

Security Area Director(s):

Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Sam Hartman <hartmans-ietf@mit.edu>

Mailing Lists:

General Discussion: inch@nic.surfnet.nl
To Subscribe: listserv@nic.surfnet.nl
In Body: subscribe inch
Archive: http://listserv.surfnet.nl/archives/inch.html

Description of Working Group:

Background
==========

Computer security incidents occur across administrative domains often
spanning different organizations and national borders. Therefore, the
exchange of incident information and statistics among involved parties
and associated Computer Security Incident Response Teams (CSIRTs) is
crucial for both reactionary analysis of current intruder activity and
proactive identification of trends that can lead to incident
prevention.

Scope
=====

The purpose of the Incident Handling (INCH) working group is to define
a data format for exchanging security incident information used by a
CSIRT. A CSIRT is defined broadly as an entity (either a team or
individual) with a security role or responsibility for a given
constituency (e.g., organization, network).

The use case for the INCH WG output is to standardize the information
model and messaging format currently used in communication between a
CSIRT and the:

* constituency (e.g., users, customers) from which it receives reports
of misuse;

* other parties involved in an incident (e.g., technical contact at an
attacking site, other CSIRTs); and

* analysis centers performing trending across broad data-sets.

These INCH developed formats will replace the now largely human-
intensive communication processes common in incident handling. The
working group will address the issues related to representing and
transporting:

* the source(s) and target(s) of system misuse, as well as the
analysis of their behavior;

* the evidence to support this analysis;

* status of an incident investigation and analysis process; and

* meta-information relevant to sharing sensitive information across
administrative domains (e.g., internationalization, authorization,
privacy).

Constraints
===========

The WG will not attempt to define

- - an incident taxonomy;
- - an archive format for incident information;
- - a format for workflow process internal to a CSIRT; or
- - a format for computer security related information for which there
is already a working standard.

Output of Working Group
=======================

1. A set of high-level requirements for a data format to represent
information commonly exchanged by CSIRTs.

2. A specification of an extensible, incident data description language
that describes a format that satisfies these requirements (Output #1).

3. A set of sample incident reports and their associate representation
in the incident data language.

4. A message format specification and associated transport binding to
carry the encoded description of an incident (Output #2).

5. Guidelines for implementing the data format (Output #2) and
associated communications (Output #4)

Goals and Milestones:

Done  Initial I-D of the incident data language specification
Done  Initial I-D for the requirements specification
Done  Initial I-D of the implementation guidelines document
Done  Initial I-D of the traceback extension specification
Done  Submit initial draft of phishing extension specification I-D
Dec 2005  Submit requirements I-D to the IESG as Informational
Dec 2005  Submit incident data language specification I-D to the IESG as Proposed
Dec 2005  Submit traceback extension specification I-D to the IESG as Proposed
Dec 2005  Submit phishing extension specification I-D to the IESG as Proposed
Feb 2006  Submit implementation guidelines I-D to the IESG as Informational

Internet-Drafts:

  • draft-ietf-inch-iodef-04.txt
  • draft-ietf-inch-requirements-05.txt
  • draft-ietf-inch-rid-05.txt
  • draft-ietf-inch-phishingextns-02.txt

    No Request For Comments

    Current Meeting Report

     
    Extended Incident Handling (INCH) WG Minutes
IETF 64
Wednesday, November 9, 2005, 13.00-15.00
Vancouver, Canada

     Chair: Roman Danyliw 
AD Adviser: Sam Hartman 

---[ Agenda ]-----------------------------------------------------------

  o Administrative              
    (Roman Danyliw, 5 min)

  o Requirements draft review (draft-ietf-inch-requirements-05)
    (Glenn Keeni-Mansfield -- proxy presentation, 5 min)

  o Data Model draft review (draft-ietf-inch-iodef-05)
    (Roman Danyliw, 25 min)

  o Implementation guide draft (draft-ietf-inch-implement-01)
    (Roman Danyliw, 2 min)

  o RID draft review (draft-ietf-inch-rid-05)
    (Kathleen Moriarty, 20 min)

  o Transport draft review (draft-ietf-inch-soap-01)
    (Brian Trammell, 10 min)

  o Phishing extension draft review (draft-ietf-inch-phishingextns-02)
    (Pat Cain -- proxy presentation, 5 min)

---[ Administrative ]---------------------------------------------------

presentation: 

Roman Danyliw presented a summary of the INCH working group.

o Updates to the schedule were made to reflect a slight slippage in 
  the delivery dates (WG last-call) of the following WG draft:

 ] Nov 05  Submit requirements I-D to the IESG as Informational


---[ Requirements ]-----------------------------------------------------

    document: draft-ietf-inch-requirements-05

An -05 version of the requirements draft was produced shortly 
after IETF63.  Minor changes are still required in the security 
requirements to ensure that the messaging format and transport 
binding are considered.  A new draft should be available in
about a week at which point the document can enter WG last call.


---[ Data Model ]-------------------------------------------------------

    document: draft-ietf-inch-iodef-05
presentation: 

Roman Danyliw reviewed the updates that were made to the 
data model in the new -05 draft.  A major effort was made to 
uncover inconsistencies between the Schema and UML description.
In this new revision, issues related to internationalization
and those brought up by implementers were also addressed.  Only
two technical issues remain and the intent is to address them
aggressively.

Comments: none


---[ Implementation Guide draft ]---------------------------------------

    document: draft-ietf-inch-implement-01 (now expired)

Roman Danyliw reported that no changes have been made to the 
implementation draft pending resolution on transport and data model 
issues.

---[ RID draft ]--------------------------------------------------------

    document: draft-ietf-inch-rid-05
presentation: 

Kathleen Moriarty reviewed the latest -05 draft of RID which
largely reflects changes made to complement updates to the 
data model.  Other than continuing to track changes in IODEF, 
the draft is complete.

Comments: none


---[ SOAP Binding draft ]-----------------------------------------------

presentation: 
    document: draft-moriarty-soap-01

Brian Trammell presented an updated version (-01) of an individual 
draft that provides a SOAP transport binding to RID and IODEF.

Given a generalized messaging format (RID) and this associated 
transport binding (SOAP), the AD agreed to now accept a proposal
to re-charter the WG that include transport issues.  Draft language
for the charter update will be provided by the WG chair.

Comments:

AD: Mention the need for confidentiality as the justification for 
requiring TLS.

---[ Phishing Extensions draft ]----------------------------------------

presentation: 
    document: draft-ietf-inch-phishingextns-02

Minor technical and editorial changes were made to the IODEF 
Phishing extension.

Comments:

o An XForm generator for phishing IODEF message can be found at
  http://coopercain.com/incidents/index.htm

    Slides

    Administrative
    Data Model (IODEF) Review
    Message Format (RID) Review
    Transport Binding (SOAP)
    Phishing extension to the IODEF