2.6.2 Extended Incident Handling (inch)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-22

Roman Danyliw <rdd@cert.org>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Jeffrey Schiller <jis@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:

Computer security incidents occur across administrative domains often spanning different organizations and national borders. Therefore, the free exchange of incident information and statistics among involved parties and the responsible 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.

There is a substantial amount of related work in this domain in TERENA's TF-CSIRT IODEF working group. The IODEF WG has already defined a set of requirements for exchanging incident information in RFC 3067: "TERENA's Incident Object Description and Exchange Format Requirements" and proposed a data format implementing them in the "Incident Object Description and Exchange Format Data Model and Extensible Markup Language (XML) Document Type Definition" (http://www.terena.nl/task-forces/tf-csirt/iodef/).


The purpose of the Incident Handling (inch) working group is to define data formats for communication between

* a CSIRT and its constituency (e.g., users, customers, trusted reporters) which reports system misuse;

* a CSIRT and parties involved in an incident investigation (e.g., law enforcement, attacking site); and

* collaborating CSIRTs sharing information.

This format will support the now largely human-intensive dimension of the incident handling process. It will represent the product of various incremental data gathering and analysis operations performed by a CSIRT from the time when the system misuse was initially reported (perhaps by an automated system) till ultimate resolution. Specifically, the working group will address the issues related to representing

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

* the evidence to support any analysis results;

* a scheme to document the incident investigation and analysis process; and

* constructs to facilitate the exchange of security information across administrative domains (e.g., internationalization, data sensitivity).

The WG will investigate the information model needed to support the typical, operational workflow of the incident handling processes found at Internet Service Providers; Managed Security Service Providers; Risk Analysis vendors; and traditional, internal CSIRTs.


The WG will not attempt to

- define an incident or address the implications of sharing incident data across administrative domains;

- define a format for computer security related information for which there is already a standard, but where applicable, provide full compatibility (e.g. IDWG's IDMEF, Mitre's CVE); or

- define a protocol for exchanging the incident information.

Output of Working Group

1. A document describing the high-level functional requirements of a data format for collaboration between CSIRTs and parties involved when handling computer security incidents.

2. A specification of the extensible, incident data language that describes the data formats that satisfy the requirements.

3. Guidelines for implementing the WG data format (Output #2 of the WG).

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

Goals and Milestones:
SEP 02  Initial I-D of the implementation guidelines and examples document
DEC 02  Initial I-D of the requirements specification
DEC 02  Submit requirements I-D to the IESG as Informational
DEC 02  Submit incident data language specification I-D to the IESG as Proposed
JAN 03  Submit implementation guidelines I-D to the IESG as Informational
  • - draft-ietf-inch-iodef-00.txt
  • - draft-ietf-inch-iodef-rfc3067bis-requirements-00.txt
  • - draft-ietf-inch-requirements-00.txt
  • No Request For Comments

    Current Meeting Report

    IETF 56 INCH WG Meeting Minutes
    Roman Danyliw <rdd@cert.org>
    Mon, 24 Mar 2003 16:40:37 -0500 (EST)
    Incident Handling (INCH) WG Minutes
    IETF56 - Wednesday 13.00-15.00 March 19, 2003, San Francisco
    Chair: Roman Danyliw <rdd@cert.org>
    ---[ Agenda 
      o Administrative  (Roman Danyliw)
      o Data model requirements (Glenn Mansfield Keeni, Yuri Demchenko)
         - draft-ietf-inch-requirements-00
      o Data Model (Jan Meijer)
         - draft-ietf-inch-iodef-00
      o XML Security in the IODEF (Yuri Demchenko)
    ---[ Administrative 
    presenter: Roman Danyliw
    The status of the deliverables is as follows:
      o A commonly agreed upon initial draft, 
        for the requirements has been completed.  It unifies the two 
        previous drafts (draft-glenn-inch-req-00 and
      o The data model is beginning to stabilize.  An 01 version
        of the draft fully documenting all the proposed changes from 
        IETF55 and Uppsala will be submitted by the end of the month.
    An aggressive schedule has been adopted to bring the WG 
    deliverables to
    last call.  It has been updated as follows:
     ] APR 03    Initial I-D of the implementation guidelines document
     ] SEP 03    Submit requirements I-D to the IESG as Informational
     ] SEP 03    Submit incident data language specification I-D to the 
                 IESG as Proposed Standard
     ] NOV 03    Submit implementation guidelines I-D to the IESG as
    ---[ Requirements 
    presenter: Glenn Mansfield Keeni and Yuri Demchenko
    The co-authors of the new requirements draft introduced the document
    and noted the areas that still need to be addressed in [1] and [2].
    Comments and Discussion:
      o A major area of work is to finish and refine the list of term
        definitions.  It was stressed that we should not reinvent
        new definitions, but use existing work when possible.  A specific
        example of relevant work mentioned was the BCPs published 
        by the now non-existent GRIP WG.  The strategy to complete this
        task is to first create a list of terms that need to be defined,
        and then go about citing or refining the appropriate 
        There was some discussion about whether the use of the term
        "Actor" was appropriate.  Likewise, whether "Damage" is the
        same thing as "Impact".
      o The operational model needs to be simplified to merely include
        CSIRTs in the communication path.  Furthermore, it should be
        noted somewhere in the draft that human security analysts will
        not be direct consumers of an IODEF document; rather, some 
        software will first parse it.  However, incident data, that
        which will be represented in an IODEF document, is typically
        created (or at least aggregated) by a human security analysts
        (i.e., not auto-generated like IDMEF).
      o Since including incident report in the FINE acronym was deemed
        to restrictive,  The FINE acronym should be reworded to expand
        to "Format for INcident data Exchange".
      o The term incident report was used to refer to information
        represented in FINE.  It was considered too restrictive; a more
        general term of "incident data" should be used to refer to the
      o The purpose of FINE (and its implementation, IODEF) was 
        again reiterated to be an exchange format.
    ---[ Data Model 
    presenter: Jan Meijer
    Meijer presented a review of the open issues related to the current
    data model in [3].
    Comments and Discussion:
      o An instance of the IODEF needs to be referred to consistently in
        the draft.  Is it a message, description, or document?
        Discussions suggest that there is least objection to 
        using document (i.e., an instance of the IODEF, is an IODEF 
        Related to this issue is the name of the top-level element of
        the DTD/Schema.  Currently, it is <IODEF-Message>.  There was
        some concern about such a name, because a "message" implies a 
        communications protocol.  The old name for this element,
        <IODEF-Description>, was felt to be un-descriptive.  Consistent 
        with the use of document to refer to an instance of the IODEF, 
        the top level container should be called 
      o When an IODEF document is processed and stored in a
        database, the character-encoding might be lost.  This is 
        in the free-form field <Description>, where retaining the
        encoding is key to later deciphering the text.  An attribute
        should be added to <Description> to note whether the encoding
        should be preserved by the processing incident handling system.
      o Precedence/Priority rules for processing nested restriction 
        attributes needs to be specified in the draft.
      o A clearer description of <IncidentData> and <EventData> is
        necessary in the draft.  For example:
          - the meaning of multiple <EventData>s at the same depth
          - the "rules" for when <EventData> should use it's recursive
            child (i.e., nesting an <EventData> inside an <EventData>
          - the differences in semantics for the classes that are found 
            in both the <IncidentData> and <EventData> (e.g., Method) 
      o Given that the implementation is transport protocol agnostic,
        the operational issues and semantics of an IODEF document that
        is forwarded (like an email message) was questioned.
    ---[ XML Security in the IODEF 
    presenter: Yuri Demchenko
    Demchenko gave a brief overview of XML Signature and Encryption,
    and summarized its impact on the current IODEF data model in [4].
    Comments and Discussion
      o XML Signature is documented in RFC3275
    ---[ Open Discussion 
    o Concerns and suggestions about the IODEF XML implementation with
      regard to internationalization for the Asia-Pacific region were noted.  
      The details are document on the mailing list:


    Requirements for Format for INcident data Exchange (FINE)
    INCH Requirements (2)
    XML Security in IODEF
    Incident Exchange Format (IODEF)