|
IODEF WGIODEF Working Group Charter |
Revised at the 4th TF-CSIRT meeting - 28 Sep 2001
Coordinator(s):
Andrew Cormack <Andrew.Cormack@ukerna.ac.uk>
Jan Meijer <jan.meijer@surfnet.nl>
Secretary:
Yuri Demchenko <demch@terena.nl>
Liaison(s):
CERT/CC - Roman Danyliw <rdd@cert.orgg>
AusCERT - Rob McMillan <rob@auscert.org.au>
Mailing Lists:
Incident Object Description and Exchange Format: iodef@terena.nl
To subscribe send this
message to majordomo@terena.nl
Mailing List Archive: http://hypermail.terena.nl/iodef-list/mail-archive/
General discussion: incident-taxonomy@terena.nl (merged with iodef mailing
list since April 2001)
Mailing List Archive (historical): http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/
Webpage:
http://www.terena.nl/task-forces/tf-csirt/iodef/
Security incidents are becoming more common and more serious, and handling these incidents by Computer Security Incident Response Teams (CSIRTs) is becoming of increasing (commercial) importance. Incidents usually involve multiple CSIRTs of multiple administrative domains, each with their own incident handling systems, formats and procedures. To properly resolve an incident the involved CSIRTs need to exchange data related to the incident. To minimize the time spent on each incident and to allow for further automation of the incident handling process and let incident handlers spend their time on incident handling in stead of pumping data around, it would be advantageous to have a standardized incident data format and standardized incident data exchange procedures.
A standardized extendable data format and standardized incident exchange procedures would also allow aggregation of incident data across multiple administrative domains thus creating the possibility to create automated regular statistics. These statistics are an important enabler for the CSIRT community to spot trends, predict upcoming large-scale attacks, and so on.
The purpose of the Incident Object Description and Exchange Format Working
Group is to define a common data format and common exchange procedures
for sharing information needed to handle an incident between different
CSIRTs and to exchange incident related data between CSIRTs that allows
both known and new types of incidents to be formatted and exchanged. The
Incident Object Description and Exchange Format Working Group will coordinate
its efforts with other (IETF) Working Groups.
Target audience:
The primary audience for the output of the IODEF Working Group will
be CSIRTs involved in the TF-CSIRT and in the FIRST community.
Problem solvers:
Teams able to seriously contribute to the development of the output
of the IODEF Working Group are invited to participate in the development.
Beyond the scope of this working group:
There are a number of elements that are very important in supporting the goals of this working group that we can intentionally set aside as beyond the scope of this project for the moment.
(a) Linkages between incidents within the data set of a CSIRT
This means that the total number of incidents reported by a CSIRT as
a discrete value is likely to be less than the total number of incidents
reported as a sum of components. For example, an incident may have 3 MOs
(remote buffer overflow, Trojan Horse, DDOS). As a discrete value, this
is reported as a single incident, but for analysis purposes it is reported
3 times - once under each MO. Therefore a CSIRT may handle 1000 incidents
each year as a discrete total, but the total incidents when added up by
MO components may come to (for example) 3000.
This should probably be addressed when actually implementing a complete incident handling and tracking application.
(b) Linkages between incidents worked on by two CSIRTs.
Lets say AusCERT and CERT/CC work on an incident. At one level its
a single incident, but it will still be reported twice - once by AusCERT
and once by CERT/CC.
(c) Automatic data exchange, using the CIDF or anything else.
This is an implementation detail (worthy though it is) that is best
left until after the completion of the work at hand.
(d) The CVE - this project is approaching the problem from a different
perspective.
It concerns itself with *cataloging* *known* vulnerabilities and matching
them against advisories. The problem we are trying to solve is wider in
scope. We are looking at a vulnerabilities, incidents and other items.
We are building a framework, not a catalogue. The framework must be able
to support future events by being flexible enough to allow easy expansion
as events evolve.
(e) Internal classifications.
We all have internal classifications for administrative reasons. These
can be thought up by each team individually.
1. A best current practice document of incident classification and reporting schemes currently used by active CSIRTs
2. A requirements document, which describes the functional requirements for an Incident Object
3. A document describing the relations between the IODEF Incident handling systems and IDMEF developed by IETF IDWG
4. An incident report example set
5. The IODEF Data Model and XML DTD description
6. The IODEF usage recommendations
| November 2000 | Submit Requirements document as Internet-Draft to become an informational RFC | Done |
| February 2001 | Submit update on Requirements document | Done |
| March 2001 | Draft document describing relations between the IODEF and IDMEF (to be presented to IDWG) | Done |
| October 2001 | First draft incident report example set | |
| November 2001 | Report on application of data model to incidents from the incident report example set | |
| December 2001 | Submit IODEF Data Model and XML DTD descriptiondocument as an Internet-Draft (intended to become an informational RFC) | |
| December 2001 | Submit IODEF usage recommendations document as an Internet-Draft (intended to become an informational RFC) |
TERENA Pilot Implementation Project (not part of the
IODEF WG)
