TERENA'S Incident Object Description and Exchange Format Requirements
RFC 3067

Document Type RFC - Informational (February 2001; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 3067 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       J. Arvidsson
Request for Comments: 3067                                    Telia CERT
Category: Informational                                       A. Cormack
                                                              JANET-CERT
                                                            Y. Demchenko
                                                                  TERENA
                                                               J. Meijer
                                                                 SURFnet
                                                           February 2001

 TERENA's Incident Object Description and Exchange Format Requirements

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   The purpose of the Incident Object Description and Exchange Format is
   to define a common data format for the description, archiving and
   exchange of information about incidents between CSIRTs (Computer
   Security Incident Response Teams) (including alert, incident in
   investigation, archiving, statistics, reporting, etc.).  This
   document describes the high-level requirements for such a description
   and exchange format, including the reasons for those requirements.
   Examples are used to illustrate the requirements where necessary.

1. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

Arvidsson, et al.            Informational                      [Page 1]
RFC 3067                   IODEF Requirements              February 2001

2. Introduction

   This document defines requirements for the Incident object
   Description and Exchange Format (IODEF), which is the intended
   product of the Incident Taxonomy Working Group (ITDWG) at TERENA [2].
   IODEF is planned to be a standard format which allows CSIRTs to
   exchange operational and statistical information; it may also provide
   a basis for the development of compatible and inter-operable tools
   for Incident recording, tracking and exchange.

   Another aim is to extend the work of IETF IDWG (currently focused on
   Intrusion Detection exchange format and communication protocol) to
   the description of incidents as higher level elements in Network
   Security.  This will involve CSIRTs and their constituency related
   issues.

   The IODEF set of documents of which this document is the first will
   contain IODEF Data Model and XML DTD specification.  Further
   discussion of this document will take place in the ITDWG mailing
   lists <incident-taxonomy@terena.nl> or <iodef@terena.nl>, archives
   are available correspondently at
   http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/ and
   http://hypermail.terena.nl/iodef-list/mail-archive/

2.1. Rationale

   This work is based on attempts to establish cooperation and
   information exchange between leading/advanced CSIRTs in Europe and
   among the FIRST community.  These CSIRTs understand the advantages of
   information exchange and cooperation in processing, tracking and
   investigating security incidents.

   Computer Incidents are becoming distributed and International and
   involve many CSIRTs across borders, languages and cultures.  Post-
   Incident information and statistics exchange is important for future
   Incident prevention and Internet security improvement.  The key
   element for information exchange in all these cases is a common
   format for Incident (Object) description.

   It is probable that in further development or implementation the
   IODEF might be used for forensic purposes, and this means that
   Incident description must be unambiguous and allow for future custody
   (archiving/documentation) features.

Arvidsson, et al.            Informational                      [Page 2]
RFC 3067                   IODEF Requirements              February 2001

   Another issue that is targeted by developing IODEF is a need to have
   higher level Incident description and exchange format than will be
   provided by IDS (Intrusion Detection Systems) and the proposed IDEF
   (Intrusion Detection Exchange Format).  Compatibility with IDEF and
   other related standards will be satisfied by the IODEF requirement on
   modularity and extensibility.  IODEF should vertically be compatible
   with IDMEF, IODEF might be able to include or reference IDMEF Alert
   message as initial information about Incident.

2.2. Incident Description Terms

   A definition of the main terms used in the rest of document is given
   for clarity.

   Where possible, existing definitions will be used; some definitions
Show full document text