Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5070

The Incident Object Description Exchange Format

Pages: 92
Obsoleted by:  7970
Updated by:  6685
Part 3 of 4 – Pages 42 to 66
First   Prev   Next

ToP   noToC   RFC5070 - Page 42   prevText

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