Peter Bivesand (SESIC) and myself has been working with the IODEF
I am sorry to say that we hasn't been able to spend the amount of time
that we planned.
We have been working on the Mgmt Guide a couple of hours but it is
*more* to do. Below you'll find our working material.
If we are not expelled from IODEF we would like to complete our work.
Telia AB, HQ
TeliaCERT Full-member of FIRST
Jimmy Arvidsson Phone: +46 (0)8-713 1889
SE-123 86 Farsta Cell.: +46 (0)70-513 1889
SWEDEN Fax: +46 (0)706 175 101
Fingerprint: 3B69 E9AE 2BA7 18BE D28A 6D03 637F 9A64 E65F 3A18
IODEF Management Guide must be relatively short, 2-3 pages.
This is a proposal for topics.
1 INTRODUCTION 1
1.1 Background 1
1.2 Purpose 2
1.3 Targeted audience 2
2 HISTORY / CURRENT SITUATION 2
2.1 Handling of incident information 2
2.1.1 Information Exchange 3
2.1.2 Multiple Incident Sources / parties 3
2.1.3 Multiple Complaints on the same Incident 3
2.2 Information gathering 3
3 SOLUTION 3
3.1 Purpose 3
4 DESCRIPTION FOR 3
4.1 Pro's and Con's 3
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 minimise 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 standardised incident data format and
standardised incident data exchange procedures.
Incident Object Description and Exchange Format (IODEF) is a standard
format which allows CSIRTs to exchange operational and statistical
information; it also provide a basis for the development of compatible and
inter-operable tools for Incident recording, tracking and exchange.
IODEF is the common data format and common exchange procedures between
CSIRTs and it is generated when sending message with Incident information
to another CSIRT or Incident Handling System (IHS). IODEF is not dependent
on internal incident data storage/database, which may use another
(proprietary) format. When using IODEF in the workflow and Incident
Handling Systems, CSIRTs can benefit from:
· a method of identifying and storing information from a variety of
· simplified building of an incident correlation and statistical
system that process Incident reports from different CSIRTs; it 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
· a common incident data exchange format makes it easier for
different organisations (users, vendors, response teams, law
enforcement, etc) to exchange and communicate information about
incidents and related data.
One of IODEF design principles is compatibility with Intrusion Detection
Message Exchange Format (IDMEF)  developed for Intrusion Detection
Systems. IODEF is heavily based on IDMEF and has
compatibility with IDMEF. The IODEF Working Group are coordinating its
efforts with other (IETF) Working Groups.
IODEF is very flexible and capable of handling different kinds of
information or data related to Computer Security Incident Handling.
IODEF provides a framework for a common taxonomy in the area of Computer
Security Incident Handling.
This document provides a overview of the Incident Object Description and
Exchange Format (IODEF) and the benefits of using this in an Computer
Security Incident Handling organisation.
1.3 Targeted audience
This document is primarily for managers of Computer Security Incident
2 History / Current situation
2.1 Handling of incident information
Today Computer Security Incident Information is in most cases handled
manually depending on the type of case and parties involved. This work is
time consuming and prune to errors.
2.1.1 Information Exchange
2.1.2 Multiple Incident Sources / parties
2.1.3 Multiple Complaints on the same Incident
2.2 Information gathering
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.
A uniform incident classification enables applications such as:
· uniform statistic generation and exchange, for both
domestic use and exchange of data between teams. Over time a
distributed incident statistics infrastructure can evolve
· trend-analyses for reoccurrence of incidents, victims,
· trend-analyses for relations between scans and attacks and
thus begin working on pro-active incident response
· uniform internal incident storage
· incident handling between teams made easier (only one team
needs to classify and analyze the complete incident, the other
team can re-use this data)
· uniform incident reporting by victims to CSIRTs
4 Description For
4.1 Pro's and Con's
The pro's are following:
· IODEF format supports full internationalization and
· The format of IODEF supports modularity in Incident
description to allows aggregation and filtering of data
· IODEF support the application of an access restriction policy
attribute to every element.
· The IODEF itself MUST be extensible. It is essential that when
the use of new technologies and development of automated Incident
handling system demands extension of IODEF, the IODEF will be capable
to include new information.
· IODEF exchange is initiated by humans using standard
[IODEF WG Charter.htm]
[IODEF Pilot Proposal.txt]
This archive was generated by hypermail 2b30 : Tue Jan 22 2002 - 08:13:08 CET