tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5070

 
 
 

The Incident Object Description Exchange Format

Part 3 of 4, p. 42 to 66
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 42 
3.16.  Node Class

   The Node class names a system (e.g., PC, router) or network.

   This class was derived from the IDMEF [17].

Top      Up      ToC       Page 43 
   +---------------+
   | Node          |
   +---------------+
   |               |<>--{0..*}--[ NodeName ]
   |               |<>--{0..*}--[ Address  ]
   |               |<>--{0..1}--[ Location ]
   |               |<>--{0..1}--[ DateTime ]
   |               |<>--{0..*}--[ NodeRole ]
   |               |<>--{0..*}--[ Counter  ]
   +---------------+

                         Figure 27: The Node Class

   The aggregate classes that constitute Node are:

   NodeName
      Zero or more.  ML_STRING.  The name of the Node (e.g., fully
      qualified domain name).  This information MUST be provided if no
      Address information is given.

   Address
      Zero or more.  The hardware, network, or application address of
      the Node.  If a NodeName is not provided, at least one Address
      MUST be specified.

   Location
      Zero or one.  ML_STRING.  A free-from description of the physical
      location of the equipment.

   DateTime
      Zero or one.  A timestamp of when the resolution between the name
      and address was performed.  This information SHOULD be provided if
      both an Address and NodeName are specified.

   NodeRole
      Zero or more.  The intended purpose of the Node.

   Counter
      Zero or more.  A counter with which to summarizes properties of
      this host or network.

3.16.1.  Counter Class

   The Counter class summarize multiple occurrences of some event, or
   conveys counts or rates on various features (e.g., packets, sessions,
   events).

Top      Up      ToC       Page 44 
   The value of the counter is the element content with its units
   represented in the type attribute.  A rate for a given feature can be
   expressed by setting the duration attribute.  The complete semantics
   are entirely context dependent based on the class in which the
   Counter is aggregated.

   +---------------------+
   | Counter             |
   +---------------------+
   | REAL                |
   |                     |
   | ENUM type           |
   | STRING ext-type     |
   | STRING meaning      |
   | ENUM duration       |
   | STRING ext-duration |
   +---------------------+

                       Figure 28: The Counter Class

   The Counter class has three attribute:

   type
      Required.  ENUM.  Specifies the units of the element content.

      1.   byte.  Count of bytes.

      2.   packet.  Count of packets.

      3.   flow.  Count of flow (e.g., NetFlow records).

      4.   session.  Count of sessions.

      5.   alert.  Count of notifications generated by another system
           (e.g., IDS or SIM).

      6.   message.  Count of messages (e.g., mail messages).

      7.   event.  Count of events.

      8.   host.  Count of hosts.

      9.   site.  Count of site.

      10.  organization.  Count of organizations.

Top      Up      ToC       Page 45 
      11.  ext-value.  An escape value used to extend this attribute.
           See Section 5.1.

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

   duration
      Optional.  ENUM.  If present, the Counter class represents a rate
      rather than a count over the entire event.  In that case, this
      attribute specifies the denominator of the rate (where the type
      attribute specified the nominator).  The possible values of this
      attribute are defined in Section 3.10.2

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

3.16.2.  Address Class

   The Address class represents a hardware (layer-2), network (layer-3),
   or application (layer-7) address.

   This class was derived from the IDMEF [17].

   +---------------------+
   | Address             |
   +---------------------+
   | ENUM category       |
   | STRING ext-category |
   | STRING vlan-name    |
   | INTEGER vlan-num    |
   +---------------------+

                       Figure 29: The Address Class

   The Address class has four attributes:

   category
      Required.  ENUM.  The type of address represented.  The permitted
      values for this attribute are shown below.  The default value is
      "ipv4-addr".

      1.   asn.  Autonomous System Number

      2.   atm.  Asynchronous Transfer Mode (ATM) address

Top      Up      ToC       Page 46 
      3.   e-mail.  Electronic mail address (RFC 822)

      4.   ipv4-addr.  IPv4 host address in dotted-decimal notation
           (a.b.c.d)

      5.   ipv4-net.  IPv4 network address in dotted-decimal notation,
           slash, significant bits (a.b.c.d/nn)

      6.   ipv4-net-mask.  IPv4 network address in dotted-decimal
           notation, slash, network mask in dotted-decimal notation
           (a.b.c.d/w.x.y.z)

      7.   ipv6-addr.  IPv6 host address

      8.   ipv6-net.  IPv6 network address, slash, significant bits

      9.   ipv6-net-mask.  IPv6 network address, slash, network mask

      10.  mac.  Media Access Control (MAC) address

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

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

   vlan-name
      Optional.  STRING.  The name of the Virtual LAN to which the
      address belongs.

   vlan-num
      Optional.  STRING.  The number of the Virtual LAN to which the
      address belongs.

3.16.3.  NodeRole Class

   The NodeRole class describes the intended function performed by a
   particular host.

Top      Up      ToC       Page 47 
         +---------------------+
         | NodeRole            |
         +---------------------+
         | ENUM category       |
         | STRING ext-category |
         | ENUM lang           |
         +---------------------+

                       Figure 30: The NodeRole Class

   The NodeRole class has three attributes:

   category
      Required.  ENUM.  Functionality provided by a node.

      1.   client.  Client computer

      2.   server-internal.  Server with internal services

      3.   server-public.  Server with public services

      4.   www.  WWW server

      5.   mail.  Mail server

      6.   messaging.  Messaging server (e.g., NNTP, IRC, IM)

      7.   streaming.  Streaming-media server

      8.   voice.  Voice server (e.g., SIP, H.323)

      9.   file.  File server (e.g., SMB, CVS, AFS)

      10.  ftp.  FTP server

      11.  p2p.  Peer-to-peer node

      12.  name.  Name server (e.g., DNS, WINS)

      13.  directory.  Directory server (e.g., LDAP, finger, whois)

      14.  credential.  Credential server (e.g., domain controller,
           Kerberos)

      15.  print.  Print server

      16.  application.  Application server

Top      Up      ToC       Page 48 
      17.  database.  Database server

      18.  infra.  Infrastructure server (e.g., router, firewall, DHCP)

      19.  log.  Logserver (e.g., syslog)

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

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

   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.

3.17.  Service Class

   The Service class describes a network service of a host or network.
   The service is identified by specific port or list of ports, along
   with the application listening on that port.

   When Service occurs as an aggregate class of a System that is a
   source, then this service is the one from which activity of interest
   is originating.  Conversely, when Service occurs as an aggregate
   class of a System that is a target, then that service is the one to
   which activity of interest is directed.

   This class was derived from the IDMEF [17].

   +---------------------+
   | Service             |
   +---------------------+
   | INTEGER ip_protocol |<>--{0..1}--[ Port        ]
   |                     |<>--{0..1}--[ Portlist    ]
   |                     |<>--{0..1}--[ ProtoCode   ]
   |                     |<>--{0..1}--[ ProtoType   ]
   |                     |<>--{0..1}--[ ProtoFlags  ]
   |                     |<>--{0..1}--[ Application ]
   +---------------------+

                       Figure 31: The Service Class

   The aggregate classes that constitute Service are:

Top      Up      ToC       Page 49 
   Port
      Zero or one.  INTEGER.  A port number.

   Portlist
      Zero or one.  PORTLIST.  A list of port numbers formatted
      according to Section 2.10.

   ProtoCode
      Zero or one.  INTEGER.  A layer-4 protocol-specific code field
      (e.g., ICMP code field).

   ProtoType
      Zero or one.  INTEGER.  A layer-4 protocol specific type field
      (e.g., ICMP type field).

   ProtoFlags
      Zero or one.  INTEGER.  A layer-4 protocol specific flag field
      (e.g., TCP flag field).

   Application
      Zero or more.  The application bound to the specified Port or
      Portlist.

   Either a Port or Portlist class MUST be specified for a given
   instance of a Service class.

   For a given source, System@type="source", a corresponding target,
   System@type="target", maybe defined, or vice versa.  When a Portlist
   class is defined in the Service class of both the source and target
   in a given instance of the Flow class, there MUST be symmetry in the
   enumeration of the ports.  Thus, if n-ports are listed for a source,
   n-ports should be listed for the target.  Likewise, the ports should
   be listed in an identical sequence such that the n-th port in the
   source corresponds to the n-th port of the target.  This symmetry in
   listing and sequencing of ports applies whether there are 1-to-1,
   1-to-many, or many-to-many sources-to-targets.  In the 1-to-many or
   many-to-many, the exact order in which the System classes are
   enumerated in the Flow class is significant.

   The Service class has one attribute:

   ip_protocol
      Required.  INTEGER.  The IANA protocol number.

Top      Up      ToC       Page 50 
3.17.1.  Application Class

   The Application class describes an application running on a System
   providing a Service.

   +--------------------+
   | Application        |
   +--------------------+
   | STRING swid        |<>--{0..1}--[ URL        ]
   | STRING configid    |
   | STRING vendor      |
   | STRING family      |
   | STRING name        |
   | STRING version     |
   | STRING patch       |
   +--------------------+

                     Figure 32: The Application Class

   The aggregate class that constitutes Application is:

   URL
      Zero or one.  URL.  A URL describing the application.

   The Application class has seven attributes:

   swid
      Optional.  STRING.  An identifier that can be used to reference
      this software.

   configid
      Optional.  STRING.  An identifier that can be used to reference a
      particular configuration of this software.

   vendor
      Optional.  STRING.  Vendor name of the software.

   family
      Optional.  STRING.  Family of the software.

   name
      Optional.  STRING.  Name of the software.

   version
      Optional.  STRING.  Version of the software.

Top      Up      ToC       Page 51 
   patch
      Optional.  STRING.  Patch or service pack level of the software.

3.18.  OperatingSystem Class

   The OperatingSystem class describes the operating system running on a
   System.  The definition is identical to the Application class
   (Section 3.17.1).

3.19.  Record Class

   The Record class is a container class for log and audit data that
   provides supportive information about the incident.  The source of
   this data will often be the output of monitoring tools.  These logs
   should substantiate the activity described in the document.

   +------------------+
   | Record           |
   +------------------+
   | ENUM restriction |<>--{1..*}--[ RecordData ]
   +------------------+

                          Figure 33: Record Class

   The aggregate class that constitutes Record is:

   RecordData
      One or more.  Log or audit data generated by a particular type of
      sensor.  Separate instances of the RecordData class SHOULD be used
      for each sensor type.

   The Record class has one attribute:

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

3.19.1.  RecordData Class

   The RecordData class groups log or audit data from a given sensor
   (e.g., IDS, firewall log) and provides a way to annotate the output.

Top      Up      ToC       Page 52 
   +------------------+
   | RecordData       |
   +------------------+
   | ENUM restriction |<>--{0..1}--[ DateTime        ]
   |                  |<>--{0..*}--[ Description     ]
   |                  |<>--{0..1}--[ Application     ]
   |                  |<>--{0..*}--[ RecordPattern   ]
   |                  |<>--{1..*}--[ RecordItem      ]
   |                  |<>--{0..*}--[ AdditionalData  ]
   +------------------+

                      Figure 34: The RecordData Class

   The aggregate classes that constitutes RecordData is:

   DateTime
      Zero or one.  Timestamp of the RecordItem data.

   Description
      Zero or more.  ML_STRING.  Free-form textual description of the
      provided RecordItem data.  At minimum, this description should
      convey the significance of the provided RecordItem data.

   Application
      Zero or one.  Information about the sensor used to generate the
      RecordItem data.

   RecordPattern
      Zero or more.  A search string to precisely find the relevant data
      in a RecordItem.

   RecordItem
      One or more.  Log, audit, or forensic data.

   AdditionalData
      Zero or one.  An extension mechanism for data not explicitly
      represented in the data model.

   The RecordData class has one attribute:

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

Top      Up      ToC       Page 53 
3.19.2.  RecordPattern Class

   The RecordPattern class describes where in the content of the
   RecordItem relevant information can be found.  It provides a way to
   reference subsets of information, identified by a pattern, in a large
   log file, audit trail, or forensic data.

   +-----------------------+
   | RecordPattern         |
   +-----------------------+
   | STRING                |
   |                       |
   | ENUM type             |
   | STRING ext-type       |
   | INTEGER offset        |
   | ENUM offsetunit       |
   | STRING ext-offsetunit |
   | INTEGER instance      |
   +-----------------------+

                    Figure 35: The RecordPattern Class

   The specific pattern to search with in the RecordItem is defined in
   the body of the element.  It is further annotated by four attributes:

   type
      Required.  ENUM.  Describes the type of pattern being specified in
      the element content.  The default is "regex".

      1.  regex. regular expression, per Appendix F of [3].

      2.  binary.  Binhex encoded binary pattern, per the HEXBIN data
          type.

      3.  xpath.  XML Path (XPath) [5]

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

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

   offset
      Optional.  INTEGER.  Amount of units (determined by the offsetunit
      attribute) to seek into the RecordItem data before matching the
      pattern.

Top      Up      ToC       Page 54 
   offsetunit
      Optional.  ENUM.  Describes the units of the offset attribute.
      The default is "line".

      1.  line.  Offset is a count of lines.

      2.  binary.  Offset is a count of bytes.

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

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

   instance
      Optional.  INTEGER.  Number of types to apply the specified
      pattern.

3.19.3.  RecordItem Class

   The RecordItem class provides a way to incorporate relevant logs,
   audit trails, or forensic data to support the conclusions made during
   the course of analyzing the incident.  The class supports both the
   direct encapsulation of the data, as well as, provides primitives to
   reference data stored elsewhere.

   This class is identical to AdditionalData class (Section 3.6).

4.  Processing Considerations

   This section defines additional requirements on creating and parsing
   IODEF documents.

4.1.  Encoding

   Every IODEF document MUST begin with an XML declaration, and MUST
   specify the XML version used.  If UTF-8 encoding is not used, the
   character encoding MUST also be explicitly specified.  The IODEF
   conforms to all XML data encoding conventions and constraints.

   The XML declaration with no character encoding will read as follows:

   <?xml version="1.0" ?>

   When a character encoding is specified, the XML declaration will read
   like the following:

Top      Up      ToC       Page 55 
   <?xml version="1.0" encoding="charset" ?>

   Where "charset" is the name of the character encoding as registered
   with the Internet Assigned Numbers Authority (IANA), see [9].

   The following characters have special meaning in XML and MUST be
   escaped with their entity reference equivalent: "&", "<", ">", "\""
   (double quotation mark), and "'" (apostrophe).  These entity
   references are "&amp;", "&lt;", "&gt;", "&quot;", and "&apos;"
   respectively.

4.2.  IODEF Namespace

   The IODEF schema declares a namespace of
   "urn:ietf:params:xml:ns:iodef-1.0" and registers it per [4].  Each
   IODEF document SHOULD include a valid reference to the IODEF schema
   using the "xsi:schemaLocation" attribute.  An example of such a
   declaration would look as follows:

   <IODEF-Document
      version="1.00" lang="en-US"
      xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
      xsi:schemaLocation="urn:ietf:params:xmls:schema:iodef-1.0">

4.3.  Validation

   The IODEF documents MUST be well-formed XML and SHOULD be validated
   against the schema described in Section 8.  However, mere conformance
   to the schema is not sufficient for a semantically valid IODEF
   document.  There is additional specification in the text of Section 3
   that cannot be readily encoded in the schema and it must also be
   considered by an IODEF parser.  The following is a list of
   discrepancies in what is more strictly specified in the normative
   text (Section 3), but not enforced in the IODEF schema:

   o  The elements or attributes that are defined as POSTAL, NAME,
      PHONE, and EMAIL data-types are implemented as "xs:string", but
      more rigid formatting requirements are specified in the text.

   o  The IODEF-Document@lang and MLStringType@lang attributes are
      declared as an "xs:language" that constrains values with a regular
      expression.  However, the value of this attribute still needs to
      be validated against the list of possible enumerated values is
      defined in [7].

   o  The MonetaryImpact@currency attribute is declared as an "xs:
      string", but the list of valid values as defined in [14].

Top      Up      ToC       Page 56 
   o  All of the aggregated classes Contact and EventData are optional
      in the schema, but at least one of these aggregated classes MUST
      be present.

   o  There are multiple conventions that can be used to categorize a
      system using the NodeRole class or to specify software with the
      Application and OperatingSystem classes.  IODEF parsers MUST
      accept incident reports that do not use these fields in accordance
      with local conventions.

   o  The Confidence@rating attribute determines whether the element
      content of Confidence should be empty.

   o  The Address@type attribute determines the format of the element
      content.

   o  The attributes AdditionalData@dtype and RecordItem@dtype derived
      from iodef:ExtensionType determine the semantics and formatting of
      the element content.

   o  Symmetry in the enumerated ports of a Portlist class is required
      between sources and targets.  See Section 3.17.

5.  Extending the IODEF

   In order to support the changing activity of CSIRTS, the IODEF data
   model will need to evolve along with them.  This section discusses
   how new data elements that have no current representation in the data
   model can be incorporated into the IODEF.  These techniques are
   designed so that adding new data will not require a change to the
   IODEF schema.  With proven value, well documented extensions can be
   incorporated into future versions of the specification.  However,
   this approach also supports private extensions relevant only to a
   closed consortium.

5.1.  Extending the Enumerated Values of Attributes

   The data model supports a means by which to add new enumerated values
   to an attribute.  For each attribute that supports this extension
   technique, there is a corresponding attribute in the same element
   whose name is identical, less a prefix of "ext-".  This special
   attribute is referred to as the extension attribute, and the
   attribute being extended is referred to as an extensible attribute.
   For example, an extensible attribute named "foo" will have a
   corresponding extension attribute named "ext-foo".  An element may
   have many extensible, and therefore many extension, attributes.

Top      Up      ToC       Page 57 
   In addition to a corresponding extension attribute, each extensible
   attribute has "ext-value" as one its possible values.  This
   particular value serves as an escape sequence and has no valid
   meaning.

   In order to add a new enumerated value to an extensible attribute,
   the value of this attribute MUST be set to "ext-value", and the new
   desired value MUST be set in the corresponding extension attribute.
   For example, an extended instance of the type attribute of the Impact
   class would look as follows:

    <Impact type="ext-value" ext-type="new-attack-type">

   A given extension attribute MUST NOT be set unless the corresponding
   extensible attribute has been set to "ext-value".

5.2.  Extending Classes

   The classes of the data model can be extended only through the use of
   the AdditionalData and RecordItem classes.  These container classes,
   collectively referred to as the extensible classes, are implemented
   with the iodef:ExtensionType data type in the schema.  They provide
   the ability to have new atomic or XML-encoded data elements in all of
   the top-level classes of the Incident class and a few of the more
   complicated subordinate classes.  As there are multiple instances of
   the extensible classes in the data model, there is discretion on
   where to add a new data element.  It is RECOMMENDED that the
   extension be placed in the most closely related class to the new
   information.

   Extensions using the atomic data types (i.e., all values of the dtype
   attributes other than "xml") MUST:

   1.  Set the element content of extensible class to the desired value,
       and

   2.  Set the dtype attribute to correspond to the data type of the
       element content.

   The following guidelines exist for extensions using XML:

   1.  The element content of the extensible class MUST be set to the
       desired value and the dtype attribute MUST be set to "xml".

   2.  The extension schema MUST declare a separate namespace.  It is
       RECOMMENDED that these extensions have the prefix "iodef-".

Top      Up      ToC       Page 58 
   3.  It is RECOMMENDED that extension schemas follow the naming
       convention of the IODEF data model.  The names of all elements
       are capitalized.  For composed names, a capital letter is used
       for each word.  Attribute names are lower case.

   4.  When a parser encounters an IODEF document with an extension it
       does not understand, this extension MUST be ignored (and not
       processed), but the remainder of the document MUST be processed.
       Parsers will be able to identify these extensions for which they
       have no processing logic through the namespace declaration.
       Parsers that encounter an unrecognized element in a namespace
       that they do support SHOULD reject the document as a syntax
       error.

   5.  Implementations SHOULD NOT download schemas at runtime due to the
       security implications, and extensions MUST NOT be required to
       provide a resolvable location of their schema.

   The following schema and XML document excerpt provide a template for
   an extension schema and its use in the IODEF document.

   This example schema defines a namespace of "iodef-extension1" and a
   single element named "newdata".

     <xs:schema
        targetNamespace="iodef-extension1.xsd"
        xmlns:iodef-extension1="iodef-extension1.xsd"
        xmlns:xs="http://www.w3.org/2001/XMLSchema">
        attributeFormDefault="unqualified"
        elementFormDefault="qualified">
      <xs:import
           namespace="urn:ietf:params:xml:ns:iodef-1.0"
           schemaLocation=" urn:ietf:params:xml:schema:iodef-1.0"/>

        <xs:element name="newdata" type="xs:string" />
     </xs:schema>

   The following XML excerpt demonstrates the use of the above schema as
   an extension to the IODEF.

Top      Up      ToC       Page 59 
      <IODEF-Document
           version="1.00" lang="en-US"
           xmlns="urn:ietf:params:xml:ns:iodef-1.0"
           xmlns:iodef=" urn:ietf:params:xml:ns:iodef-1.0"
           xmlns:iodef-extension1="iodef-extension1.xsd"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="iodef-extension1.xsd">
          <Incident purpose="reporting">
          ...
          <AdditionalData dtype="xml" meaning="xml">
            <iodef-extension1:newdata>
               Field that could not be represented elsewhere
            </iodef-extension1:newdata>
          </AdditionalData>
          </Incident>
      </IODEF-Document>

6.  Internationalization Issues

   Internationalization and localization is of specific concern to the
   IODEF, since it is only through collaboration, often across language
   barriers, that certain incidents be resolved.  The IODEF supports
   this goal by depending on XML constructs, and through explicit design
   choices in the data model.

   Since IODEF is implemented as an XML Schema, it implicitly supports
   all the different character encodings, such as UTF-8 and UTF-16,
   possible with XML.  Additionally, each IODEF document MUST specify
   the language in which their contents are encoded.  The language can
   be specified with the attribute "xml:lang" (per Section 2.12 of [1])
   in the top-level element (i.e., IODEF-Document@lang) and letting all
   other elements inherit that definition.  All IODEF classes with a
   free-form text definition (i.e., all those defined of type iodef:
   MLStringType) can also specify a language different from the rest of
   the document.  The valid language codes for the "xml:lang" attribute
   are described in RFC 4646 [7].

   The data model supports multiple translations of free-form text.  In
   the places where free-text is used for descriptive purposes, the
   given class always has a one-to-many cardinality to its parent (e.g.,
   Description class).  The intent is to allow the identical text to be
   encoded in different instances of the same class, but each being in a
   different language.  This approach allows an IODEF document author to
   send recipients speaking different languages an identical document.
   The IODEF parser SHOULD extract the appropriate language relevant to
   the recipient.

Top      Up      ToC       Page 60 
   While the intent of the data model is to provide internationalization
   and localization, the intent is not to do so at the detriment of
   interoperability.  While the IODEF does support different languages,
   the data model also relies heavily on standardized enumerated
   attributes that can crudely approximate the contents of the document.
   With this approach, a CSIRT should be able to make some sense of an
   IODEF document it receives even if the text based data elements are
   written in a language unfamiliar to the analyst.

7.  Examples

   This section provides examples of an incident encoded in the IODEF.
   These examples do not necessarily represent the only way to encode a
   particular incident.

7.1.  Worm

   An example of a CSIRT reporting an instance of the Code Red worm.

<?xml version="1.0" encoding="UTF-8"?>
<!-- This example demonstrates a report for a very
     old worm (Code Red) -->
<IODEF-Document version="1.00" lang="en"
  xmlns="urn:ietf:params:xml:ns:iodef-1.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
  <Incident purpose="reporting">
    <IncidentID name="csirt.example.com">189493</IncidentID>
    <ReportTime>2001-09-13T23:19:24+00:00</ReportTime>
    <Description>Host sending out Code Red probes</Description>
    <!-- An administrative privilege was attempted, but failed -->
    <Assessment>
      <Impact completion="failed" type="admin"/>
    </Assessment>
    <Contact role="creator" type="organization">
      <ContactName>Example.com CSIRT</ContactName>
      <RegistryHandle registry="arin">example-com</RegistryHandle>
      <Email>contact@csirt.example.com</Email>
    </Contact>
    <EventData>
      <Flow>
        <System category="source">
          <Node>
            <Address category="ipv4-addr">192.0.2.200</Address>
            <Counter type="event">57</Counter>
          </Node>
        </System>
        <System category="target">

Top      Up      ToC       Page 61 
          <Node>
            <Address category="ipv4-net">192.0.2.16/28</Address>
          </Node>
          <Service ip_protocol="6">
            <Port>80</Port>
          </Service>
        </System>
      </Flow>
      <Expectation action="block-host" />
      <!-- <RecordItem> has an excerpt from a log -->
      <Record>
        <RecordData>
          <DateTime>2001-09-13T18:11:21+02:00</DateTime>
          <Description>Web-server logs</Description>
          <RecordItem dtype="string">
          192.0.2.1 - - [13/Sep/2001:18:11:21 +0200] "GET /default.ida?
          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
          </RecordItem>
            <!-- Additional logs -->
          <RecordItem dtype="url">
             http://mylogs.example.com/logs/httpd_access</RecordItem>
        </RecordData>
      </Record>
    </EventData>
    <History>
      <!-- Contact was previously made with the source network owner -->
      <HistoryItem action="contact-source-site">
        <DateTime>2001-09-14T08:19:01+00:00</DateTime>
        <Description>Notification sent to
                     constituency-contact@192.0.2.200</Description>
      </HistoryItem>
    </History>
  </Incident>
</IODEF-Document>

7.2.  Reconnaissance

   An example of a CSIRT reporting a scanning activity.

   <?xml version="1.0" encoding="UTF-8" ?>
   <!-- This example describes reconnaissance activity: one-to-one and
        one-to-many scanning -->

Top      Up      ToC       Page 62 
   <IODEF-Document version="1.00" lang="en"
     xmlns="urn:ietf:params:xml:ns:iodef-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
     <Incident purpose="reporting">
       <IncidentID name="csirt.example.com">59334</IncidentID>
       <ReportTime>2006-08-02T05:54:02-05:00</ReportTime>
       <Assessment>
         <Impact type="recon" completion="succeeded" />
       </Assessment>
       <Method>
         <!-- Reference to the scanning tool "nmap" -->
         <Reference>
           <ReferenceName>nmap</ReferenceName>
           <URL>http://nmap.toolsite.example.com</URL>
         </Reference>
       </Method>
       <!-- Organizational contact and that for staff in that
            organization -->
       <Contact role="creator" type="organization">
         <ContactName>CSIRT for example.com</ContactName>
         <Email>contact@csirt.example.com</Email>
         <Telephone>+1 412 555 12345</Telephone>
         <!-- Since this <Contact> is nested, Joe Smith is part of the
             CSIRT for example.com -->
         <Contact role="tech" type="person" restriction="need-to-know">
           <ContactName>Joe Smith</ContactName>
           <Email>smith@csirt.example.com</Email>
         </Contact>
       </Contact>
       <EventData>
         <!-- Scanning activity as follows:
           192.0.2.1:60524 >> 192.0.2.3:137
                  192.0.2.1:60526 >> 192.0.2.3:138
                  192.0.2.1:60527 >> 192.0.2.3:139
                  192.0.2.1:60531 >> 192.0.2.3:445
         -->
         <Flow>
           <System category="source">
             <Node>
               <Address category="ipv4-addr">192.0.2.200</Address>
             </Node>
             <Service ip_protocol="6">
               <Portlist>60524,60526,60527,60531</Portlist>
             </Service>
           </System>
           <System category="target">
             <Node>

Top      Up      ToC       Page 63 
               <Address category="ipv4-addr">192.0.2.201</Address>
             </Node>
             <Service ip_protocol="6">
               <Portlist>137-139,445</Portlist>
             </Service>
           </System>
         </Flow>
         <!-- Scanning activity as follows:
               192.0.2.2 >> 192.0.2.3/28:445 -->
         <Flow>
           <System category="source">
             <Node>
               <Address category="ipv4-addr">192.0.2.240</Address>
             </Node>
           </System>
           <System category="target">
             <Node>
               <Address category="ipv4-net">192.0.2.64/28</Address>
             </Node>
             <Service ip_protocol="6">
               <Port>445</Port>
             </Service>
           </System>
         </Flow>
       </EventData>
     </Incident>
   </IODEF-Document>

7.3.  Bot-Net Reporting

   An example of a CSIRT reporting a bot-network.

 <?xml version="1.0" encoding="UTF-8" ?>
 <!-- This example describes a compromise and subsequent installation
      of bots -->
 <IODEF-Document version="1.00" lang="en"
   xmlns="urn:ietf:params:xml:ns:iodef-1.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
   <Incident purpose="mitigation">
     <IncidentID name="csirt.example.com">908711</IncidentID>
     <ReportTime>2006-06-08T05:44:53-05:00</ReportTime>
     <Description>Large bot-net</Description>
     <Assessment>
       <Impact type="dos" severity="high" completion="succeeded" />

Top      Up      ToC       Page 64 
     </Assessment>
     <Method>
       <!-- References a given piece of malware, "GT Bot" -->
       <Reference>
         <ReferenceName>GT Bot</ReferenceName>
       </Reference>
       <!-- References the vulnerability used to compromise the
            machines -->
       <Reference>
         <ReferenceName>CA-2003-22</ReferenceName>
         <URL>http://www.cert.org/advisories/CA-2003-22.html</URL>
         <Description>Root compromise via this IE vulnerability to
                      install the GT Bot</Description>
       </Reference>
     </Method>
     <!-- A member of the CSIRT that is coordinating this
          incident -->
     <Contact type="person" role="irt">
       <ContactName>Joe Smith</ContactName>
       <Email>jsmith@csirt.example.com</Email>
     </Contact>
     <EventData>
       <Description>These hosts are compromised and acting as bots
                    communicating with irc.example.com.</Description>
       <Flow>
         <!-- bot running on 192.0.2.1 and sending DoS traffic at
              10,000 bytes/second -->
         <System category="source">
           <Node>
             <Address category="ipv4-addr">192.0.2.1</Address>
           </Node>
           <Counter type="byte" duration="second">10000</Counter>
           <Description>bot</Description>
         </System>
         <!-- a second bot on 192.0.2.3 -->
         <System category="source">
           <Node>
             <Address category="ipv4-addr">192.0.2.3</Address>
           </Node>
           <Counter type="byte" duration="second">250000</Counter>
           <Description>bot</Description>
         </System>
         <!-- Command-and-control IRC server for these bots-->
         <System category="intermediate">
           <Node>
             <NodeName>irc.example.com</NodeName>
             <Address category="ipv4-addr">192.0.2.20</Address>
             <DateTime>2006-06-08T01:01:03-05:00</DateTime>

Top      Up      ToC       Page 65 
           </Node>
           <Description>IRC server on #give-me-cmd channel</Description>
         </System>
       </Flow>
       <!-- Request to take these machines offline -->
       <Expectation action="investigate">
         <Description>Confirm the source and take machines off-line and
                      remediate</Description>
       </Expectation>
     </EventData>
   </Incident>
 </IODEF-Document>

7.4.  Watch List

   An example of a CSIRT conveying a watch-list.

<?xml version="1.0" encoding="UTF-8" ?>
<!-- This example demonstrates a trivial IP watch-list -->
<!-- @formatid is set to "watch-list-043" to demonstrate how additional
     semantics about this document could be conveyed assuming both
     parties understood it-->
<IODEF-Document version="1.00" lang="en" formatid="watch-list-043"
  xmlns="urn:ietf:params:xml:ns:iodef-1.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
  <Incident purpose="reporting" restriction="private">
    <IncidentID name="csirt.example.com">908711</IncidentID>
    <ReportTime>2006-08-01T00:00:00-05:00</ReportTime>
    <Description>Watch-list of known bad IPs or networks</Description>
    <Assessment>
      <Impact type="admin" completion="succeeded" />
      <Impact type="recon" completion="succeeded" />
    </Assessment>
    <Contact type="organization" role="creator">
      <ContactName>CSIRT for example.com</ContactName>
      <Email>contact@csirt.example.com</Email>
    </Contact>
    <!-- Separate <EventData> used to convey different <Expectation> -->
    <EventData>
      <Flow>
        <System category="source">
          <Node>
            <Address category="ipv4-addr">192.0.2.53</Address>
          </Node>

Top      Up      ToC       Page 66 
          <Description>Source of numerous attacks</Description>
        </System>
      </Flow>
      <!-- Expectation class indicating that sender of list would like
           to be notified if activity from the host is seen -->
      <Expectation action="contact-sender" />
    </EventData>
    <EventData>
      <Flow>
        <System category="source">
          <Node>
            <Address category="ipv4-net">192.0.2.16/28</Address>
          </Node>
          <Description>
            Source of heavy scanning over past 1-month
          </Description>
        </System>
      </Flow>
      <Flow>
        <System category="source">
          <Node>
            <Address category="ipv4-addr">192.0.2.241</Address>
          </Node>
          <Description>C2 IRC server</Description>
        </System>
      </Flow>
      <!-- Expectation class recommends that these networks
           be filtered -->
      <Expectation action="block-host" />
    </EventData>
  </Incident>
</IODEF-Document>



(page 66 continued on part 4)

Next RFC Part