tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5070


Pages: 92
Top     in Index     Prev     Next
 

The Incident Object Description Exchange Format

Part 1 of 4, p. 1 to 18
None       Next Section

Obsoleted by:    7970
Updated by:    6685


Top       ToC       Page 1 
Network Working Group                                         R. Danyliw
Request for Comments: 5070                                          CERT
Category: Standards Track                                      J. Meijer
                                                                 UNINETT
                                                            Y. Demchenko
                                                 University of Amsterdam
                                                           December 2007


            The Incident Object Description Exchange Format

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   The Incident Object Description Exchange Format (IODEF) defines a
   data representation that provides a framework for sharing information
   commonly exchanged by Computer Security Incident Response Teams
   (CSIRTs) about computer security incidents.  This document describes
   the information model for the IODEF and provides an associated data
   model specified with XML Schema.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
     1.2.  Notations  . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  About the IODEF Data Model . . . . . . . . . . . . . . . .  5
     1.4.  About the IODEF Implementation . . . . . . . . . . . . . .  6
   2.  IODEF Data Types . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Integers . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Real Numbers . . . . . . . . . . . . . . . . . . . . . . .  7
     2.3.  Characters and Strings . . . . . . . . . . . . . . . . . .  7
     2.4.  Multilingual Strings . . . . . . . . . . . . . . . . . . .  7
     2.5.  Bytes  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.6.  Hexadecimal Bytes  . . . . . . . . . . . . . . . . . . . .  7
     2.7.  Enumerated Types . . . . . . . . . . . . . . . . . . . . .  8
     2.8.  Date-Time Strings  . . . . . . . . . . . . . . . . . . . .  8

Top      ToC       Page 2 
     2.9.  Timezone String  . . . . . . . . . . . . . . . . . . . . .  8
     2.10. Port Lists . . . . . . . . . . . . . . . . . . . . . . . .  8
     2.11. Postal Address . . . . . . . . . . . . . . . . . . . . . .  9
     2.12. Person or Organization . . . . . . . . . . . . . . . . . .  9
     2.13. Telephone and Fax Numbers  . . . . . . . . . . . . . . . .  9
     2.14. Email String . . . . . . . . . . . . . . . . . . . . . . .  9
     2.15. Uniform Resource Locator strings . . . . . . . . . . . . .  9
   3.  The IODEF Data Model . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  IODEF-Document Class . . . . . . . . . . . . . . . . . . . 10
     3.2.  Incident Class . . . . . . . . . . . . . . . . . . . . . . 10
     3.3.  IncidentID Class . . . . . . . . . . . . . . . . . . . . . 14
     3.4.  AlternativeID Class  . . . . . . . . . . . . . . . . . . . 14
     3.5.  RelatedActivity Class  . . . . . . . . . . . . . . . . . . 15
     3.6.  AdditionalData Class . . . . . . . . . . . . . . . . . . . 16
     3.7.  Contact Class  . . . . . . . . . . . . . . . . . . . . . . 18
       3.7.1.  RegistryHandle Class . . . . . . . . . . . . . . . . . 21
       3.7.2.  PostalAddress Class  . . . . . . . . . . . . . . . . . 22
       3.7.3.  Email Class  . . . . . . . . . . . . . . . . . . . . . 22
       3.7.4.  Telephone and Fax Classes  . . . . . . . . . . . . . . 23
     3.8.  Time Classes . . . . . . . . . . . . . . . . . . . . . . . 23
       3.8.1.  StartTime  . . . . . . . . . . . . . . . . . . . . . . 24
       3.8.2.  EndTime  . . . . . . . . . . . . . . . . . . . . . . . 24
       3.8.3.  DetectTime . . . . . . . . . . . . . . . . . . . . . . 24
       3.8.4.  ReportTime . . . . . . . . . . . . . . . . . . . . . . 24
       3.8.5.  DateTime . . . . . . . . . . . . . . . . . . . . . . . 24
     3.9.  Method Class . . . . . . . . . . . . . . . . . . . . . . . 24
       3.9.1.  Reference Class  . . . . . . . . . . . . . . . . . . . 25
     3.10. Assessment Class . . . . . . . . . . . . . . . . . . . . . 25
       3.10.1. Impact Class . . . . . . . . . . . . . . . . . . . . . 27
       3.10.2. TimeImpact Class . . . . . . . . . . . . . . . . . . . 29
       3.10.3. MonetaryImpact Class . . . . . . . . . . . . . . . . . 30
       3.10.4. Confidence Class . . . . . . . . . . . . . . . . . . . 31
     3.11. History Class  . . . . . . . . . . . . . . . . . . . . . . 32
       3.11.1. HistoryItem Class  . . . . . . . . . . . . . . . . . . 33
     3.12. EventData Class  . . . . . . . . . . . . . . . . . . . . . 34
       3.12.1. Relating the Incident and EventData Classes  . . . . . 36
       3.12.2. Cardinality of EventData . . . . . . . . . . . . . . . 37
     3.13. Expectation Class  . . . . . . . . . . . . . . . . . . . . 37
     3.14. Flow Class . . . . . . . . . . . . . . . . . . . . . . . . 40
     3.15. System Class . . . . . . . . . . . . . . . . . . . . . . . 40
     3.16. Node Class . . . . . . . . . . . . . . . . . . . . . . . . 42
       3.16.1. Counter Class  . . . . . . . . . . . . . . . . . . . . 43
       3.16.2. Address Class  . . . . . . . . . . . . . . . . . . . . 45
       3.16.3. NodeRole Class . . . . . . . . . . . . . . . . . . . . 46
     3.17. Service Class  . . . . . . . . . . . . . . . . . . . . . . 48
       3.17.1. Application Class  . . . . . . . . . . . . . . . . . . 50
     3.18. OperatingSystem Class  . . . . . . . . . . . . . . . . . . 51
     3.19. Record Class . . . . . . . . . . . . . . . . . . . . . . . 51

Top      ToC       Page 3 
       3.19.1. RecordData Class . . . . . . . . . . . . . . . . . . . 51
       3.19.2. RecordPattern Class  . . . . . . . . . . . . . . . . . 53
       3.19.3. RecordItem Class . . . . . . . . . . . . . . . . . . . 54
   4.  Processing Considerations  . . . . . . . . . . . . . . . . . . 54
     4.1.  Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 54
     4.2.  IODEF Namespace  . . . . . . . . . . . . . . . . . . . . . 55
     4.3.  Validation . . . . . . . . . . . . . . . . . . . . . . . . 55
   5.  Extending the IODEF  . . . . . . . . . . . . . . . . . . . . . 56
     5.1.  Extending the Enumerated Values of Attributes  . . . . . . 56
     5.2.  Extending Classes  . . . . . . . . . . . . . . . . . . . . 57
   6.  Internationalization Issues  . . . . . . . . . . . . . . . . . 59
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
     7.1.  Worm . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
     7.2.  Reconnaissance . . . . . . . . . . . . . . . . . . . . . . 61
     7.3.  Bot-Net Reporting  . . . . . . . . . . . . . . . . . . . . 63
     7.4.  Watch List . . . . . . . . . . . . . . . . . . . . . . . . 65
   8.  The IODEF Schema . . . . . . . . . . . . . . . . . . . . . . . 66
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 87
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 88
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 88
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 89
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 89
     12.2. Informative References . . . . . . . . . . . . . . . . . . 90

Top      ToC       Page 4 
1.  Introduction

   Organizations require help from other parties to mitigate malicious
   activity targeting their network and to gain insight into potential
   threats.  This coordination might entail working with an ISP to
   filter attack traffic, contacting a remote site to take down a bot-
   network, or sharing watch-lists of known malicious IP addresses in a
   consortium.

   The Incident Object Description Exchange Format (IODEF) is a format
   for representing computer security information commonly exchanged
   between Computer Security Incident Response Teams (CSIRTs).  It
   provides an XML representation for conveying incident information
   across administrative domains between parties that have an
   operational responsibility of remediation or a watch-and-warning over
   a defined constituency.  The data model encodes information about
   hosts, networks, and the services running on these systems; attack
   methodology and associated forensic evidence; impact of the activity;
   and limited approaches for documenting workflow.

   The overriding purpose of the IODEF is to enhance the operational
   capabilities of CSIRTs.  Community adoption of the IODEF provides an
   improved ability to resolve incidents and convey situational
   awareness by simplifying collaboration and data sharing.  This
   structured format provided by the IODEF allows for:

   o  increased automation in processing of incident data, since the
      resources of security analysts to parse free-form textual
      documents will be reduced;

   o  decreased effort in normalizing similar data (even when highly
      structured) from different sources; and

   o  a common format on which to build interoperable tools for incident
      handling and subsequent analysis, specifically when data comes
      from multiple constituencies.

   Coordinating with other CSIRTs is not strictly a technical problem.
   There are numerous procedural, trust, and legal considerations that
   might prevent an organization from sharing information.  The IODEF
   does not attempt to address them.  However, operational
   implementations of the IODEF will need to consider this broader
   context.

   Sections 3 and 8 specify the IODEF data model with text and an XML
   schema.  The types used by the data model are covered in Section 2.
   Processing considerations, the handling of extensions, and
   internationalization issues related to the data model are covered in

Top      ToC       Page 5 
   Sections 4, 5, and 6, respectively.  Examples are listed in Section
   7.  Section 1 provides the background for the IODEF, and Section 9
   documents the security considerations.

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

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

1.2.  Notations

   The normative IODEF data model is specified with the text in Section
   3 and the XML schema in Section 8.  To help in the understanding of
   the data elements, Section 3 also depicts the underlying information
   model using Unified Modeling Language (UML).  This abstract
   presentation of the IODEF is not normative.

   For clarity in this document, the term "XML document" will be used
   when referring generically to any instance of an XML document.  The
   term "IODEF document" will be used to refer to specific elements and
   attributes of the IODEF schema.  The terms "class" and "element" will
   be used interchangeably to reference either the corresponding data
   element in the information or data models, respectively.

1.3.  About the IODEF Data Model

   The IODEF data model is a data representation that provides a
   framework for sharing information commonly exchanged by CSIRTs about
   computer security incidents.  A number of considerations were made in
   the design of the data model.

   o  The data model serves as a transport format.  Therefore, its
      specific representation is not the optimal representation for on-
      disk storage, long-term archiving, or in-memory processing.

   o  As there is no precise widely agreed upon definition for an
      incident, the data model does not attempt to dictate one through
      its implementation.  Rather, a broad understanding is assumed in
      the IODEF that is flexible enough to encompass most operators.

   o  Describing an incident for all definitions would require an
      extremely complex data model.  Therefore, the IODEF only intends
      to be a framework to convey commonly exchanged incident
      information.  It ensures that there are ample mechanisms for

Top      ToC       Page 6 
      extensibility to support organization-specific information, and
      techniques to reference information kept outside of the explicit
      data model.

   o  The domain of security analysis is not fully standardized and must
      rely on free-form textual descriptions.  The IODEF attempts to
      strike a balance between supporting this free-form content, while
      still allowing automated processing of incident information.

   o  The IODEF is only one of several security relevant data
      representations being standardized.  Attempts were made to ensure
      they were complimentary.  The data model of the Intrusion
      Detection Message Exchange Format [17] influenced the design of
      the IODEF.

   Further discussion of the desirable properties for the IODEF can be
   found in the Requirements for the Format for Incident Information
   Exchange (FINE) [16].

1.4.  About the IODEF Implementation

   The IODEF implementation is specified as an Extensible Markup
   Language (XML) [1] Schema [2] in Section 8.

   Implementing the IODEF in XML provides numerous advantages.  Its
   extensibility makes it ideal for specifying a data encoding framework
   that supports various character encodings.  Likewise, the abundance
   of related technologies (e.g., XSL, XPath, XML-Signature) makes for
   simplified manipulation.  However, XML is fundamentally a text
   representation, which makes it inherently inefficient when binary
   data must be embedded or large volumes of data must be exchanged.

2.  IODEF Data Types

   The various data elements of the IODEF data model are typed.  This
   section discusses these data types.  When possible, native Schema
   data types were adopted, but for more complicated formats, regular
   expressions (see Appendix F of [3]) or external standards were used.

2.1.  Integers

   An integer is represented by the INTEGER data type.  Integer data
   MUST be encoded in Base 10.

   The INTEGER data type is implemented as an "xs:integer" [3] in the
   schema.

Top      ToC       Page 7 
2.2.  Real Numbers

   Real (floating-point) attributes are represented by the REAL data
   type.  Real data MUST be encoded in Base 10.

   The REAL data type is implemented as an "xs:float" [3] in the schema.

2.3.  Characters and Strings

   A single character is represented by the CHARACTER data type.  A
   character string is represented by the STRING data type.  Special
   characters must be encoded using entity references.  See Section 4.1.

   The CHARACTER and STRING data types are implement as an "xs:string"
   [3] in the schema.

2.4.  Multilingual Strings

   STRING data that represents multi-character attributes in a language
   different than the default encoding of the document is of the
   ML_STRING data type.

   The ML_STRING data type is implemented as an "iodef:MLStringType" in
   the schema.

2.5.  Bytes

   A binary octet is represented by the BYTE data type.  A sequence of
   binary octets is represented by the BYTE[] data type.  These octets
   are encoded using base64.

   The BYTE data type is implemented as an "xs:base64Binary" [3] in the
   schema.

2.6.  Hexadecimal Bytes

   A binary octet is represented by the HEXBIN (and HEXBIN[]) data type.
   This octet is encoded as a character tuple consisting of two
   hexadecimal digits.

   The HEXBIN data type is implemented as an "xs:hexBinary" [3] in the
   schema.

Top      ToC       Page 8 
2.7.  Enumerated Types

   Enumerated types are represented by the ENUM data type, and consist
   of an ordered list of acceptable values.  Each value has a
   representative keyword.  Within the IODEF schema, the enumerated type
   keywords are used as attribute values.

   The ENUM data type is implemented as a series of "xs:NMTOKEN" in the
   schema.

2.8.  Date-Time Strings

   Date-time strings are represented by the DATETIME data type.  Each
   date-time string identifies a particular instant in time; ranges are
   not supported.

   Date-time strings are formatted according to a subset of ISO 8601:
   2000 [13] documented in RFC 3339 [12].

   The DATETIME data type is implemented as an "xs:dateTime" [3] in the
   schema.

2.9.  Timezone String

   A timezone offset from UTC is represented by the TIMEZONE data type.
   It is formatted according to the following regular expression:
   "Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]".

   The TIMEZONE data type is implemented as an "xs:string" with a
   regular expression constraint in the schema.  This regular expression
   is identical to the timezone representation implemented in an "xs:
   dateTime".

2.10.  Port Lists

   A list of network ports are represented by the PORTLIST data type.  A
   PORTLIST consists of a comma-separated list of numbers and ranges
   (N-M means ports N through M, inclusive).  It is formatted according
   to the following regular expression: "\d+(\-\d+)?(,\d+(\-\d+)?)*".
   For example, "2,5-15,30,32,40-50,55-60".

   The PORTLIST data type is implemented as an "xs:string" with a
   regular expression constraint in the schema.

Top      ToC       Page 9 
2.11.  Postal Address

   A postal address is represented by the POSTAL data type.  This data
   type is an ML_STRING whose format is documented in Section 2.23 of
   RFC 4519 [10].  It defines a postal address as a free-form multi-line
   string separated by the "$" character.

   The POSTAL data type is implemented as an "xs:string" in the schema.

2.12.  Person or Organization

   The name of an individual or organization is represented by the NAME
   data type.  This data type is an ML_STRING whose format is documented
   in Section 2.3 of RFC 4519 [10].

   The NAME data type is implemented as an "xs:string" in the schema.

2.13.  Telephone and Fax Numbers

   A telephone or fax number is represented by the PHONE data type.  The
   format of the PHONE data type is documented in Section 2.35 of RFC
   4519 [10].

   The PHONE data type is implemented as an "xs:string" in the schema.

2.14.  Email String

   An email address is represented by the EMAIL data type.  The format
   of the EMAIL data type is documented in Section 3.4.1 RFC 2822 [11]

   The EMAIL data type is implemented as an "xs:string" in the schema.

2.15.  Uniform Resource Locator strings

   A uniform resource locator (URL) is represented by the URL data type.
   The format of the URL data type is documented in RFC 2396 [8].

   The URL data type is implemented as an "xs:anyURI" in the schema.

3.  The IODEF Data Model

   In this section, the individual components of the IODEF data model
   will be discussed in detail.  For each class, the semantics will be
   described and the relationship with other classes will be depicted
   with UML.  When necessary, specific comments will be made about
   corresponding definition in the schema in Section 8

Top      ToC       Page 10 
3.1.  IODEF-Document Class

   The IODEF-Document class is the top level class in the IODEF data
   model.  All IODEF documents are an instance of this class.

   +-----------------+
   | IODEF-Document  |
   +-----------------+
   | STRING version  |<>--{1..*}--[ Incident     ]
   | ENUM lang       |
   | STRING formatid |
   +-----------------+

                      Figure 1: IODEF-Document Class

   The aggregate class that constitute IODEF-Document is:

   Incident
      One or more.  The information related to a single incident.

   The IODEF-Document class has three attributes:

   version
      Required.  STRING.  The IODEF specification version number to
      which this IODEF document conforms.  The value of this attribute
      MUST be "1.00"

   lang
      Required.  ENUM.  A valid language code per RFC 4646 [7]
      constrained by the definition of "xs:language".  The
      interpretation of this code is described in Section 6.

   formatid
      Optional.  STRING.  A free-form string to convey processing
      instructions to the recipient of the document.  Its semantics must
      be negotiated out-of-band.

3.2.  Incident Class

   Every incident is represented by an instance of the Incident class.
   This class provides a standardized representation for commonly
   exchanged incident data.

Top      ToC       Page 11 
   +--------------------+
   | Incident           |
   +--------------------+
   | ENUM purpose       |<>----------[ IncidentID      ]
   | STRING ext-purpose |<>--{0..1}--[ AlternativeID   ]
   | ENUM lang          |<>--{0..1}--[ RelatedActivity ]
   | ENUM restriction   |<>--{0..1}--[ DetectTime      ]
   |                    |<>--{0..1}--[ StartTime       ]
   |                    |<>--{0..1}--[ EndTime         ]
   |                    |<>----------[ ReportTime      ]
   |                    |<>--{0..*}--[ Description     ]
   |                    |<>--{1..*}--[ Assessment      ]
   |                    |<>--{0..*}--[ Method          ]
   |                    |<>--{1..*}--[ Contact         ]
   |                    |<>--{0..*}--[ EventData       ]
   |                    |<>--{0..1}--[ History         ]
   |                    |<>--{0..*}--[ AdditionalData  ]
   +--------------------+

                       Figure 2: The Incident Class

   The aggregate classes that constitute Incident are:

   IncidentID
      One. An incident tracking number assigned to this incident by the
      CSIRT that generated the IODEF document.

   AlternativeID
      Zero or one.  The incident tracking numbers used by other CSIRTs
      to refer to the incident described in the document.

   RelatedActivity
      Zero or one.  The incident tracking numbers of related incidents.

   DetectTime
      Zero or one.  The time the incident was first detected.

   StartTime
      Zero or one.  The time the incident started.

   EndTime
      Zero or one.  The time the incident ended.

   ReportTime
      One. The time the incident was reported.

Top      ToC       Page 12 
   Description
      Zero or more.  ML_STRING.  A free-form textual description of the
      incident.

   Assessment
      One or more.  A characterization of the impact of the incident.

   Method
      Zero or more.  The techniques used by the intruder in the
      incident.

   Contact
      One or more.  Contact information for the parties involved in the
      incident.

   EventData
      Zero or more.  Description of the events comprising the incident.

   History
      Zero or one.  A log of significant events or actions that occurred
      during the course of handling the incident.

   AdditionalData
      Zero or more.  Mechanism by which to extend the data model.

   The Incident class has four attributes:

   purpose
      Required.  ENUM.  The purpose attribute represents the reason why
      the IODEF document was created.  It is closely related to the
      Expectation class (Section 3.13).  This attribute is defined as an
      enumerated list:

      1.  traceback.  The document was sent for trace-back purposes.

      2.  mitigation.  The document was sent to request aid in
          mitigating the described activity.

      3.  reporting.  The document was sent to comply with reporting
          requirements.

      4.  other.  The document was sent for purposes specified in the
          Expectation class.

      5.  ext-value.  An escape value used to extend this attribute.
          See Section 5.1.

Top      ToC       Page 13 
   ext-purpose
      Optional.  STRING.  A means by which to extend the purpose
      attribute.  See Section 5.1.

   lang
      Optional.  ENUM.  A valid language code per RFC 4646 [7]
      constrained by the definition of "xs:language".  The
      interpretation of this code is described in Section 6.

   restriction
      Optional.  ENUM.  This attribute indicates the disclosure
      guidelines to which the sender expects the recipient to adhere for
      the information represented in this class and its children.  This
      guideline provides no security since there are no specified
      technical means to ensure that the recipient of the document
      handles the information as the sender requested.

      The value of this attribute is logically inherited by the children
      of this class.  That is to say, the disclosure rules applied to
      this class, also apply to its children.

      It is possible to set a granular disclosure policy, since all of
      the high-level classes (i.e., children of the Incident class) have
      a restriction attribute.  Therefore, a child can override the
      guidelines of a parent class, be it to restrict or relax the
      disclosure rules (e.g., a child has a weaker policy than an
      ancestor; or an ancestor has a weak policy, and the children
      selectively apply more rigid controls).  The implicit value of the
      restriction attribute for a class that did not specify one can be
      found in the closest ancestor that did specify a value.

      This attribute is defined as an enumerated value with a default
      value of "private".  Note that the default value of the
      restriction attribute is only defined in the context of the
      Incident class.  In other classes where this attribute is used, no
      default is specified.

      1.  public.  There are no restrictions placed in the information.

      2.  need-to-know.  The information may be shared with other
          parties that are involved in the incident as determined by the
          recipient of this document (e.g., multiple victim sites can be
          informed of each other).

      3.  private.  The information may not be shared.

Top      ToC       Page 14 
      4.  default.  The information can be shared according to an
          information disclosure policy pre-arranged by the
          communicating parties.

3.3.  IncidentID Class

   The IncidentID class represents an incident tracking number that is
   unique in the context of the CSIRT and identifies the activity
   characterized in an IODEF Document.  This identifier would serve as
   an index into the CSIRT incident handling system.  The combination of
   the name attribute and the string in the element content MUST be a
   globally unique identifier describing the activity.  Documents
   generated by a given CSIRT MUST NOT reuse the same value unless they
   are referencing the same incident.

   +------------------+
   | IncidentID       |
   +------------------+
   | STRING           |
   |                  |
   | STRING name      |
   | STRING instance  |
   | ENUM restriction |
   +------------------+

                      Figure 3: The IncidentID Class

   The IncidentID class has three attributes:

   name
      Required.  STRING.  An identifier describing the CSIRT that
      created the document.  In order to have a globally unique CSIRT
      name, the fully qualified domain name associated with the CSIRT
      MUST be used.

   instance
      Optional.  STRING.  An identifier referencing a subset of the
      named incident.

   restriction
      Optional.  ENUM.  This attribute has been defined in Section 3.2.

3.4.  AlternativeID Class

   The AlternativeID class lists the incident tracking numbers used by
   CSIRTs, other than the one generating the document, to refer to the
   identical activity described the IODEF document.  A tracking number
   listed as an AlternativeID references the same incident detected by

Top      ToC       Page 15 
   another CSIRT.  The incident tracking numbers of the CSIRT that
   generated the IODEF document should never be considered an
   AlternativeID.

         +------------------+
         | AlternativeID    |
         +------------------+
         | ENUM restriction |<>--{1..*}--[ IncidentID ]
         |                  |
         +------------------+

                     Figure 4: The AlternativeID Class

   The aggregate class that constitutes AlternativeID is:

   IncidentID
      One or more.  The incident tracking number of another CSIRT.

   The AlternativeID class has one attribute:

   restriction
      Optional.  ENUM.  This attribute has been defined in Section 3.2.

3.5.  RelatedActivity Class

   The RelatedActivity class lists either incident tracking numbers of
   incidents or URLs (not both) that refer to activity related to the
   one described in the IODEF document.  These references may be to
   local incident tracking numbers or to those of other CSIRTs.

   The specifics of how a CSIRT comes to believe that two incidents are
   related are considered out of scope.

         +------------------+
         | RelatedActivity  |
         +------------------+
         | ENUM restriction |<>--{0..*}--[ IncidentID ]
         |                  |<>--{0..*}--[ URL        ]
         +------------------+

                      Figure 5: RelatedActivity Class

Top      ToC       Page 16 
   The aggregate classes that constitutes RelatedActivity are:

   IncidentID
      One or more.  The incident tracking number of a related incident.

   URL
      One or more.  URL.  A URL to activity related to this incident.

   The RelatedActivity class has one attribute:

   restriction
      Optional.  ENUM.  This attribute has been defined in Section 3.2.

3.6.  AdditionalData Class

   The AdditionalData class serves as an extension mechanism for
   information not otherwise represented in the data model.  For
   relatively simple information, atomic data types (e.g., integers,
   strings) are provided with a mechanism to annotate their meaning.
   The class can also be used to extend the data model (and the
   associated Schema) to support proprietary extensions by encapsulating
   entire XML documents conforming to another Schema (e.g., IDMEF).  A
   detailed discussion for extending the data model and the schema can
   be found in Section 5.

   Unlike XML, which is self-describing, atomic data must be documented
   to convey its meaning.  This information is described in the
   'meaning' attribute.  Since these description are outside the scope
   of the specification, some additional coordination may be required to
   ensure that a recipient of a document using the AdditionalData
   classes can make sense of the custom extensions.

   +------------------+
   | AdditionalData   |
   +------------------+
   | ANY              |
   |                  |
   | ENUM dtype       |
   | STRING ext-dtype |
   | STRING meaning   |
   | STRING formatid  |
   | ENUM restriction |
   +------------------+

                    Figure 6: The AdditionalData Class

Top      ToC       Page 17 
   The AdditionalData class has five attributes:

   dtype
      Required.  ENUM.  The data type of the element content.  The
      permitted values for this attribute are shown below.  The default
      value is "string".

      1.   boolean.  The element content is of type BOOLEAN.

      2.   byte.  The element content is of type BYTE.

      3.   character.  The element content is of type CHARACTER.

      4.   date-time.  The element content is of type DATETIME.

      5.   integer.  The element content is of type INTEGER.

      6.   portlist.  The element content is of type PORTLIST.

      7.   real.  The element content is of type REAL.

      8.   string.  The element content is of type STRING.

      9.   file.  The element content is a base64 encoded binary file
           encoded as a BYTE[] type.

      10.  frame.  The element content is a layer-2 frame encoded as a
           HEXBIN type.

      11.  packet.  The element content is a layer-3 packet encoded as a
           HEXBIN type.

      12.  ipv4-packet.  The element content is an IPv4 packet encoded
           as a HEXBIN type.

      13.  ipv6-packet.  The element content is an IPv6 packet encoded
           as a HEXBIN type.

      14.  path.  The element content is a file-system path encoded as a
           STRING type.

      15.  url.  The element content is of type URL.

      16.  csv.  The element content is a common separated value (CSV)
           list per Section 2 of [20] encoded as a STRING type.

      17.  winreg.  The element content is a Windows registry key
           encoded as a STRING type.

Top      ToC       Page 18 
      18.  xml.  The element content is XML (see Section 5).

      19.  ext-value.  An escape value used to extend this attribute.
           See Section 5.1.

   ext-dtype
      Optional.  STRING.  A means by which to extend the dtype
      attribute.  See Section 5.1.

   meaning
      Optional.  STRING.  A free-form description of the element
      content.

   formatid
      Optional.  STRING.  An identifier referencing the format and
      semantics of the element content.

   restriction
      Optional.  ENUM.  This attribute has been defined in Section 3.2.



(page 18 continued on part 2)

Next RFC Part