Internet DRAFT - draft-cejkat-mile-iodef-and-idea
draft-cejkat-mile-iodef-and-idea
MILE T. Cejka
Internet-Draft P. Kacha
Intended status: Informational CESNET
Expires: May 4, 2016 November 1, 2015
MILE Differences between IODEF and IDEA
draft-cejkat-mile-iodef-and-idea-00
Abstract
This document summarizes differences between IODEF and IDEA data
formats for description of computer security incidents.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Cejka & Kacha Expires May 4, 2016 [Page 1]
Internet-Draft IODEF and IDEA November 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. IODEF . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. IDEA . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Example Reports Represented in IODEF and IDEA . . . . . . . . 3
2.1. Minimal Example in IODEF . . . . . . . . . . . . . . . . 4
2.2. Minimal Example in IDEA . . . . . . . . . . . . . . . . . 4
2.3. Worm Example in IODEF . . . . . . . . . . . . . . . . . . 4
2.4. Worm Example in IDEA . . . . . . . . . . . . . . . . . . 6
2.5. Reconnaissance Example in IODEF . . . . . . . . . . . . . 7
2.6. Reconnaissance Example in IDEA . . . . . . . . . . . . . 9
2.7. Bot-Net Reporting Example in IODEF . . . . . . . . . . . 12
2.8. Bot-Net Reporting Example in IDEA . . . . . . . . . . . . 13
2.9. Watch List Reporting Example in IODEF . . . . . . . . . . 15
2.10. Watch List Reporting Example in IDEA . . . . . . . . . . 16
3. What is missing in IDMEF and IODEF . . . . . . . . . . . . . 18
4. Real World . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. From XML to JSON . . . . . . . . . . . . . . . . . . . . . . 20
6. General observations . . . . . . . . . . . . . . . . . . . . 20
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11. Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
This document is a collection of examples of security incidents
represented in Incident Object Description Exchange Format (IODEF) v2
[RFC5070-bis] and Intrusion Detection Extensible Alert (IDEA) [IDEA]
data formats. IODEF uses XML technology meanwhile IDEA is listed as
a possible data representation that uses JSON.
This activity comes from an idea of JSON usage for representation of
IODEF documents. IDEA is a data format for representation of network
security incidents detected by Intrusion Detection Systems (IDS),
honeypots etc. Since IDEA uses JSON, it can be a possible way for
JSON-based IODEF. However, the motivation of this document is to
show different approaches of representation of similar information.
Examples that are listed in this document were taken from RFC5070-bis
and coverted into IDEA. The analysis of IODEF and IDEA discovered
that the data format is not the only difference between IODEF and
IDEA.
Cejka & Kacha Expires May 4, 2016 [Page 2]
Internet-Draft IODEF and IDEA November 2015
The following sections briefly introduces IODEF and IDEA. The rest
of the document contains examples in IODEF and IDEA with comments.
1.1. IODEF
IODEF is a human readable and processable data representation for
sharing information cmmonly exchanged by Computer Security Incident
Response Teams (CSIRTs). IODEF is defined in RFC5070 and by the time
of writing this document, new version IODEF v2 is developed by draft-
ietf-mile-rfc5070-bis.
Existing implementations of IODEF are listed in draft-moriarty-mile-
implementreport.
IODEF v2 updates information model of IODEF, however, XML remains as
the only one supported data format.
1.2. IDEA
IDEA stands for Intrusion Detection Extensible Alert. Even though
there exists a variety of models for communication between honeypots,
agents, detection probes, none of them is really used because of
various limitations for general usage. It is an attempt to define
nowadays requirements and propose foundations for viable solution for
security event model, taking into consideration existing formats,
their benefits and drawbacks.
IDEA is designed for storage and automatic processing of incident
reports/alerts. Since IDEA is based on JSON, it can be used and
processed by several available tools. IDEA is developed and used for
sharing information about technical aspects of incidents between
CSIRTs. It is currently used in Czech National Research and
Educational Network (NREN) http://www.ces.net.
IDEA messages can be created by detection systems, stored in NoSQL
databases and automaticaly processed / data mined for reputation
modelling and blacklisting. In comparison to IODEF, IDEA is more
strict and tries not to allow multiple ways of incident
representation. This kind of explicitness allows machine processing.
On the other hand, IDEA describes only a subset of IODEF because it
does not need to contain various information that are only
informational for human reading.
2. Example Reports Represented in IODEF and IDEA
Cejka & Kacha Expires May 4, 2016 [Page 3]
Internet-Draft IODEF and IDEA November 2015
2.1. Minimal Example in IODEF
<?xml version="1.0" encoding="UTF-8"?>
<!-- Minimum IODEF document -->
<IODEF-Document version="2.00" xml:lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://www.iana.org/assignments/xmlregistry/schema/
iodef-2.0.xsd">
<Incident purpose="reporting" restriction="private">
<IncidentID name="csirt.example.com">492382</IncidentID>
<GenerationTime>2015-07-18T09:00:00-05:00</GenerationTime>
<Contact type="organization" role="creator">
<Email>contact@csirt.example.com</Email>
</Contact>
<!-- Add more fields to make the document useful -->
</Incident>
</IODEF-Document>
2.2. Minimal Example in IDEA
This example shows minimal set of keys that must contain an IDEA
message.
{
"Format": "IDEA0",
"ID": "bc2a3696-a1d2-49cc-9644-34da932085a8",
"Category": [
"Test"
],
"DetectTime": "2001-09-13T18:11:21+02:00"
}
2.3. Worm Example in IODEF
<?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
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="2.00" lang="en" formatid="watch-list-043"
xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
<Incident purpose="reporting" restriction="private">
<IncidentID name="csirt.example.com">908711</IncidentID>
Cejka & Kacha Expires May 4, 2016 [Page 4]
Internet-Draft IODEF and IDEA November 2015
<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> is 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 -->
Cejka & Kacha Expires May 4, 2016 [Page 5]
Internet-Draft IODEF and IDEA November 2015
<Expectation action="block-host"/>
</EventData>
</Incident>
</IODEF-Document>
2.4. Worm Example in IDEA
IDEA can add "Imprecise" into Target to express that not every IP
address from the given range was influenced.
{
"Format": "IDEA0",
"ID": "bc2a3696-a1d2-49cc-9644-34da932085a8",
"Category": [
"Attempt.Login"
],
"AltNames": [
"csirt.example.com-189493"
],
"DetectTime": "2001-09-13T18:11:21+02:00",
"CreateTime": "2001-09-13T23:19:24+00:00",
"Description": "Host sending out Code Red probes",
"ConnectionCount": 57,
"Source": [
{
"IP4": [
"192.0.2.200"
],
"Proto": [
"tcp"
],
"Note": "We recommend to block the host"
}
],
"Target": [
{
"IP4": [
"192.0.2.16/28"
],
"Proto": [
"tcp"
],
"Port": [
80
],
"Imprecise": true
}
],
Cejka & Kacha Expires May 4, 2016 [Page 6]
Internet-Draft IODEF and IDEA November 2015
"Attach": [
{
"Note": "Web-server logs",
"Content": "192.0.2.1 - - [13/Sep/2001:18:11:21 +0200]
\"GET/default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\"",
"Ref": [
"http://mylogs.example.com/logs/httpd_access"
]
}
],
"Node": [
{
"Name": "com.example.csirt.logdetector",
"Ref": [
"urn:arin:example-com",
"urn:mailto:contact@csirt.example.com"
],
"Note": "Example.com CSIRT log detector"
}
]
}
2.5. Reconnaissance Example in IODEF
<?xml version="1.0" encoding="UTF-8"?>
<!-- This example describes reconnaissance activity:
one-to-one and one-to-many scanning -->
<IODEF-Document
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="2.00" lang="en"
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">
Cejka & Kacha Expires May 4, 2016 [Page 7]
Internet-Draft IODEF and IDEA November 2015
<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>
Cejka & Kacha Expires May 4, 2016 [Page 8]
Internet-Draft IODEF and IDEA November 2015
</Service>
</System>
</Flow>
</EventData>
</Incident>
</IODEF-Document>
2.6. Reconnaissance Example in IDEA
IDEA message has "Category" that defines a type of incident that is
described. In comparison to IODEF, success of event/incident is
implicitly known according to Category, whereas IODEF needs a
"completion" attribute.
Note that IDEA event can represent just ONE event (corresponding to
Flow concept in IODEF). Therefore, this example can be represented
by two events. Related events can reference each other in "RelID".
{
"Format": "IDEA0",
"ID": "5E1BE2FE-7322-11E5-9498-975EA0D99A02",
"RelID": "0833E4BE-7326-11E5-AE5A-975EA0D99A02",
"AltNames": [
"csirt.example.com-59344"
],
"CreateTime": "2006-08-02T05:54:02-05:00",
"DetectTime": "2006-08-02T05:54:02-05:00",
"Category": [
"Recon.Scanning"
],
"Source": [
{
"IP4": [
"192.0.2.200"
],
"Proto": [
"tcp"
],
"Port": [
60524,
60526,
60527,
60531
]
}
],
"Target": [
{
Cejka & Kacha Expires May 4, 2016 [Page 9]
Internet-Draft IODEF and IDEA November 2015
"IP4": [
"192.0.2.201"
],
"Proto": [
"tcp"
],
"Port": [
137,
138,
139,
445
]
}
],
"Node": [
{
"Name": "com.example.csirt.scandetector",
"Ref": [
"urn:mailto:contact@csirt.example.com",
"urn:tel:+1 412 555 12345"
],
"Note": "Example.com CSIRT scan detector"
}
]
}
Cejka & Kacha Expires May 4, 2016 [Page 10]
Internet-Draft IODEF and IDEA November 2015
{
"Format": "IDEA0",
"ID": "0833E4BE-7326-11E5-AE5A-975EA0D99A02",
"RelID": "5E1BE2FE-7322-11E5-9498-975EA0D99A02",
"AltNames": [
"csirt.example.com-59344"
],
"EventTime": "2006-08-02T05:54:02-05:00",
"DetectTime": "2006-08-02T05:54:02-05:00",
"Category": [
"Recon.Scanning"
],
"Source": [
{
"IP4": [
"192.0.2.240"
],
"Proto": [
"tcp"
]
}
],
"Target": [
{
"IP4": [
"192.0.2.64/28"
],
"Proto": [
"tcp"
],
"Port": [
445
]
}
],
"Node": [
{
"Name": "com.example.csirt.scandetector",
"Ref": [
"urn:mailto:contact@csirt.example.com",
"urn:tel:+1 412 555 12345"
],
"Note": "Example.com CSIRT scan detector"
}
]
}
Cejka & Kacha Expires May 4, 2016 [Page 11]
Internet-Draft IODEF and IDEA November 2015
2.7. Bot-Net Reporting Example in IODEF
<?xml version="1.0" encoding="UTF-8"?>
<!-- This example describes a compromise and subsequent
installation of bots -->
<IODEF-Document
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="2.00" lang="en"
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>
Cejka & Kacha Expires May 4, 2016 [Page 12]
Internet-Draft IODEF and IDEA November 2015
<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>
2.8. Bot-Net Reporting Example in IDEA
IDEA has the notion of toplevel ByteCount, FlowCount, PacketCount,
ConnCount, however some nodes have already added Source/Targed
specific counters, and we will incorporate them.
Incident in IDEA must be represented in exact time frames
(WinStartTime, WinEndTime). Counters are related to the time frame.
IDEA keeps notion of the "Source" and the "Target" of the problem.
Source and Target do not try to describe semantics of network flows.
This approach marks every Source as an evil participant of an
incident and it allows to easily recognize attackers and victims.
{
Cejka & Kacha Expires May 4, 2016 [Page 13]
Internet-Draft IODEF and IDEA November 2015
"Format": "IDEA0",
"ID": "78335B50-7344-11E5-BD6F-5B49358CC448",
"Category": [
"Availability.DDOS",
"Intrusion.Botnet"
],
"AltNames": [
"csirt.example.com-908711"
],
"EventTime": "2006-06-08T01:01:03-05:00",
"WinStartTime": "2006-06-08T01:01:02-05:00",
"WinEndTime": "2006-06-08T01:01:03-05:00",
"CreateTime": "2006-06-08T05:44:53-05:00",
"DetectTime": "2006-06-08T05:44:53-05:00",
"Description": "Large bot-net",
"ByteCount": 260000,
"Ref": [
"urn:clamav:GT%20Bot",
"urn:certcc:CA-2003-22",
"http://www.cert.org/advisories/CA-2003-22.html"
],
"Note": "Root compromise via IE vulnerability to install
the GT Bot",
"Source": [
{
"Type": [
"Botnet"
],
"IP4": [
"192.0.2.1"
],
"ByteCount": 10000,
"Note": "Host is compromised and acting as bot
communicating with irc.example.com."
},
{
"Type": [
"Botnet"
],
"IP4": [
"192.0.2.3"
],
"ByteCount": 250000,
"Note": "Host is compromised and acting as bot
communicating with irc.example.com."
},
{
"Type": [
Cejka & Kacha Expires May 4, 2016 [Page 14]
Internet-Draft IODEF and IDEA November 2015
"CC"
],
"IP4": [
"192.0.2.20"
],
"Proto": [
"tcp",
"irc"
],
"Note": "IRC server on #give-me-cmd channel"
}
],
"Node": [
{
"Name": "com.example.csirt.logdetector",
"Ref": [
"urn:arin:example-com",
"urn:mailto:contact@csirt.example.com"
],
"Note": "Example.com CSIRT log detector"
}
]
}
2.9. Watch List Reporting Example in IODEF
<?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
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="2.00" lang="en" formatid="watch-list-043"
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>
Cejka & Kacha Expires May 4, 2016 [Page 15]
Internet-Draft IODEF and IDEA November 2015
<Email>contact@csirt.example.com</Email>
</Contact>
<!-- Separate <EventData> is 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>
2.10. Watch List Reporting Example in IDEA
Idea has no notion of expected action or reply. However, this
example shows specific two-parties agreed on format, as indicated by
Cejka & Kacha Expires May 4, 2016 [Page 16]
Internet-Draft IODEF and IDEA November 2015
"watch-list-043", which can be represented in freely added and
negotiated key. "FormatID" is used as an example here.
If both parties agree to act on specific IDEA messages, they can also
agree on new keys to indicate/require this, here "Expected" key on
the event level and on the Source level is used as an example.
{
"Format": "IDEA0",
"ID": "3411C0F2-734D-11E5-A71C-5B49358CC448",
"FormatID": "watch-list-043",
"AltNames": [
"csirt.example.com-908711"
],
"Category": [
"Recon",
"Intrusion.AdminCompromise"
],
"CreateTime": "2006-08-01T00:00:00-05:00",
"DetectTime": "2006-08-01T00:00:00-05:00",
"Note": "Watch-list of known bad IPs or networks",
"Expected": "Block",
"Source": [
{
"IP4": [
"192.0.2.53"
],
"Note": "Source of numerous attacks",
"Expected": "Notify"
},
{
"IP4": [
"192.0.2.16/28"
],
"Note": "Source of heavy scanning over past 1-month"
},
{
"Type": [
"CC"
],
"IP4": [
"192.0.2.241"
],
"Note": "C2 IRC server"
}
],
"Node": [
{
Cejka & Kacha Expires May 4, 2016 [Page 17]
Internet-Draft IODEF and IDEA November 2015
"Name": "com.example.csirt.logdetector",
"Ref": [
"urn:arin:example-com",
"urn:mailto:contact@csirt.example.com"
],
"Note": "Example.com CSIRT log detector"
}
]
}
3. What is missing in IDMEF and IODEF
Creation of messages in almost any format is easy. However, most
formats are hard to process, query and analyze. As RFC5070 says:
"IODEF is a format for representing computer security information
commonly exchanged between Computer Security Incident Response Teams
(CSIRTs)." That means it does too much of what we need for automated
incident exchange (detectors/SIEMs have no use for the whole incident
solving lifecycle and organisations involved). However, the subset
of information was recognized as usable for data representation. It
is very similar in concepts to IDMEF, so mostly the same applies.
IODEF has only limited means for extension (ext-type, ext-value,
AdditionalData), and extension is only on strictly specified places,
or by RFC update, or own nonstandard schema. However attacks evolve
and there can be the need to incorporate the new (yet unknown)
information in the future. For information, which cannot be
represented in IODEF, there is a possibility to incorporate another
format (IDMEF, IDEA, Taxii/Styx, OpenIOC). That however subverts use
of the one standard format (recipients might not know how to deal
with embedded message, or would have to implement all of the existing
standards).
IODEF is very free in various fields representation (e.g.
Assessment). Both types and semantics are dependent on attributes:
category of Address, type of Assessment or Impact. That is very
unfriendly for internal representation and processing. The more
conversions needed (into internal format, db storage, etc.), the less
efficient is the data representation for usage. Various pieces of
the same information on different places (and depths of the
structure) make it hard to index/search.
According to RFC5070: "These examples do not necessarily represent
the only way to encode a particular incident." Various ways to
encode one incident complicate its further processing and comparison,
correllation or merging with other similar incidents. Machine would
have to know all possible variations/representations.
Cejka & Kacha Expires May 4, 2016 [Page 18]
Internet-Draft IODEF and IDEA November 2015
Recursive representation of information is allowed for Contact or
EvenData (Contact/Contact/Contact..., EventData/EventData/Event/Data.
Although it is a better representation of real world relations, it
complicates processing and internal representation. In addition,
IODEF structure is a tree, however, a graph would be more suitable in
real world (example in the following section).
4. Real World
If the aim is to describe the real world relations, tree is not
enough (possibly digraph may do). The following example shows
information duplication/incoherence, where one technical contact is
responsible for more company subsidiaries:
<Contact role="creator", type="organization">
<ContactName>Example Mother Company</ContactName>
<Contact role="tech", type="person">
<ContactName>**John Doe**</ContactName>
</Contact>
</Contact>
<Contact role="reporter", type="organization">
<ContactName>Example Subsidiary Company</ContactName>
<Contact role="tech", type="person">
<ContactName>**John Doe**</ContactName>
</Contact>
</Contact>
Not every event can be described by means of Flow/System hierarchy.
For example a phishing URL and related information (source MTA),
extracted from spam message. Does the Flow mean the transfer of the
message from the source MTA to the destination? Should be the
extracted URL represented within the Flow or within one of two System
instances? Or in Observable? How to refer it from Flow?
(ObservableReference is usable only within Indicator scope.)
Another real-world example is related to a trojan on the web page.
User clicks, downloads the page, JavaScript exploits user's
webbrowser, user machine gets compromised. Does it mean that Flow
goes from the user to the webpage (it has been definitely initiated
by user), or the other way around? Is it direction of the attack, or
description of technical means? Where does the URL and trojan info
belong? A data representation should describe an incident clearly in
one way.
Cejka & Kacha Expires May 4, 2016 [Page 19]
Internet-Draft IODEF and IDEA November 2015
5. From XML to JSON
Each JSON key may have one and only one value. General methods of
mapping of XML attributes or nested tags to JSON are possible,
however, they are usually hairy and nonelegant.
Consider the following XML sample:
<Counter type="average" unit="byte">123</Counter>
JSON1: Goes against JSON paradigms: orthogonal hierarchy, info
encoded in keys.
"Counter": 123
"Counter.type": "average"
"Counter.unit": "byte"
JSON2: Each and every attribute has to be nested object because of
extensibility.
"Counter": {
"value": 123
"type": "average"
"unit": "byte"
}
JSON3: Simple, jsonic, however every combination neads unique name.
"AvgBytesCounter": 123
If a designed JSON has deterministic, typed and expectable structure,
it can be readily imported into existing tools (document stores such
as MongoDB, PostgreSQL), indexed, queried, analyzed. It would be
very usage friendly to leverage this possibility.
6. General observations
No known format allows for timed/marked modifications (e.g. one party
generates the event, the second party does the enrichment with
PassiveDNS, the third party with Whois information and finally,
receiver has no opportunity to find out who and when modified the
event report. That is important, because of issue of trust, and
because of time differences (some information like DNS change in
time, so information added later, may be out of date). Another issue
is related to weak notion of trust (authentication, signing). It can
be done by means of signed differences (such as JSON Patch).
Cejka & Kacha Expires May 4, 2016 [Page 20]
Internet-Draft IODEF and IDEA November 2015
7. Conclusion
JSON version of the format should be built from the grounds up and
take into consideration JSON specifics. Straightforward XML to JSON
translation would lead to cumbersome result.
One possible approach might be a representation of all simple objects
in a reasonably flat structure ("information for machine"), and to
map the real world relations by references ("information for
humans"). In our oppinion, IDEA is close to the EventData class of a
IODEF schema. It might be a good idea to start with event/attack
description format (IDEA or IDMEF based) at first and to add security
team aimed information (IODEF based) later.
8. Acknowledgements
For review and advices, the authors thank to:
Takeshi Takahashi, National Institute of Information and
Communications Technology Network Security Research Institute
Vaclav Bartos, CESNET
9. IANA Considerations
This memo includes no request to IANA.
10. Security Considerations
There are no security considerations added in this draft because of
the nature of the document.
11. Informative References
[IDEA] CESNET, a.l.e., "Intrusion Detection Extensible Alert",
<https://csirt.cesnet.cz/en/idea>.
[RFC5070-bis]
Danyliw, R. and P. Stoecker, "The Incident Object
Description Exchange Format v2", 2015,
<https://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-
14>.
Authors' Addresses
Cejka & Kacha Expires May 4, 2016 [Page 21]
Internet-Draft IODEF and IDEA November 2015
Tomas Cejka
CESNET, a.l.e.
Zikova 4
Prague, CZ 16000
CZ
Email: cejkat@cesnet.cz
Pavel Kacha
CESNET, a.l.e.
Zikova 4
Prague, CZ 16000
CZ
Email: ph@cesnet.cz
Cejka & Kacha Expires May 4, 2016 [Page 22]
