Concluded WG Extended Incident Handling (inch)
Note: The data for concluded WGs is occasionally incorrect.
WG | Name | Extended Incident Handling | |
---|---|---|---|
Acronym | inch | ||
Area | Security Area (sec) | ||
State | Concluded | ||
Charter | charter-ietf-inch-01 Approved | ||
Document dependencies | |||
Personnel | Chair | Roman Danyliw | |
Mailing list | Address | inch@nic.surfnet.nl | |
To subscribe | listserv@nic.surfnet.nl | ||
Archive | http://listserv.surfnet.nl/archives/inch.html |
Final Charter for Working Group
Background
Computer security incidents occur across administrative domains often
spanning different organizations and national borders. Therefore, the
exchange of incident information and statistics among involved parties
and associated 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.
Scope
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 (either a team or
individual) with a security role or responsibility for a given
constituency (e.g., organization, network).
The use case for the INCH WG output is to standardize the information
model and messaging format currently used in communication between a
CSIRT and the:
-
constituency (e.g., users, customers) from which it receives reports
of misuse; -
other parties involved in an incident (e.g., technical contact at an
attacking site, other CSIRTs); and -
analysis centers performing trending across broad data-sets.
These INCH developed formats will replace the now largely human-
intensive communication processes common in incident handling. The
working group will address the issues related to representing and
transporting:
-
the source(s) and target(s) of system misuse, as well as the
analysis of their behavior; -
the evidence to support this analysis;
-
status of an incident investigation and analysis process; and
-
meta-information relevant to sharing sensitive information across
administrative domains (e.g., internationalization, authorization,
privacy).
Constraints
The WG will not attempt to define
-
- an incident taxonomy;
-
- an archive format for incident information;
-
- a format for workflow process internal to a CSIRT; or
-
- a format for computer security related information for which there
is already a working standard.
- a format for computer security related information for which there
Output of Working Group
-
A set of high-level requirements for a data format to represent
information commonly exchanged by CSIRTs. -
A specification of an extensible, incident data description language
that describes a format that satisfies these requirements (Output #1). -
A set of sample incident reports and their associate representation
in the incident data language. -
A message format specification and associated transport binding to
carry the encoded description of an incident (Output #2). -
Guidelines for implementing the data format (Output #2) and
associated communications (Output #4)
Milestones
Date | Milestone | Associated documents |
---|---|---|
Sep 2006 | Submit implementation guidelines I-D to the IESG as Informational | |
Aug 2006 | Submit messaging format specification I-D to the IESG as Proposed | |
Aug 2006 | Submit incident data language specification I-D to the IESG as Proposed | |
Aug 2006 | Submit transport binding specification I-D to the IESG as Proposed | |
Aug 2006 | Submit phishing extension specification I-D to the IESG as Proposed | |
Jun 2006 | Submit requirements I-D to the IESG as Informational |
Done milestones
Date | Milestone | Associated documents |
---|---|---|
Done | Initial I-D of a transport binding specification | |
Done | Submit initial draft of phishing extension specification I-D | |
Done | Initial I-D of the traceback extension specification | |
Done | Initial I-D of the implementation guidelines document | |
Done | Initial I-D for the requirements specification | |
Done | Initial I-D of the incident data language specification |