[iodef] IODEF Mgment Guide

From: [email protected]
Date: Tue Jan 22 2002 - 08:12:52 CET

  • Next message: Karel Vietsch: "Re: [iodef] draft agenda iodef-wg meeting 23 jan 2002"


    Peter Bivesand (SESIC) and myself has been working with the IODEF
    Management Guide.
    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
    Veta mer?:

                              IODEF Management Guide

    IODEF Management Guide must be relatively short, 2-3 pages.

    This is a proposal for topics.

    1.1 Background 1

    1.2 Purpose 2

    1.3 Targeted audience 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.1 Pro's and Con's 3


    1 Introduction
    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.

    1.1 Background

    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
       subordinate teams/CSIRTs

    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) [3] 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.

    1.2 Purpose

    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
    Handling organisations.

    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

    3 Solution
    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.
    3.1 Purpose
       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,
              attackers, etc.
            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
          communications protocols


    [IODEF WG Charter.htm]
    [IODEF Pilot Proposal.txt]

    This archive was generated by hypermail 2b30 : Tue Jan 22 2002 - 08:13:08 CET