RFC 5070
The Incident Object Description Exchange Format
3.16. Node Class
The Node class names a system (e.g., PC, router) or network. This class was derived from the IDMEF [17].
+---------------+ | 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).
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.
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
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.
+---------------------+ | 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
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:
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.
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.
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.
+------------------+ | 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.
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.
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:
<?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 "&", "<", ">", """, and "'" 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].
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.
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-".
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.
<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.
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">
<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 -->
<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>
<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" />
</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>
</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>
<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)
