Current Meeting Report
Slides


2.6.1 Extended Incident Handling (inch)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 08/16/2002

Chair(s):
Roman Danyliw <rdd@cert.org>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Steve 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:
Background

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/).

Scope

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.

Constraints

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
No Current Internet-Drafts
No Request For Comments

Current Meeting Report

Incident Handling (INCH) WG Minutes
IETF55 - Thursday 13.00-15.00 November 21, 2002, Atlanta

Chair: Roman Danyliw <rdd@cert.org>

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

 o Administrative  (Roman Danyliw)

 o Data model requirements (Glenn Mansfield Keeni, Yuri Demchenko)
    - draft-glenn-inch-req-00
    - 
draft-ietf-inch-iodef-rfc3067bis-requirements

 o Data Model (Jan Meijer)
    - draft-ietf-inch-iodef-00

 o eCSIRT  (Arne Helme)

 o Implementation experience with IODEF at the CERT/CC  (Roman Danyliw)


---[ Administrative 
]---------------------------------------------------
presenter: Roman Danyliw

The meeting in Atlanta for IETF 55 was the first meeting since INCH was 
officially designated a working group (in August 2002).

The status of the deliverables is as follows:

 o There are two drafts for the INCH data model requirements document.  
This said, there is quite a bit of similarity between these drafts since 
both are loosely based on RFC3067.

    -  draft-glenn-inch-req-00
    -  
draft-ietf-inch-iodef-rfc3067bis-requirements-00

   The intent of the authors is to have a single draft by December 2002, and a 
WG last call no later than IETF 57

 o The data model has been undergoing rapid change, and is intended to for a 
WG last call by IETF 57.

 o There has been little interest in the Implementation guide since the 
data model needed quite a few refinements.  The target date for an 
initial draft is March 2003.


---[ Data Model 
]-------------------------------
------------------------
presenter: Jan Meijer
URL: 
http://www.andrew.cmu.edu/~rdanyliw/in
ch/ietf55/ietf55-inch-datamodel.ps

Meijer presented a review of the open issues related to the current data 
model (draft-ietf-inch-iodef-00).  Also presented was a radical 
redesign using recursive classes to solve may of these open issues.  This 
proposed redesign will be further documented and sent to the list.

Questions and Comments:

o Based on the newly proposed data model, several issues were 
discussed:

  o The relative importance between simplicity of presentation (i.e., 
human readability) and the redundancy of data (e.g., duplicate contact 
information).

o There were several concerns with the current implementation of the data 
model:

  o Demchenko volunteered to investigate using XML Schema instead of the 
current DTD implemented.

  o Based on complaints that it was very cumbersome to extract DTDs from the 
I-D, Meijer promised to maintain a separate DTD document for 
implementors as changes are made.

  o Concerns were voiced about the inconsistency of the current 
representation of contact information; too many classes to represent the 
same information.  The proposed changes to the data model offer some 
solutions.

o Some general questions about IODEF completeness were raised:

  o The need for representing routing information between the attacker and 
victim was brought up.  The feeling of the group was that this 
information was important, but would not be standardized by the data model 
and would be relegated to the AdditionalData or Record classes.  
However, traceback information in the more general sense, that might 
enable a CSIRT to take IODEF documents from many constituencies to form a 
larger incident should be explicitly supported.

  o Inquires were made as to whether it was possible to associate 
contact information with an IP-address/host.  The current data model 
supports this functionality.


---[ Requirements 
]-----------------------------------------------------
presenter: Glenn Mansfield Keeni and Yuri Demchenko
URL: 
http://www.andrew.cmu.edu/~rdanyliw/in
ch/ietf55/ietf55-inch-requirements.ppt

There were two RFC3067-based I-Ds submitted as the INCH 
requirements document. Keeni presented on 
draft-glenn-inch-req-00, and Demchenko spoke about 
draft-ietf-inch-iodef-rfc3067bis-requirements.  The latter more 
strictly adheres to the original RFC3067, while the former is a bit more of a 
high level document.

The authors (Keeni and Demchenko) have agreed to collaborate to form a 
single documents; any controversy found while merging to these drafts will be 
itemized for discussion on the list.

Questions and Comments

 o glenn-inch-req-00 posits the need for ACLs on the document, and this 
spurred some debate as to the place of IODEF in the incident handling 
process.  In the end, there was agreement that IODEF is essentially an 
exchange format.  While it should provide mechanisms to indicate how the 
data will be used, this is the highest level of assurance that can be 
promised

 o Concern was raised about the use of the acronym IR in the document; in 
this case it was meant to be incident report.  However, the term's 
pervasive use to also mean incident response seemed confusing.  The term 
"IR" will be renamed in the future draft.

 o There was some discussion about the assumed mode of operation for a 
system using IODEF.  Should it be push or pull?  There was no 
agreement on this topic.


---[ Implementation: eCSIRT 
]-------------------------------------------
presenter: Arne Helme
URL: 
http://www.andrew.cmu.edu/~rdanyliw/in
ch/ietf55/ietf55-inch-ecsirt.pdf

Arne Helme gave a presentation on the eCSIRT project, a 
European-wide early warning system for security events, outlining how they 
plan on using the IODEF.


---[ Implementation: CERT/CC 
]------------------------------------------
presenter: Roman Danyliw
URL: 
http://www.andrew.cmu.edu/~rdanyliw/in
ch/ietf55/ietf55-inch-implementing-iodef.pdf

Roman Danyliw gave a presentation on the implementation experiences of 
CERT/CC with IODEF for its incident reports.

Slides

INCH Requirements
The European CSIRT Network
Implementing the IODEF at the CERT/CC
IODEF Databodel Issues