2.6.2 Extended Incident Handling (inch)
Last Modified: 2003-05-19
Roman Danyliw <firstname.lastname@example.org>
Security Area Director(s):
Russell Housley <email@example.com>
Steven Bellovin <firstname.lastname@example.org>
Security Area Advisor:
Steven Bellovin <email@example.com>
General Discussion: firstname.lastname@example.org
To Subscribe: email@example.com
In Body: subscribe inch
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
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"
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
* constructs to facilitate the exchange of security information
across administrative domains (e.g., internationalization, data
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
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
|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
No Request For Comments
Current Meeting Report
Incident Handling (INCH) WG Minutes
IETF 57 - Wednesday, 15.30-17.30, July 16, 2003
Chair: Roman Danyliw <firstname.lastname@example.org>
Security Area Advisor: Steven Bellovin
o Administrative (Roman Danyliw)
o Data model requirements (Glenn Mansfield Keeni)
o Data Model
- draft-ietf-inch-iodef-01 (Jan Meijer)
- XML Schema migration (Yuri Demchenko)
o Implementation Guide (Roman Danyliw)
presenter: Roman Danyliw
o Steve Bellovin is the new security area adviser to the working group
o Updates to the schedule were made to reflect a slight slippage in the
delivery dates (WG last-call) of the WG drafts.
] SEP 03 Initial I-D of the implementation guidelines document
] NOV 03 Submit requirements I-D to the IESG as Informational
] NOV 03 Submit incident data language specification I-D to the IESG as
] FEB 04 Submit implementation guidelines I-D to the IESG as
presenter: Glenn Mansfield Keeni
Keeni presented the remaining open issues in the requirement draft in .
Comments and Discussion:
o There is a need for continued discussion of the
domain-specific definitions found in Section #3.
- "Impact" reflects a non-technical results on an organization (e.g.,
loss of customers). On the other hand, "Damage" is a technical impact of an
"Attack" on a host (e.g., denial of service).
- Is the definition of "Incident" sufficiently broad to encompass the
destruction of information? Yes.
- There appears to be a lack of symmetric in the definitions. If a
"Target" and "Victim" are defined, then a corresponding "Source" and
"Attacker" must also be added.
- Reuse definitions from other sources. If a term is used in other
standards, cite that reference, and provide a description as to why the
term is slightly different in the INCH domain.
o The requirements should more clearly reflect the need for
multi-lingual text. A proposed change to support this need can be found at:
- Provide a requirement that translations (multiple versions of the
same text in different languages) of text must be consistent.
o A requirement to deal with time corrections should be added.
The situation of concern is how to convey that a host has their clock
o The term "data owner" used in several requirements is unclear;
expound upon this definition. Does this term refer to the "owner" as the
source of the data? person acting on the data?
o Certain terms defined in the requirements draft are NOT used in the
o There was some discussion on the time format of FINE: explicitly UTC, or
to allow local timezone. Ultimately, it was decided to support only UTC, or a
local format easily convertible to UTC.
---[ Data Model
presenter: Jan Meijer
Meijer presented a review of the open issues related to the current data
model in .
That said, the data model is beginning to stabilize. There have been no
substantial changes (or proposed changes) in the past 4-months. The
remaining work is in:
o migrating the current XML DTD implementation to Schema
o addressing remaining issues with multi-lingual free-form text
o examining and further enumerating certain enumerated attribute values
o codifying the semantics of document updates, and making any
appropriate data model changes that might be necessary
- At a minimum this will require a careful examination of which
fields are explicitly required (rather than optional)
o fully integrating XML-Signature and XML-Encryption
o confirming that all FINE requirements are being met
o proof reading of the text
A new draft incorporating an initial implementation in XML Schema, and all
current pending issues will be complete by September 2003. This draft will
still include the DTD implementation to ease the transition.
Comments and Discussion:
o Supporting multi-lingual free-form text remains an open issues.
A thread on the particular details can be found
o The use of terms defined in the requirements document should be
consistent with the data model document
---[ XML Security in the IODEF
presenter: Yuri Demchenko
Demchenko provided a migration strategy for the data model to XML Schema in
Comments and Discussion
o Many suggestions to the data model were proposed in the
presentation. However, not all are explicitly required to make the
transition to XML Schema. Yuri was asked to separate the suggested
changes from those explicitly required for the migration.
---[ Implementation Guide
presenter: Roman Danyliw
Danyliw presented an overview of the main topics to discuss in the
implementation guide in . No draft for this document exists, but an
initial version should be complete by September 2003.
The following topics were suggested for inclusion in the draft:
o examples of IDMEF messages included in an IODEF document
o best practices in CSIRT data exchange protocols
o an interoperability matrix, when a sufficient number of
implementations are available
Optimising XML Schema for IODEF Data model
IODEF datamodel update
IODEF Implementation Guide: