How to use IODEF¶
Introduction¶
This tutorial won't be considering the implementation of IODEF, but rather the content of the format and what it means to use it.
As there is still no library to use yourself to implement IODEF, this is only focused on helping you understand what is essential in IODEF and how it was constructed.
IODEF, is built upon IDMEF, which has its own tutorial on this wiki.
This means that, just like IDMEF, IODEF is thought to be encoded in XML. However, you can choose to encode your IODEF messages with the protocol thats suits you best, as this shoudn't have a great impact on the schema. Note that most implementations of IODEF are using XML though.
Finally, you may know that a new version of IODEF is under development. This new version, work of the group MILE, won't be mentioned in this tutorial, in which we will focus on the first version, described in this RFC.
IODEF's sections¶
IODEF can be split in 6 parts :- The Incident section
- The Contact section
- The Method section
- The Assessment section
- The EventData section
- The History section
Each section contains several classes and will be described underneath.
The Incident section¶
The Incident section is meant to described rapidly the incident. It contains information about the sender and the reason lying under the creation of the message.
It isn't a big section, but is very important.
The Contact section¶
The Contact section is meant to offer one or many points of contact regarding the incident described in the message.
The Method section¶
The Method section contains information about the methodology used by the intrude to perpetrate the attack.
The Assessment section¶
The Assessment section is meant to express assessments on the impact of the incident, being monetary, temporal or even on the compagny image.
The EventData section¶
This section is where the events that triggered the incident can be decribed. It is where you can find a link between IODEF and IDMEF.
The History section¶
This section is meant to describe the way the incident was handled.
IODEF & IDMEF¶
IODEF is based on IDMEF. For this reason, you can find lots of fields of an IDMEF alert in IODEF's schema.
First, let's have a look on what you can describe using IODEF.
IODEF is contructed to be a mean to describe security incidents. An incident can be the result of many single attacks, which can be made of many single events.
These all can be describe using IODEF.
An incident, in IODEF vocabulary, is called an incident, which isn't really complicated.
Each incident is made of events, which are described using the class EventData.
But an event can actually be constituted of many events, that's why the EventData class contains an EventData.
You can then build your own hierarchy and add up to as many levels as you want.
You can directly add the corresponding IDMEF alert or other logs concerning the event using the section Record. But you can also describe the alert directly in IODEF.
If an EventData represents an IDMEF alert, it is however structured very differently.
Each host of the alert (target or source) is a "System". For each you can fill the classes Node, Service and Operating System. This information differs slightly from the one given in an IDMEF alert, but it reduces the number of classes needed to describe the alert. Sources and targets can be grouped under a Flow.
Note that there is no mention of the analyzer in IODEF whereas it is quite important in IDMEF. You can however add it when attaching alerts using the Record section in the class application.
What is really necessary ?¶
IODEF is made of a lot of classes (47 to be precise) and you may wonder which of them are really necessary.
First of all, IODEF messages are meant to describe an incident. The incident section is thus really significant. Don't forget to fill in the decription of the incident as it will serve as a title or a way to find it easier than using the incidentid.
You may also want to be in touch with concerned people, so the contact section should be filled when possible.
As for EventData, History and Assessment section, you can fill them how you want. Let's just remember that more information there is, better will the incident be understood.
As for Assessment, most incident description focus on this part, so you may want to have it filled.
IODEF particularities¶
Some particular points should be discussed about IODEF.
First the workaround for static enumerations.
An issue that was raised with IDMEF found a solution in IODEF. The problem was that enumerations are static and that isn't really compatible with the speed at which cyber security evolves. To avoid having too static enumerations, IODEF allows to use your own values, even when dealing with an enumeration field.
To enter your own value, select ext-avlue in the enumeration and fill the field ext-value in the same class.
Shared classes is also a distinguishing feature of IODEF as there are many of them.
Instead of only having an additional data class linked to the alert, you ave one additional data class linked to every significant section of the message. The same goes for Description and Counter.
This allows more precision in describing the incident but can also be tricky because the same class shouldn't be filled the same way each time, and because it is much more easier to forget the existence of one link and thus forget to fill one class.
Finally, some classes may seem not to contain any information since they don't have attributes. This is due to the RFC considering that IODEF messages are encoded in XML. Thus some classes are actually strings and can be used to write free text.
Examples¶
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>
Reconnaisance¶
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>
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>
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>