[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01

Extended Incident Handling Working Group                      R. Danyliw
Internet-Draft                                  CERT Coordination Center
Expires: September 7, 2004                                March 09, 2004

        The Incident Object Description Exchange Format (IODEF)
                          Implementation Guide

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 7, 2004.

Copyright Notice

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


   The purpose of this Internet-Draft is to provide implementation
   guidelines for Computer Security Incident Response Teams (CSIRT)
   adopting the Incident Object Description Exchange Format (IODEF).

Danyliw                Expires September 7, 2004                [Page 1]

Internet-Draft         IODEF Implementation Guide             March 2004

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3   CSIRT Operations . . . . . . . . . . . . . . . . . . . . .  3
   2.  General Integration Considerations . . . . . . . . . . . . . .  4
     2.1   Unique Identifiers . . . . . . . . . . . . . . . . . . . .  5
     2.2   Profiles . . . . . . . . . . . . . . . . . . . . . . . . .  5
       2.2.1   Required Data  . . . . . . . . . . . . . . . . . . . .  6
       2.2.2   Semantics  . . . . . . . . . . . . . . . . . . . . . .  6
       2.2.3   Formatting . . . . . . . . . . . . . . . . . . . . . .  6
       2.2.4   Transport issues . . . . . . . . . . . . . . . . . . .  6
     2.3   Updating Incident Data . . . . . . . . . . . . . . . . . .  7
   3.  Importing and Processing Considerations  . . . . . . . . . . .  7
     3.1   Processing Algorithm . . . . . . . . . . . . . . . . . . .  7
     3.2   IDMEF relationship . . . . . . . . . . . . . . . . . . . .  9
     3.3   Types of Data  . . . . . . . . . . . . . . . . . . . . . .  9
       3.3.1   Enumerated Values  . . . . . . . . . . . . . . . . . .  9
       3.3.2   Structured Values  . . . . . . . . . . . . . . . . . . 10
       3.3.3   Subjective Values  . . . . . . . . . . . . . . . . . . 10
       3.3.4   Free-form Values . . . . . . . . . . . . . . . . . . . 10
       3.3.5   Extensions . . . . . . . . . . . . . . . . . . . . . . 11
     3.4   Structure of the Data  . . . . . . . . . . . . . . . . . . 11
       3.4.1   Non-deterministic  . . . . . . . . . . . . . . . . . . 11
       3.4.2   Document unique idents . . . . . . . . . . . . . . . . 11
   4.  Export Considerations  . . . . . . . . . . . . . . . . . . . . 11
     4.1   Processing Algorithm . . . . . . . . . . . . . . . . . . . 11
   5.  Representation Examples  . . . . . . . . . . . . . . . . . . . 12
     5.1   Multiple Contacts  . . . . . . . . . . . . . . . . . . . . 12
     5.2   Expectation  . . . . . . . . . . . . . . . . . . . . . . . 13
     5.3   Sequence of Events . . . . . . . . . . . . . . . . . . . . 13
     5.4   XML-Signature  . . . . . . . . . . . . . . . . . . . . . . 13
     5.5   XML-Encryption . . . . . . . . . . . . . . . . . . . . . . 13
     5.6   Non-English example  . . . . . . . . . . . . . . . . . . . 13
     5.7   Translations . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  Appendix 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
       Normative References . . . . . . . . . . . . . . . . . . . . . 16
       Informative References . . . . . . . . . . . . . . . . . . . . 17
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
       Intellectual Property and Copyright Statements . . . . . . . . 18

Danyliw                Expires September 7, 2004                [Page 2]

Internet-Draft         IODEF Implementation Guide             March 2004

1. Introduction

1.1 Terminology

   The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"
   document are to be interpreted as described in RFC2119 [4].

   Definitions for some of the common computer security-related
   terminology used in this document can be found in Section 2 of [1].

1.2 Overview

   The Incident Object Description Exchange Format (IODEF) [7] is an
   abstract data model for representing computer security incidents
   exchanged by Computer Security Incident Response Teams (CSIRTs).  It
   was designed to satisfy the requirements laid out in [1].
   Practically, [7] also provides an XML DTD (soon to be Schema)
   implementation of the data model.

   The purpose of this document is to provide additional information for
   IODEF implementers.  Section 1 outlines the operational assumptions
   and context in which the IODEF will be used.  Sections 2 discusses
   general issues related to exchanging IODEF documents.  The importing
   and exporting IODEF documents with an IHS is covered in detail in
   Section 3 and 4, respectively.  Section 5 provides useful examples of
   IODEF usage for given situations.

   This draft is incomplete.  There are several sections marked as
   "TODO" either the document author has not completed the text, or the
   working group needs to provide clarification.

1.3 CSIRT Operations

   The key function of a CSIRT is to remediate security activity in
   their constituency.  As security events can occur across
   administrative domains, CSIRTs also often play a coordination role to
   resolve incidents.  In the IODEF context, a CSIRT is defined very
   broadly to include almost any entity that might exchange incident
   information.  For example, this role might be fulfilled by a single
   security analyst in a network operations group, a help-desk operation
   center, or a national-level CSIRT.

   CSIRTs with responsibility over networks often build their operations
   around a system to manage the entire incident life-cycle.  This
   incident handling system (IHS) must store all incident information
   and related communications; provide primitives to support the
   work-flow of the analysts; and tools to analyze the reported incident

Danyliw                Expires September 7, 2004                [Page 3]

Internet-Draft         IODEF Implementation Guide             March 2004

   data.  It is commonly built around a ticket-tracking application
   adapted for a security role.  The underlying data store is typically
   a relational database.  See section 3 of [1] for additional details
   about the implicit operational assumptions for the IODEF.

   The IODEF is agnostic to most of the internal process and technology
   choices made by a CSIRT.  The IODEF provides no improvements for user
   interface issues or new analytical techniques.  It is in the
   communications with other parties that the IODEF can have an impact
   on operations.  The current collaboration model requires significant
   effort to process incident reports because of a lack of
   standardization in incident information.  The IODEF can simplify some
   of this communication by providing a well-documented format and
   structure, published as an XML DTD, to represent the incident data
   already being exchanged.

   The IODEF is not a replacement for all communication in and across
   constituencies.  Any common format is useful when there is a need to
   inter-operate.  Inside an organization, where processes can be
   mandated by fiat, standardization occurs implicitly.  The value of
   IODEF comes when there is a need to exchange information across
   administrative domain.  That said, the IODEF is not suitable for all
   users.  The format is complex, making it unlikely that IODEF
   documents will be generated by hand as done with many incident
   reports today.  Therefore, it will largely be employed only by a more
   sophisticated set of users that have the knowledge to reformat their
   incident data.  In the foreseeable future, there will be a continued
   need to support free-form reporting mechanisms.  As a middle ground,
   front-end tools gathering incident data (e.g., web forms) can be
   developed to export IODEF documents.

2. General Integration Considerations

   Integrating the IODEF into a CSIRT requires changing the IHS to
   import and export IODEF documents.  Effectively, this capability
   involves the ability to convert from the native IHS data format to
   XML, and vice versa.  Since it merely introduces another
   representation for existing data, the underlying storage mechanism
   and schema of the IHS need not be changed to accommodate the IODEF.
   Furthermore, the use of the IODEF as the explicit storage or archive
   format is not recommended due to the space inefficiency of XML.
   Importing IODEF documents will allow a CSIRT to rapidly process newly
   reported incident information since the barriers of the semantics
   ambiguity and data normalization will not be present.  Exporting
   IODEF documents allows a CSIRT to unambiguously share information
   with collaborators.  This capability becomes especially relevant when
   coordinating with a CSIRT with whom no prior relationship might

Danyliw                Expires September 7, 2004                [Page 4]

Internet-Draft         IODEF Implementation Guide             March 2004

2.1 Unique Identifiers

   CSIRTs track incidents by assigning each an identifier unique in
   context of its constituency.  In the IODEF data model, this
   identifier is represented by the mandatory IncidentID class.  It is
   through this identifier that an IODEF document relates to the IHS.
   It is possible that this same activity could be reported to another
   CSIRT that in turn assigns its own unique identifier.  Each CSIRT
   associates their own identifier for the identical incident in their
   respective IHS.  However, to provide a framework for CSIRTs to refer
   to each other's data, the IODEF provides the optional AlternateID
   class to represent another CSIRT's tracking identifier for the same
   activity.  Combining the name of a CSIRT and the incident identifier
   provides a globally unique identifier for an incident.

   TODO: How are IncidentIDs generated?  What is the convention?

   It may be possible that multiple IODEF documents are exchanged about
   the same incident over its lifetime.  Hence, the use of the id
   attribute of the IODEF-Document to uniquely identify a particular
   IODEF document.  This global identifier is only relevant for the
   purposes of transport (e.g., duplicate detection, retransmission).
   It will change with each new IODEF document, regardless of the value
   of the IncidentID class value.

   TODO: Can an /IODEF-Document@id ever be reused? how is it generated?
   Is it globally unique?

2.2 Profiles

   While the IODEF data model is unambiguous, the usage and the
   semantics of the data will need to be further refined for a community
   of collaborators if incident data is to be exchanged.  These data
   exchange policies are collectively referred to as a profile.  The
   need for profiles, in addition to the format specification, is due to
   the wide variety of data that might be represented in an IODEF
   document.  A well-specified profile is the key to machine-parsing the
   exchanged documents.

   A CSIRT may choose to publicly publish a profile for use by anyone
   wishing to communicate information to it.  Such a model is helpful in
   a CSIRT with a wide constituency that might receive unsolicited
   reports.  Likewise, in a smaller, closed community of CSIRTs,
   specific arrangements that apply only to the respective parties can
   be made.  These profiles may cover organizational specific
   information that the parties will be sharing.  Since a CSIRT may send
   IODEF documents to many other CSIRTS, it will have to maintain many
   profiles, each specific to the intended recipient.

Danyliw                Expires September 7, 2004                [Page 5]

Internet-Draft         IODEF Implementation Guide             March 2004

   The format for specifying a profile is outside the scope of this
   document and the INCH working group.  However, Section 2.2.1 to
   Section 2.2.4 provide a cursory description of the types of
   information that should be included in a profile.

2.2.1 Required Data

   A profile MUST specify exactly the data that will be exchanged
   between peers.  The IODEF specification mandates the presence of
   certain fields, but the profile should go further to define which
   optional fields are required.  There is no point in sending data that
   a peer might not be interested in collected.  Likewise, insufficient
   information will require a follow-up communication.

   Incident reports documenting different types of activity are not
   composed of the same type of data.  For example, the data needed to
   describe an administrative compromise might be different from that of
   a policy violation.  Therefore, a profile could distinguish between
   the different types of incidents and specify different mandatory
   fields for each.

2.2.2 Semantics

   Given the XML DTD and the profile, the recipient of an IODEF document
   should be able to understand the the contents.  A profile MUST
   disambiguate the semantics of all the subjective values (see Section
   3.3.3) that are exchanged.  When not compromising the intent of the
   transformation, any sanitization performed on the data SHOULD be
   documented.  Naming conventions for data commonly found in CSIRTs
   (e.g., incident numbers) SHOULD be documented.

2.2.3 Formatting

   To the the degree possible, formatting conventions SHOULD be
   standardized to aid in machine processing of IODEF documents.  This
   specification is especially relevant when dealing with the free-form
   values (see Section 3.3.4).  Agreeing on a natural language for these
   fields is also helpful within a diverse community.

   In addition the format of the content itself, the overall structure
   of the IODEF document should be documented.  Given that the data
   model is non-deterministic (see Section 3.4.1), the profile SHOULD
   specify the required way to represent the information.

2.2.4 Transport issues

   In the absence of an IODEF transport protocol, the profile MUST

Danyliw                Expires September 7, 2004                [Page 6]

Internet-Draft         IODEF Implementation Guide             March 2004

   document how the peers will exchange the IODEF documents.  The choice
   of protocols must take into account the properties of the XML IODEF
   documents.  Ideally the channel between parties would provide
   reliable delivery, compression of the text stream, confidentiality,
   integrity, and authenticity.  Non-repudiation may be desirable in
   certain situations.

   The process surrounding the use of the protocol will also need to be
   specified.  The frequency of incident data exchange SHOULD be
   specified (e.g., batched at pre-determined intervals, or real-time).
   If cryptography is used, key management issues must be addressed.
   Choices of trust models must be decided; will trust be based on a
   hierarchy (ala, a PKI) or a web-of-trust (ala, PGP).

   Existing data exchange practices in CSIRT operations commonly make
   use of SOAP, TLS, or PGP encrypted and signed email messages.

2.3 Updating Incident Data

   TODO: The working group needs to decide how to perform updates, if at

3. Importing and Processing Considerations

   Upon receiving an IODEF document, the IHS must process it so that
   normal work-flow processes can be applied.  The task of importing an
   IODEF document involves extracting the relevant data and storing it
   in the IHS.

3.1 Processing Algorithm

   The processing of IODEF documents can be generalized into five steps.
   Depending on the specific exchange protocols used, and the particular
   IHS, certain steps may not be necessary.

   o  Accepting the document.  IODEF documents will likely be exchanged
      over a cryptographically secured medium.  Prior to even examining
      the document, it may need to be decrypted.  If the underlying
      transport does not already handling the issues of key management,
      the IHS must provide the correct decryption key.  It may be
      necessary to use external information or properties of the
      document itself to determine the proper key to use.  When
      possible, the authenticity of the document from the sender must
      also be verified (e.g., via public key signatures).  If
      confidentiality and integrity are implemented via XML-Encryption
      and XML-Signature, validation of the XML MUST occur prior to this

Danyliw                Expires September 7, 2004                [Page 7]

Internet-Draft         IODEF Implementation Guide             March 2004

   o  Structural Validation.  To confirm proper formatting, the document
      must be examined with an XML parser to check that it is both
      well-formed and valid according to the IODEF DTD.  If XML
      extensions are used in the AdditionalData or RecordItem classes,
      then the appropriate DTDs must be used. There are numerous free
      and commercial parsers for virtual all programming languages.
      Given a properly formatted XML document, any additional
      constraints on element and attribute cardinality imposed by a data
      sharing profile SHOULD be applied.

   o  Data Validation.  Verification of properly formatted XML document
      does not guarantee that the data itself is valid.  Therefore, the
      individual element and attribute values must be checked that they
      conform to the data types specified by the data model (e.g., was
      an alphanumeric string value specified for a numeric TCP port).  A
      profile might also impose formatting restrictions on the data.

   o  Semantic Validation.  Given properly formatted data, its semantics
      must be verified.  This validation may be dictated by the profile
      specification (e.g., a particular value range), or from external
      information (e.g., are the timestamps in the future).  Discerning
      the reason why this incident report was sent to the CSIRT and the
      expected response is key at this phase.

   o  Transformation and Storage.  Since IODEF documents must be
      imported, transformations may need to be applied to the data to
      convert it to the native representation of the IHS.  Once natively
      formatted, the necessary invocation must be made to write into the
      data store (e.g., SQL statements).

   o  Post-Processing.  In the course of processing IODEF documents
      useful meta-data can be generated.  This meta-information is often
      useful for work-flow, debugging and audit purposes.  An IHS might
      note in a transaction logs when a document arrived, its size and
      source.  Implementers can chose to store this information external
      to the IHS, or extend its underlying data store.  Furthermore,
      when a new incident report arrives certain triggers in the IHS may
      need to be invoked to signal the presence of this new information.
      Automated analysis tools may be invoked to correlate the new
      information with the existing data set.  Work-flow processes or
      tasking priorities may need to be adjusted.

   There will be instances where an IODEF document that cannot be
   processed is sent to a CSIRT.  This situation may be due to invalid
   XML formatting, or a semantic misunderstanding.  The CSIRT must
   decide how to handle this occurrence.  The range of possibilities
   includes silently dropping these documents to manual intervention by
   an analyst.  The IHS SHOULD keep at least cursory logs of these types

Danyliw                Expires September 7, 2004                [Page 8]

Internet-Draft         IODEF Implementation Guide             March 2004

   of documents.  It will allow for debugging, as well as, a way to
   identify denial of service activity.

3.2 IDMEF relationship

   In constructing the IODEF data model, certain classes were reused
   from the IDMEF.  Therefore, their description was not included in the
   specification.  Instead referencing the IDMEF specification is
   required.  The relevant portions of the IDMEF DTD were copied
   outright into the IODEF DTD for completeness.  For a list of classes
   from the IDMEF, see the "IDMEF" column of Appendix 1.

3.3 Types of Data

   Given that the IODEF is implemented in XML, the entire document is a
   single text string with an encoding specified in the leading XML
   processing instruction.  The data model enforces a structure onto
   this string by segmenting distinct data into XML elements and
   attributes each of which is typed.  However, the base data type only
   provides a formatting specification.  A richer understanding of the
   data items found in the IODEF is necessary to process the data in an
   automated way.  It is useful to segregate the various data item based
   on the different approaches that will be needed to process them.  The
   IODEF data model has items that have the following types of values:
   enumerated, structured, subjective, free-form, and extensions.
   Appendix 1 associates a data type with every data item of the IODEF
   data model.

3.3.1 Enumerated Values

   An enumerated value is a specified list of possible values for a
   given data element.  They are used when the domain of possible values
   is fixed.  Practically speaking, all enumerated values in the IODEF
   are XML attributes.  For a list of data items that are enumerated
   values, see those marked as "ENUM" in Appendix 1.

   In general, processing enumerated types is straightforward, since all
   possible values are known.  However, there are certain enumerated
   values that provide an escaping mechanism whereby an unspecified
   value may be represented.  This technique involves setting the XML
   attribute to "other", and encoding the desired value in the PCDATA of
   the XML element of the attribute.  For a full list of such special
   attributes, see those that are marked as "ENUM+OTHER" in Appendix 1.

   In order to allow updates, all enumerated lists in the IODEF are
   registered and maintained by IANA.  However, in a closed community,
   it would not be uncommon to extend an enumerated list by adding
   community-relevant data values.  This addition would have to be noted

Danyliw                Expires September 7, 2004                [Page 9]

Internet-Draft         IODEF Implementation Guide             March 2004

   in the exchange profile, and the corresponding portion of the XML DTD
   updated.  Otherwise, if an unrecognized value is provided for an
   enumerated value, it should be treated as an invalid XML document.

3.3.2 Structured Values

   Structured values are the bulk of the IODEF data model.  These are
   data items that have a well-defined format, and unambiguous
   semantics.  The IHS will be able to parse and interpret them with
   little or no transformation.  The specific format of the data is
   either dictated outright by the data type of the class, or by other
   information present in the IODEF documents (e.g., the value of an
   attribute).  For a full list of structured values, see the data items
   marked as "STRUCTURED" in Appendix 1.

3.3.3 Subjective Values

   Subjective values are identical to structured values with regard to
   formatting, but they have ambiguous semantics.   Interpretation of
   subjective values requires further specification from a
   pre-negotiated profile.  Since profiles between sites can vary, the
   semantics of the same value can depend of the profile used.  For a
   full list of the subjective values, see the data items marked as
   "SUBJECTIVE" in Appendix 1.

3.3.4 Free-form Values

   Free-form values are text strings with no pre-defined structure used
   to represent natural language descriptions.  These values often
   represent information too disparate or complex to easily specify.
   Machine parsing free-form text values to extract meaning is extremely
   difficult.  Peers may agree in a profile to apply structure to these
   fields whereby imposing formatting constraints.  However, short of
   such additional information, the IHS SHOULD extract these values and
   store them unmodified for later review by a human analyst.

   Free-form values can support a variety of natural languages.  Hence,
   associated with each element are two attributes that aid in
   disambiguating the formatting.  While the encoding of the entire XML
   document is specified in the initial XML processing instruction,
   free-form XML elements have an attribute named "encoding" that
   specifies the language encoding to apply to that element.
   Furthermore, enumerated XML attribute named "lang" allows the
   specification of the natural language of the element.

   Due to the processing complexity, free-form values SHOULD be used
   sparingly, favoring instead the existing structured data model to
   represent information.

Danyliw                Expires September 7, 2004               [Page 10]

Internet-Draft         IODEF Implementation Guide             March 2004

   For a full list of free-form values, see the data items marked
   "FREEFORM" in Appendix 1.

3.3.5 Extensions

   No standardization effort can represent all data elements of interest
   to its entire community.  Hence, the IODEF includes well-defined ways
   to   extend itself.  The AdditionalData and RecordItem classes allow
   arbitrary data to be included in the document.  The inclusion of
   these extensions and the semantics of this information MUST be
   documented in a profile.  If XML extensions are used, then the
   appropriate DTD will need to be passed to the parser.

3.4 Structure of the Data

3.4.1 Non-deterministic

   The IODEF data model is non-deterministic in that two of the elements
   are recursive defined: Contact, and EventData.  The implication of
   such a structure is that fixed XPaths to information might not always
   be valid.  Making use of the recursion allows for a logical grouping
   of information that eliminated redundancy.  The following is a simple
   example of this concept.

   TODO: include recursion examples

3.4.2 Document unique idents

   TODO: what are they used for?  to what classes do they apply?

4. Export Considerations

   In order to share information with other CSIRTs, incident information
   must be exported from the IHS to the IODEF.

4.1 Processing Algorithm

   Once the intended recipient of an incident is identified, the process
   to export and transmit this party an IODEF document can be
   generalized into four steps.

   o  Query the Incident.  Initially, all the relevant data about the
      incident that will be encoded in the IODEF document must be
      extracted from the IHS.  Based on negotiated profiles, different,
      or varying level of detail, might be shared about the same
      incident with different parties.  Certain CSIRTs might receive all
      the information about an incident; another might only receive a

Danyliw                Expires September 7, 2004               [Page 11]

Internet-Draft         IODEF Implementation Guide             March 2004

      subset.  If there is any sensitive data that must be sanitized, or
      classes of information to be filtering for certain parties, the
      appropriate policy should be enforced.

   o  Reformat the Data.  The internal representation of the incident
      data in the IHS may be quite different that the one used in the
      IODEF.  This transformation may entail explicit reformatting of
      the individual data items into the IODEF data types.  Furthermore,
      subjective values, if stored in a different way, may need to be
      remapped onto their equivalents in the IODEF data model and as
      specified in a data profile (e.g., the profile might specify a
      priorities from 1 to 4, with 1 being the lowest, but the IHS uses
      a scheme, were 4 is the lowest).  Finally, during this conversion
      process, implementers must consider XML encoding issues.  There
      are several special characters (see XML reference) that must be
      escaped.  If binary data is included in the AdditionalData or
      RecordData classes, it must also be escaped.  If whitespace is
      part of a data the xml:preserve attribute must be set correctly in
      the relevant XML element.  A value of "preserve" for this
      attribute will require the IHS to treat any whitespace as
      significant.  Otherwise, the default value of "default" allows the
      IHS to treat the whitespace as it likes.

   o  Set Expectations.  When sending an IODEF document to another
      CSIRT, the intent behind this communication and the desired
      handling of the information should be document.  The enumerated
      attributed "purpose" of the Incident class should be set to convey
      the reason why this IODEF document was sent to the CSIRT.
      Likewise the Expectation class MUST be set to encapsulate the
      expectation the sender has for the recipient.  Judicious use of
      the restriction attribute on the various data items will also
      allow the sender to convey how they would request their data to be
      used.  With all of these settings, the recipient is free to ignore
      this information.

   o  Transmission.  Given a valid XML document, the proper exchange
      protocol, as specified in the profile associated with the
      recipient, will be used to send the document.  In the absence of
      published profile for a recipient, out-of-band mechanisms MUST be
      used to contact the party to make arrangements.

5. Representation Examples

5.1 Multiple Contacts

Danyliw                Expires September 7, 2004               [Page 12]

Internet-Draft         IODEF Implementation Guide             March 2004

5.2 Expectation

5.3 Sequence of Events

5.4 XML-Signature

5.5 XML-Encryption

5.6 Non-English example

5.7 Translations

6. Acknowledgments

7. Appendix 1

   The following is a list of all elements and attributes of the IODEF
   and their associated datatypes.

        Element Name    Attribute       Datatype        Class          IDMEF
   1    access-time     PCDATA          DATETIME        STRUCTURED      Y
   2    AdditionalData  ------------    ANY                             Y
                        type            ENUM
                        meaning         STRING
   3    Address         ------------    ----------      -----------     Y
                        vlan-num        INTEGER
                        vlan-name       STRING
                        ident           INTEGER
                        category        ENUM
   4    address         PCDATA          STRING                          Y
   5    AlternativeID   ------------    ----------      -----------
   6    Analyzer        ------------    ----------      -----------     Y
                        version         STRING
                        osversion       STRING
                        ostype          STRING
                        model           STRING
                        manufacterer    STRING
                        class           STRING
                        analyzerid      STRING
   7    arg             PCDATA          STRING                          Y
   8    Assessment      ------------    ----------      ------------
   9    cgi             PCDATA          STRING                          Y
   10   change-time     PCDATA          DATETIME                        Y
   11   Classification  -----------     ----------      ------------
                        origin          ENUM + O

Danyliw                Expires September 7, 2004               [Page 13]

Internet-Draft         IODEF Implementation Guide             March 2004

   12   c-major-device  PCDATA          INTEGER                         Y
   13   c-minor-device  PCDATA          INTEGER                         Y
   14   command         PCDATA          STRING                          Y
   15   community       PCDATA          STRING                          Y
   16   Confidence      PCDATA          REAL
                        rating          ENUM
   17   Contact         ------------    ----------      ------------
                        contacttype     ENUM
                        contactrole     ENUM
   18   create-time     PCDATA          DATETIME                        Y
   19   data-size       PCDATA          INTEGER                         Y
   20   DateTime        PCDATA          DATETIME
   21   Description     PCDATA          STRING
                        transform       ENUM
                        preserve        ENUM
                        lang            ENUM
   22   DetectTime      PCDATA          DATETIME
                        ntpstamp        NTPSTAMP
   23   disk-size       PCDATA          INTEGER                         Y
   24   Email           PCDATA          EMAIL
   25   EndTime         PCDATA          DATETIME
                        ntpstamp        NTPSTAMP
   26   env             PCDATA          STRING                          Y
   27   EventData       ------------    ----------      ------------
   28   Expectation     ------------    ----------      ------------
                        priority        ENUM
                        category        ENUM
   29   Fax             PCDATA          PHONE
   30   File            ------------    ----------      ------------    Y
                        ident           STRING
                        fstype          STRING
                        category        ENUM
   31   FileAccess      ------------    ----------      ------------    Y
   32   FileList        ------------    ----------      ------------    Y
                        category        ENUM
   33   History         -----------     ---------       ------------
                        type            ENUM+O
   34   HistoryItem     ------------    ----------      ------------
   35   http-method     PCDATA          STRING                          Y
   36   Impact          PCDATA          STRING
                        type            ENUM+O
                        severity        ENUM
                        lang            ENUM
                        completion      ENUM
   37   Incident        ------------    ----------      ------------
                        purpose         ENUM+O
   38   IncidentData    ------------    ----------      ------------
   39   IncidentID      PCDATA          UID

Danyliw                Expires September 7, 2004               [Page 14]

Internet-Draft         IODEF Implementation Guide             March 2004

                        name            GUID
   40   Inode           ------------    ----------      ------------    Y
   41   IODEF-Document  ------------    ----------      ------------
                        version         STRING
   42   LifeImpact      PCDATA          INTEGER
                        severity        ENUM
                        metric          ENUM
   43   Linkage         ------------    ----------      ------------    Y
                        category        ENUM
   44   Location        PCDATA          STRING
                        lang            ENUM
   45   major-device    PCDATA          STRING                          Y
   46   minor-device    PCDATA          STRING                          Y
   47   Method          ------------    ----------      ------------
   48   modify-time     PCDATA          DATETIME                        Y
   49   MonetaryImpact  PCDATA          REAL
                        severity        ENUM
                        currency        ENUM
   50   Name            PCDATA          STRING
                        transform       ENUM
                        preserve        ENUM
                        lang            ENUM
   51   name            PCDATA          STRING
                        lang            ENUM
   52   netmask         PCDATA          STRING                          Y
   53   Node            ------------    ----------      ------------
                        category        ENUM
   54   NodeRole        PCDATA          STRING
                        lang            ENUM
                        category        ENUM+O
   55   number          PCDATA          INTEGER                         Y
   56   oid             PCDATA          STRING                          Y
   57   path            PCDATA          STRING                          Y
   58   pid             PCDATA          STRING                          Y
   59   port            PCDATA          INTEGER                         Y
   60   portlist        PCDATA          PORTLIST                        Y
   61   PostalAddresss  PCDATA          POSTAL
                        lang            ENUM
   62   Process         ------------    ----------      ------------    Y
                        ident           STRING
   63   protocol        PCDATA          STRING                          Y
   64   Record          ------------    ----------      ------------
   65   RecordData      ------------    ----------      ------------
                        ident           STRING
   66   RecordItem      PCDATA          ANY
                        dtype           ENUM
   67   RegistryHandle  PCDATA          STRING
                        type            ENUM

Danyliw                Expires September 7, 2004               [Page 15]

Internet-Draft         IODEF Implementation Guide             March 2004

   68   RelatedActivity ------------    ----------      ------------
   69   ReportTime      PCDATA          DATETIME
                        ntpstamp        NTPSTAMP
   70   Service         PCDATA          STRING                          Y
                        ident           STRING
   71   SNMPService     PCDATA                                          Y
   72   StartTime       PCDATA          DATETIME
                        ntpstamp        NTPSTAMP
   73   System          -----------     ----------      ------------
                        spoofed         ENUM
                        interface       STRING
                        category        ENUM
   74   Telephone       PCDATA          PHONE
        TimeImpact      PCDATA          REAL
                        unit            ENUM
                        severity        ENUM
                        metric          INTEGER
   75   TimeZone        PCDATA          STRING
   76   url             PCDATA          STRING                          Y
   77   User            ------------    ----------      -----------     Y
                        ident           STRING
                        category        ENUM
   78   UserID          PCDATA          STRING                          Y
                        type            ENUM
                        ident           STRING
   79   WebService      PCDATA          STRING                          Y

                                Figure 1

Normative References

   [1]  Demchenko, Y., Hiroyuki, H. and G. Keeni, "Requirements for
        Format for Incident Report Exchange", RFC XXX, September 2003.

   [2]  World Wide Web Consortium, "Extensible Markup Language (XML) 1.0
        (Second Edition)", , October 2000, <http://www.w3.org/TR/2000/

   [3]  World Wide Web Consortium, "Extensible Stylesheet Language (XSL)
        Version 1.0", , October 2001, <http://www.w3.org/TR/xsl/>.

   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.

   [5]  Alvestrand, H., "Tags for the Identification of Languages", RFC
        3066, January 2001.

Danyliw                Expires September 7, 2004               [Page 16]

Internet-Draft         IODEF Implementation Guide             March 2004

   [6]  Curry, D. and H. Debar, "Intrusion Detection Message Exchange
        Format", RFC XXX, January 2003.

   [7]  Meijer, J., Danyliw, R. and Y. Demchenko, "Intrusion Detection
        Message Exchange Format", RFC XXX, January 2003.

   [8]  Eastlake 3rd, D., Reagle, J. and D. Solo, "(Extensible Markup
        Language) XML-Signature Syntax and Processing", RFC 3275, March

   [9]  Imamura, T., Dillaway, B. and E. Simon, "XML Encryption Syntax
        and Processing, W3C Recommendation", December 2002, <http://

Informative References

Author's Address

   Roman Danyliw
   CERT Coordination Center
   4500 Fifth Ave.
   Pittsburgh, PA  15213

   Phone: +1 412 268 7090
   EMail: rdd@cert.org

Danyliw                Expires September 7, 2004               [Page 17]

Internet-Draft         IODEF Implementation Guide             March 2004

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive

Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an

Danyliw                Expires September 7, 2004               [Page 18]

Internet-Draft         IODEF Implementation Guide             March 2004



   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Danyliw                Expires September 7, 2004               [Page 19]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/