2.6.2 Extended Incident Handling (inch)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-11-05

Roman Danyliw <rdd@cert.org>
Security Area Director(s):
Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Steven Bellovin <smb@research.att.com>
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:
Done  Initial I-D of the incident data language specification
Done  Initial I-D for the requirements specification
Nov 03  Initial I-D of the implementation guidelines document
Dec 03  Submit requirements I-D to the IESG as Informational
Dec 03  Submit incident data language specification I-D to the IESG as Proposed
Mar 04  Submit implementation guidelines I-D to the IESG as Informational
  • - draft-ietf-inch-iodef-02.txt
  • - draft-ietf-inch-requirements-02.txt
  • No Request For Comments

    Current Meeting Report

    Extended Incident Handling (INCH) WG Minutes
    IETF 58 - Thursday, 13.00-15.00, November 13, 2003
    Minneapolis, USA
                    Chair: Roman Danyliw <rdd@cert.org>
    Security Area Adviser: Steven Bellovin 
    ---[ Agenda 
      o Administrative
          - WG issues
          - status of the drafts
      o Implementation
          - CERT/CC: libair
          - eCSIRT.net: ihsh
          - JPCERT/CC: IODEF verifier
      o Potential related work
          - draft-moriarty-ddos-rid-05
      o Requirements Review 
          - draft-ietf-inch-requirements-02
      o Data Model Review 
          - draft-ietf-inch-iodef-02
    ---[ Administrative 
    o rfc3067-bis draft dropped in favor of 
    o Updates to the schedule were made to reflect a slight slippage in the 
    delivery dates (WG last-call) of the WG drafts.
     ] NOV 03    Initial I-D of the implementation guidelines document
     ] DEC 03    Submit requirements I-D to the IESG as Informational
     ] FEB 03    Submit incident data language specification I-D to the IESG as 
    Proposed Standard
     ] MAR 04    Submit implementation guidelines I-D to the IESG as 
    o Future Direction of the WG
         o IODEF exchange protocol
         o Interoperability testing
         o Is IODEFa generic framework?  How to handle extensions?
    ---[ Implementation 
    There are at least four implementation of IODEF being used for various 
    projects.  The authors of three IODEF implementations presented status 
    updates on their efforts.
      o CERT/CC: libair  (Roman Danyliw)
      o eCSIRT.net: ihsh  (Roman Danyliw for Arne Helme)
      o JPCERT/CC: IODEF verifier (Hiroyuki Kido)
    Note: XML-IODEF (in CPAN) of JANET-CERT is the fourth 
    ---[ Related Work 
    Kathleen Moriarty presented on RID-DoS (Real-time Inter-network Defense 
    against Denial of Server Attacks), a protocol for network peers to 
    exchange information during a DoS (see 
    Comments and Discussion:
    The proposal of this work prompted a larger discussion of the scope of the 
    working group.  With this draft and the current implementation results, 
    interest in expanding the data model and providing an exchange protocol was 
    Several approaches were discussed as to how to expanding the scope of the 
    data model.  However, the clear consensus was that the community needs an 
    unchanging model to allow adoption.  Hence, the existing data model draft 
    should be published as is.  With regard to the desire to add RID or 
    statistics to IODEF, separate WG drafts would be accepted.  These drafts 
    would be extensions of the current IODEF data-model making using of the 
    <AdditionalData> element.
    Updating of the WG charter will be required to support this extension 
    drafts.  Text was submitted to the AD to this effect shortly after the 
    Consensus on designing (or adopting) an exchange protocol was not 
    present.  Further discussion about taking on this work (and 
    re-chartering) is required.
    ---[ Requirements 
    Glenn Mansfield Keeni and Yuri Demchenko prepared a presentation to 
    address the major changes since the 01 draft of the requirement draft 
    (draft-ietf-inch-requirements-02).  It is the feeling of the authors that 
    this draft should be ready for WG last call in December 2003.
    Comments and Discussion:
      o The use of SHOULD and MUST needs to be evaluated in the 
    ---[ Data Model 
    Jan Meijer presented a review of the open issues related to the current 
    data model (draft-ietf-inch-iodef-02).  The most significant change to the 
    draft will be the conversion of the DTD to an XML Schema.
    Comments and Discussion:
      o Continued investigation into XML-Signature will be required
      o While the use of XML Schema is not an IETF requirement, it should be 
    adopted regardless
      o Once the Schema is complete, the use of the IETF designated 
    XML-Doctors, and other XML experts is desirable
      o The use of terms defined in the requirements document should be 
    consistent with the data model 


    eCSIRT.net Common Language Specification
    IHSH A Small LibAir-based IODEF tool
    Introduction for IODEF Verifier in JPCERT/CC
    RID-DoS: Real-time Inter-network Defense Against Denial of Service Attacks
    INCH Requirements
    INCH IODEF Data Model Review