Internet DRAFT - draft-ietf-inch-implement

draft-ietf-inch-implement



INCH Working Group                                            R. Danyliw
draft-ietf-inch-implement-01.txt                CERT Coordination Center
Expires: May 10, 2005                                  November 09, 2004


        The Incident Object Description Exchange Format (IODEF)
                          Implementation Guide
                      draft-ietf-inch-implement-01

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed, or
   will be disclosed, and any of which I become aware will be disclosed,
   in accordance with RFC 3668.

   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://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 10, 2005.

Abstract

   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 May 10, 2005                  [Page 1]


Internet-Draft         IODEF Implementation Guide          November 2004


Table of Contents

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







Danyliw                   Expires May 10, 2005                  [Page 2]


Internet-Draft         IODEF Implementation Guide          November 2004


1.  Introduction

1.1  Terminology

   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 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 informati
on for
   IODEF implementers.  Section 1 outlines the operational assumptions
   and context in which the IODEF will be used.  Section 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 May 10, 2005                  [Page 3]


Internet-Draft         IODEF Implementation Guide          November 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.





















Danyliw                   Expires May 10, 2005                  [Page 4]


Internet-Draft         IODEF Implementation Guide          November 2004


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
   exist.

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?






Danyliw                   Expires May 10, 2005                  [Page 5]


Internet-Draft         IODEF Implementation Guide          November 2004


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.

   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 mig
ht 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 contents.  A profile MUST
   disambiguate the semantics of all the subjective values (see Section



Danyliw                   Expires May 10, 2005                  [Page 6]


Internet-Draft         IODEF Implementation Guide          November 2004


   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
   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
   all









Danyliw                   Expires May 10, 2005                  [Page 7]


Internet-Draft         IODEF Implementation Guide          November 2004


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
      step.

   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



Danyliw                   Expires May 10, 2005                  [Page 8]


Internet-Draft         IODEF Implementation Guide          November 2004


      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
   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 wit
h 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



Danyliw                   Expires May 10, 2005                  [Page 9]


Internet-Draft         IODEF Implementation Guide          November 2004


   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
   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



Danyliw                   Expires May 10, 2005                 [Page 10]


Internet-Draft         IODEF Implementation Guide          November 2004


   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.

   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



Danyliw                   Expires May 10, 2005                 [Page 11]


Internet-Draft         IODEF Implementation Guide          November 2004


   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?










































Danyliw                   Expires May 10, 2005                 [Page 12]


Internet-Draft         IODEF Implementation Guide          November 2004


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
      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



Danyliw                   Expires May 10, 2005                 [Page 13]


Internet-Draft         IODEF Implementation Guide          November 2004


      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.










































Danyliw                   Expires May 10, 2005                 [Page 14]


Internet-Draft         IODEF Implementation Guide          November 2004


5.  Representation Examples


5.1  Multiple Contacts

5.2  Expectation

5.3  Sequence of Events

5.4  Summarization using the Counter class

5.5  XML-Signature

5.6  XML-Encryption

5.7  Non-English example

5.8  Translations

































Danyliw                   Expires May 10, 2005                 [Page 15]


Internet-Draft         IODEF Implementation Guide          November 2004


6.  Acknowledgments


















































Danyliw                   Expires May 10, 2005                 [Page 16]


Internet-Draft         IODEF Implementation Guide          November 2004


7.  Appendix 1

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



          Element Name	 Attribute       Datatype        Type         IDMEF
   ============================================================================
   1     AdditionalData    ------------	ANY		FREEFORM		Y
   				type			ENUM		STRUCTURED
   				meaning		STRING	FREEFORM
   2	Address		PCDATA		STRING	FREEFORM
   				vlan-num		INTEGER	FREEFORM
   				vlan-name		STRING	FREEFORM
   				category		ENUM		STRUCTURED
   3	AlternativeID	------------	----------	-----------
   4	Analyzer		------------	----------	-----------		Y
   				version		STRING	FREEFORM		Y
   				osversion		STRING	FREEFORM		Y
   				ostype		STRING	FREEFORM		Y
   				model			STRING	FREEFORM		Y
   				manufacterer	STRING	FREEFORM		Y
   				class			STRING	FREEFORM		Y
   				analyzerid		STRING	FREEFORM		Y
   5	arg			PCDATA		STRING	FREEFORM		Y
   6	Assessment		------------ 	----------	------------
   7	Classification	-----------		----------	------------
   				origin		ENUM + O	STRUCTURED
   8	command		PCDATA		STRING	FREEFORM		Y
   9	Confidence		PCDATA		REAL		SUBJECTIVE		Y
   				rating		ENUM		SUBJECTIVE		Y
   10	Contact		------------	----------	------------
   				contacttype		ENUM		STRUCTURED
   				contactrole		ENUM		STRUCTURED
   11	Counter		PCDATA		INTEGER	STRUCTURED
   				type			ENUM		STRUCTURED
   				meaning		STRING	FREEFORM
   12	DateTime		PCDATA		DATETIME	STRUCTURED
   13	Description		PCDATA		STRING	FREEFORM
   				transform		ENUM		STRUCTURED
   				preserve		ENUM		STRUCTURED
   				lang			ENUM		STRUCTURED
   14	DetectTime		PCDATA		DATETIME	STRUCTURED
   15	Email			PCDATA		EMAIL		STRUCTURED
   16	EndTime		PCDATA		DATETIME	STRUCTURED
   17	env			PCDATA		STRING	FREEFORM		Y
   18	EventData		------------	----------	------------



Danyliw                   Expires May 10, 2005                 [Page 17]


Internet-Draft         IODEF Implementation Guide          November 2004


   19	Expectation		------------	----------	------------
   				priority		ENUM		SUBJECTIVE
   				category		ENUM		STRUCTURED
   20	Fax			PCDATA		PHONE		STRUCTURED
   21	Flow			----------- 	---------	------------
   22	History		-----------		---------	------------
   				type			ENUM+O	STRUCTURED
   23	HistoryItem		------------	----------	------------
   24	Impact		PCDATA		STRING	FREEFORM		Y
   				type			ENUM+O	STRUCTURED		Y
   				severity		ENUM		SUBJECTIVE		Y
   				lang			ENUM		STRUCTURED		Y
   				completion		ENUM		STRUCTURED		Y
   25	Incident		------------	----------	------------
   				purpose		ENUM+O	STRUCTURED
   26	IncidentID		PCDATA		UID		SUBJECTIVE
   				name			GUID		STRUCTURED
   27	IODEF-Document	------------	----------	------------
   				version		STRING	STRUCTURED
   28	Location		PCDATA		STRING	FREEFORM
   				lang			ENUM		STRUCTURED
   29	Method		------------	----------	------------
   30	MonetaryImpact	PCDATA		REAL		STRUCTURED
   				severity		ENUM		SUBJECTIVE
   				currency		ENUM		STRUCTURED
   31	Name			PCDATA		STRING	STRUCTURED
   				transform		ENUM		STRUCTURED
   				preserve		ENUM		STRUCTURED
   				lang			ENUM		STRUCTURED
   32	name			PCDATA		STRING	FREEFORM
   				lang			ENUM		STRUCTURED
   33	Node			------------	----------	------------
   				category		ENUM		STRUCTURED
   34	NodeRole		PCDATA		STRING	FREEFORM
   				lang			ENUM		STRUCTURED
   				category		ENUM+O	STRUCTURED
   35	path			PCDATA		STRING	FREEFORM		Y
   36	pid			PCDATA		STRING	FREEFORM		Y
   37	port			PCDATA		INTEGER	STRUCTURED		Y
   38	portlist		PCDATA		PORTLIST	STRUCTURED		Y
   39	PostalAddresss	PCDATA		POSTAL	STRUCTURED
   				lang			ENUM		STRUCTURED
   40	Process		------------	----------	------------	Y
   				ident			STRING	FREEFORM
   41	Record		------------	----------	------------
   42	RecordData		------------	----------	------------
   				ident			STRING	FREEFORM
   43	RecordItem		PCDATA		ANY		FREEFORM



Danyliw                   Expires May 10, 2005                 [Page 18]


Internet-Draft         IODEF Implementation Guide          November 2004


   				dtype			ENUM		STRUCTURED
   44	RegistryHandle	PCDATA		STRING	FREEFORM
   				type			ENUM		STRUCTURED
   45	RelatedActivity	------------	----------	------------
   46	ReportTime		PCDATA		DATETIME	STRUCTURED
   47	Service		------------	----------	------------
   				ip_version		INTEGER	STRUCTURED
   				ip_protocol		INTEGER	STRUCTURED
   48	StartTime		PCDATA		DATETIME	STRUCTURED
   49	System		-----------		----------	------------
   				spoofed		ENUM		STRUCTURED
   				interface		STRING	FREEFORM
   				category		ENUM		STRUCTURED
   50	Telephone		PCDATA		PHONE		STRUCTURED
   51	TimeImpact		PCDATA		REAL		STRUCTURED
   				unit			ENUM		STRUCTURED
   				severity		ENUM		SUBJECTIVE
   				metric		INTEGER	STRUCTURED
   52	TimeZone		PCDATA		STRING	STRUCTURED
   53	url			PCDATA		STRING	STRUCTURED		Y


                                Figure 1




























Danyliw                   Expires May 10, 2005                 [Page 19]


Internet-Draft         IODEF Implementation Guide          November 2004


8.  References

8.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/REC-xml-20001006>.

   [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.

   [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
        2002.

   [9]  Imamura, T., Dillaway, B. and E. Simon, "XML Encryption Syntax
        and Processing, W3C Recommendation", December 2002,
        <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/>.



Author's Address

   Roman Danyliw
   CERT Coordination Center
   4500 Fifth Ave.
   Pittsburgh, PA  15213
   USA
   EMail: rdd@cert.org




Danyliw                   Expires May 10, 2005                 [Page 20]


Internet-Draft         IODEF Implementation Guide          November 2004


Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE REPRESENTS
   THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 
   ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
   FOR A PARTICULAR PURPOSE.







































Danyliw                   Expires May 10, 2005                 [Page 21]