2.6.2 Extended Incident Handling (inch)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-10

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.


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 with a security role or responsibility in a given organization. Often there is a communication and collaborating component. Organizationally, a CSIRT might be a dedicated team in a network operations group, or a single individual with other responsibilities.

The primary use case for the INCH work is to standardize the the communication between a CSIRT and:

* its constituency (e.g., users, customers) reporting misuse;

* parties involved in an incident (e.g., law enforcement, attacking site); or

* peer CSIRTs sharing information.

In doing such sharing, especially when action is being requested, due attention must be paid to authorization and privacy issues.

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 59 - Thursday, 13.00-15.00, March 4, 2004
    Seoul, Korea
                   Chair: Roman Danyliw <rdd@cert.org>
    Security Area Adviser: Steven Bellovin 
    ---[ Agenda 
     o Administrative
     o Implementation
         - Implementation Guide draft 
           (Roman Danyliw)
         - "Three class based models of traceback systems between ASs"
           (Naohiro Fukuda)
         - "Early Experience from the JPCERT/CC IODEF Activity"
           (Huroyuki Kido,  Gleen Keeni-Mansfield)
     o Requirements draft review 
       (Glenn Keeni-Mansfield)
     o Data Model draft review (draft-ietf-inch-iodef-02)
       (Roman Danyliw)
     o Extensions
         - DDOS RID draft review 
           (Kathleen Moriarty)
    ---[ Administrative 
    o Updates to the schedule were made to reflect a slight slippage in the 
    delivery dates (WG last-call) of the WG drafts.
    ] done      Initial I-D of the implementation guidelines document
    ] APR 04    Submit requirements I-D to the IESG as Informational
    ] AUG 04    Submit incident data language specification I-D to the IESG as 
    Proposed Standard
    ] AUG 04    Submit distributed denial of service extension 
    specification I-D to the IESG as Proposed Standard
    ] OCT 04    Submit implementation guidelines I-D to the IESG as 
    ---[ Implementation Guide draft 
       document: draft-ietf-inch-implement-00
    Roman Danyliw presented on the newly written IODEF implementation draft. It 
    remains a work in progress.  There are a number of areas in the 
    document that highlight where further specification from the WG is 
    Comments and Questions:
    o Specific guidelines and examples must be given for generating 
    globally unique identifiers as required by the id attribute of the 
    IODEF-Description class.
    o Examples of IODEF documents using XML-Encryption and 
    XML-Signature will be necessary.
    o One of the issues identified in the draft was the need to clarify the 
    technique to perform updates to existing incidents.  The described use case 
    was the situation where there is follow-up information about an 
    incident after an IODEF document has already been sent.
        o The question of whether document updates were currently being done was 
    posed by the WG.  No one in the WG current uses these kind of 
    communication.  The open question then remains do we need to support it?
        o Given that no one is using document updates, it was suggested that 
    additional operational experience might dictate the 
    implementation path.  The consensus of the mailing list needs to be 
    ---[ Implementation Experience #1 
    Naohiro Fukuda presented on "Three class based models of traceback 
    systems between ASs" to discuss a practical implementation of the RID 
    ---[ Implementation Experience #2 
    Huroyuki Kido and Gleen Keeni-Mansfield presented on "Early 
    Experience from the JPCERT/CC IODEF Activity".
    ---[ Requirements 
       document: draft-ietf-inch-requirements-02
    Glenn Mansfield Keeni reported that the requirements draft is 
    complete, and ready for WG last call.
    Comments and Discussion:
     o A grammatical review of the document is necessary.
     o The use of SHOULD and MUST needs to be evaluated in the 
    ---[ Data Model 
       document: draft-ietf-inch-iodef-02
    Roman Danyliw presented a review of the open issues related to the 
    current data model.
    Comments and Discussion:
     o An alternate to using domain names to uniquely identify CSIRTs in name 
    attribute of the IncidentID class was proposed: use registry handle.
     o The WG was polled and there was consensus to both simplify the 
    existing data model (e.g., moving legacy IDMEF constructs), and and 
    support a flow relationships between hosts.
       A straw man proposal has been posted to the mailing list.
       This is a newly raised, complex issue that will require 
    significant further discussion on the mailing list.
     o The representation for AS numbers should be done in conjunction to the 
    new simplified model.  AS number support is required for the RID draft.
     o Consensus was reached to standardize the extension classes with the 
    proposal at 
    xe?A2=ind04&L=inch&F=&S=&P=748.  Any objections from the mailing list?
     o There was no consensus on the type attribute of the extension 
    ---[ RID draft 
       document: draft-moriarty-ddos-rid-06
    Kathleen Moriarty presented on the current status of the RID protocol.
    Comments and Discussion:
     o Separate the transport and data modeling issues into distinct 
    sections of the draft, perhaps even separate documents.
     o Use Reliable Transport for Syslog (RFC 3195) to exchange IODEF 


    Introducing the Implementation Guide
    Three classes based model of traceback system between ASs
    Early Experience from the JPCERT/CC IODEF Activity
    IODEF demonstration
    IODEF Data Model Status
    RID Draft Update Migrating to IODEF