Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5070

The Incident Object Description Exchange Format

Pages: 92
Obsoleted by:  7970
Updated by:  6685
Part 1 of 4 – Pages 1 to 18
None   None   Next

ToP   noToC   RFC5070 - 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   noToC   RFC5070 - 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   noToC   RFC5070 - 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   noToC   RFC5070 - 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   noToC   RFC5070 - 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   noToC   RFC5070 - 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   noToC   RFC5070 - 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   noToC   RFC5070 - 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   noToC   RFC5070 - 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   noToC   RFC5070 - 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   noToC   RFC5070 - 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   noToC   RFC5070 - 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   noToC   RFC5070 - 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   noToC   RFC5070 - 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   noToC   RFC5070 - 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   noToC   RFC5070 - 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   noToC   RFC5070 - 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   noToC   RFC5070 - 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 Section