MILE Working Group M. Suzuki
Internet-Draft NICT
Intended status: Informational P. Kampanakis
Expires: October 6, 2016 Cisco Systems
April 4, 2016
IODEF Usage Guidance
draft-ietf-mile-iodef-guidance-05
Abstract
The Incident Object Description Exchange Format [RFC5070] defines a
data representation that provides a framework for sharing information
commonly exchanged by Computer Security Incident Response Teams
(CSIRTs) about computer security incidents. Since the IODEF model
includes a wealth of available options that can be used to describe a
security incident or issue, it can be challenging for implementers to
develop tools that can Leverage IODEF for incident sharing. This
document provides guidelines for IODEF implementers. It will also
address how common security indicators can be represented in IODEF
and use-cases of how IODEF is being used so far. The goal of this
document is to make IODEF's adoption by vendors easier and encourage
faster and wider adoption of the model by Computer Security Incident
Response Teams (CSIRTs) around the world.
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 October 6, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
Suzuki & Kampanakis Expires October 6, 2016 [Page 1]
Internet-Draft IODEF Guidance April 2016
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Implementation Strategy . . . . . . . . . . . . . . . . . . . 3
3.1. Minimal IODEF document . . . . . . . . . . . . . . . . . 4
3.2. Decide what IODEF will be used for . . . . . . . . . . . 4
4. IODEF considerations and how to address them . . . . . . . . 5
4.1. External References . . . . . . . . . . . . . . . . . . . 5
4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Predicate logic . . . . . . . . . . . . . . . . . . . . . 5
4.4. Predicate Logic for watchlist of indicators . . . . . . . 6
4.5. Indicator identifiers . . . . . . . . . . . . . . . . . . 8
4.6. Disclosure level of IODEF . . . . . . . . . . . . . . . . 9
5. Current uses of IODEF . . . . . . . . . . . . . . . . . . . . 9
5.1. Inter-vendor and Service Provider Exercise . . . . . . . 9
5.2. Implementations . . . . . . . . . . . . . . . . . . . . . 13
5.3. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Inter-vendor and Service Provider Exercise Examples 16
A.1. Malware . . . . . . . . . . . . . . . . . . . . . . . . . 16
A.2. Malware Delivery URL . . . . . . . . . . . . . . . . . . 22
A.3. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . 22
A.4. Spear-Phishing . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction
The Incident Object Description Exchange Format in [RFC5070] defines
a data representation that provides a framework for sharing
information commonly exchanged by Computer Security Incident Response
Teams (CSIRTs) about computer security incidents. The IODEF data
Suzuki & Kampanakis Expires October 6, 2016 [Page 2]
Internet-Draft IODEF Guidance April 2016
model consists of multiple classes and data types that are used in
the IODEF XML schema.
The IODEF schema was designed to be able to describe all the possible
fields that would be needed in a security incident exchange. Thus,
IODEF contains plenty data constructs that could potentially make it
harder for IODEF implementers to decide which are the most important
ones. Additionally, in the IODEF schema, there exist multiple fields
and classes which do not necessarily need to be used in every
possible data exchange. Moreover, there are fields that are useful
only in data exchanges of non-traditional security events. This
document tries to address the issues above. It will also address how
common security indicators can be represented in IODEF. It will
point out the most important IODEF classes for an implementer and
describe other ones that are not as important. Also, it addresses
some common challenges for IODEF implementers and how they should be
addressed. The end goal of this document is to make IODEF's adoption
by vendors easier and encourage faster and wider adoption of the
model by Computer Security Incident Response Teams (CSIRTs) around
the world.
Section 3 discusses the recommended classes and how an IODEF
implementer should chose the classes to implement. Section 4
presents common considerations and implementer will come across and
how to address them. Section 5 goes over some basic security
concepts and how they can be expressed in IODEF.
2. Terminology
The terminology used in this document follows the one defined in
[RFC5070] and [RFC7203].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Implementation Strategy
It is important for IODEF implementers to be able to distinguish how
the IODEF classes will be used for incident information exchanges.
It is critical for an implementer to follow a strategy according to
which of the various IODEF classes he will choose to implement. It
is also important to know the most common classes that will be used
to describe common security incident or indicators. Thus, this
section will describe the most important classes and factors an IODEF
implementer should take into consideration before designing the
implementation or tool.
Suzuki & Kampanakis Expires October 6, 2016 [Page 3]
Internet-Draft IODEF Guidance April 2016
3.1. Minimal IODEF document
This section describes the minimal IODEF document that only equips
mandatory-to-implement classes. An IODEF document must have an
IODEF-Document class, which needs to have at least one Incident
class. Here is the structure of the minimal-style Incident class.
+-------------------------+
| Incident |
+-------------------------+
| ENUM purpose |<>----------[ IncidentID ]
| |<>----------[ GenerationTime ]
| |<>--{1..*}--[ Contact ]
+-------------------------+
Minimal-style Incident class
This minimal Incident class needs to have the purpose attribute and
the IncidentID, GenerationTime, and Contact elements. Contact class
requires type and role attributes, but no elements are required by
this specification. Nevertheless, at least one of the elements, such
as Email class, need to be implemented so that the IODEF document can
be workable.
Please see Section 7.1 of [I-D.ietf-mile-rfc5070-bis] for example
XMLs.
3.2. Decide what IODEF will be used for
This section describes that there is no need to implement all fields
of IODEF, the ones that are necessary for your use-cases. The
implementer should look into the schema and decide classes to
implement (or not). Here shows some use cases and nessesary classes.
If the implementer tackles against DDoS, Flow class and its included
information are the most important ones. The Flow class contains
information of related the attacker hosts and victim hosts. These
information may help automated filtering or sink-hole operations.
Another case is filtering malware c2 traffic. If modern malware
infect some device, it commonly connect to c2 (command and control)
server, and receive command from attackers. In such a case,
filtering traffic to c2 server is important to interupt malware's
activity. Both the Flow class and the URL class of IODEF can
indicate the URL of c2 server.
Also other external schema can be used to describe incidents or
indicators, as noted in the next section.
Suzuki & Kampanakis Expires October 6, 2016 [Page 4]
Internet-Draft IODEF Guidance April 2016
4. IODEF considerations and how to address them
4.1. External References
The IODEF format has the Reference class that refers to external
information such as a vulnerability, Intrusion Detection System (IDS)
alert, malware sample, advisory, or attack technique. However, due
to insufficiency of the capability of the Reference class itself to
describe external enumeration specifications, the Enumeretion
Reference Format needs to be used with. The Enumeration Reference
Format[RFC7495] specifies a format to include enumeration values from
external data representations into IODEF, and manages references to
external representations using IANA registry.
4.2. Extensions
The IODEF data model ([RFC5070]) is extensible. Many class
attributes and their values can be extended using using the "ext-*"
prefix. Additional classed can also be defined by using the
AdditionalData and RecordItem classes. An extension to the
AdditionalData class for reporting Phishing emails is defined in
[RFC5901].
Additionally, IODEF can import existing schemata by using an
extension framework defined in [RFC7203]. The framework enables
IODEF users to embed XML data inside an IODEF document using external
schemata or structures defined by external specifications. Examples
include CVE, CVRF and OVAL. Thus, [RFC7203] enhances the IODEF
capabilities without further extending the data model.
IODEF implementers should consider using their own IODEF extensions
only for data that cannot be described using existing standards or
importing them in and IODEF document using [RFC7203] is not a
suitable option.
4.3. Predicate logic
IODEF [I-D.ietf-mile-rfc5070-bis] allows for nesting of incident
information. For example, a EventData Class could include multiple
Flows or Records. In turn, a Flow could consist of many Nodes and a
Record of many RecordData classes. To ensure consistency, IODEF
presumes certain predicate logic.
An EventData class that contains multiple EventData classes depicts
an Event that consists of smaller events. For the parent event to
take place, all the children EventData events SHOULD take place. An
EventData class with multiple Flows means that all the information
Suzuki & Kampanakis Expires October 6, 2016 [Page 5]
Internet-Draft IODEF Guidance April 2016
defined in the flows need to exist for the event described to take
place.
For Records, the Records in an event just add more context to the
event, they do not all need to be present for the event to take
place. A Record in an EventData class with three RecordData in it,
means that either of these RecordData classes needs to be present for
the event described to take place.
In [RFC5070], if a Flow Class contained two System classes that have
"source" and "target" as the category attributes, both Systems SHOULD
be present in order for the Flow to be true and thus marked as an
event. There SHOULD NOT be more than one "source" or "watchlist-
source" and one "target" or "watchlist-target" Systems per Flow.
In Node class, Node information grouped together under a System class
depicts different representations of the same System. For example,
if a System consists of different Nodes with an IPv4 address, a
domain-name and an IPv6 address, they all represent the same system.
Of course, different representations could also be grouped under the
same Node class.
[I-D.ietf-mile-rfc5070-bis] defined the HashData Class that describes
a file's hash information as also described in [RFC5901]. Similar to
the Node, if a HashData class consists of many digital signatures,
the signatures represent alternative hash algorithms for the same
signature. For example, if the HashData type is file-hash, then the
signatures represent MD5, SHA1, SHA2 etc hashes.
For grouped Key classes the logic changes. Multiple Key classes in a
WindowsRegistryKeysModified class represent necessary Windows
Registry Keys that constitute an indicator. All SHOULD be present in
order for the indicator to be present. Multiple
WindowsRegistryKeysModified classes grouped under the same RecordData
class represent alternatives for the same indicator. For example, if
a RecordData class included two WindowsRegistryKeysModified classes,
if either of the classes was true the RecordData class would be true.
4.4. Predicate Logic for watchlist of indicators
Multiple indicators occasionally need to be combined in an IODEF
document. For example, a botnet might have multiple command and
control servers. A consistent predicate logic for indicators SHOULD
be followed in order to present such relationships in IODEF.
[I-D.ietf-mile-rfc5070-bis] defines two new category attributes in
the System Class that can enhance the IODEF predicate logic
functionality. These are watchlist-source and watchlist-target and
Suzuki & Kampanakis Expires October 6, 2016 [Page 6]
Internet-Draft IODEF Guidance April 2016
they serve for watchlist indicator groupings. A watchlist of Systems
means that the information is ORed with the information in the Flow
section. In other words, if a Flow Class consists of multiple
Systems with watchlist-source or watchlist-target attributes the
Systems of the same watchlist type are ORed in the Flow Class.
Multiple Flows in the EventData Class follow AND logic as explained
in Section 4.3. There SHOULD NOT be more than one "watchlist-source"
and one "watchlist-target" Systems per Flow. In the following
example the EventData class will evaluates as a Flow of one System
with source address being (10.10.10.104 OR 10.10.10.106) AND target
address 10.1.1.1
10.10.10.104
10.10.10.106
10.1.1.1
Similarly, the HashData Class includes a type attribute that
introduces watchlist groupings (i.e. PKI_email_ds_watchlist,
PGP_email_ds_watchlist, file_hash_watchlist, email_hash_watchlist).
Two HashData classes that contain a watchlist type attribute follow
OR logic in a RecordData class. In the following example the
RecordData class consists of either of the two files with two
different hashes.
Suzuki & Kampanakis Expires October 6, 2016 [Page 7]
Internet-Draft IODEF Guidance April 2016
dummy.txt
141accec23e7e5157de60853cb1e01bc38042d
08f9086040815300b7fe75c184
dummy2.txt
141accec23e7e5157de60853cb1e01bc38042d
08f9086040815300b7fe75c184
Similarly, [I-D.ietf-mile-rfc5070-bis] introduces the
WindowsRegistryKeyModified Class which consists of Key Classes. Key
has an optional type attribute which has watchlist as an option in
order to include the ability to group Keys. Multiple Keys of the
same watchlist of indicators SHOULD be grouped in the same
WindowsRegistryKeysModified Class. These Keys follow OR logic.
4.5. Indicator identifiers
[I-D.ietf-mile-rfc5070-bis] defines attrbutes indicator-set-id and
indicator-uid. These are data elements that are commonly used as
indicators. They are used in mutliple IODEF classes. Their purpose
is to be able to define indicator relationships and reference
respectively. The indicator-uid is used as a unique indicator
identifier. Practitioners MAY use them to establish that a class
represents an indicator that is different than other IODEF contextual
information.
On the other hand, an IODEF report could contain multiple indicators
that are part of the same or different indicator group. For example,
an IP source address, a target address, that consitute a Flow and a
Suzuki & Kampanakis Expires October 6, 2016 [Page 8]
Internet-Draft IODEF Guidance April 2016
RecordData class respectively could be representing indicators of a
virus and the traffic it generates. In such a situation, the
indicator-set-id for all the classes (Address, RecordData) MUST be
the same. Unrelated indicators MUST contain different indicator-set-
id attributes or no indicator-set-id attributes.
4.6. Disclosure level of IODEF
This section describes how to control the disclosure level of IODEF
docuemnts.
The information conveyed in IODEF documents should be treated
carefully since the content may be confidential. There are two types
of restrictions on the use of IODEF: disclosure level indicator
provided by IODEF and the one provided by external measures.
IODEF has a common attribute, called "restriction", which indicates
the disclosure guideline to which the sender expects the recipient to
adhere for the information represented in the class and its children.
In this way, the sender can express the level of disclosure for each
components of an IODEF document. Assorted external measures could be
implemented. Among them is RID, which provides policy guidelines for
handling IODEF documents by preparing RIDPolicy class.
Note that the enforcement of above disclosure guidelines is another
issue. The recipient of the IODEF document needs to follow the
guidelines, but these disclosure guidelines themselves do not provide
any enforcement measures. Some appropriate measures, be it either
technical or operational, need to be considered for that.
5. Current uses of IODEF
IODEF is currently used by various organizations in order to
represent security incidents and share incident and threat
information between security operations organizations.
5.1. Inter-vendor and Service Provider Exercise
Various vendors organized and executed an exercise where multiple
threat indicators were exchanged using IODEF. The transport protocol
used was RID. The threat information shared included incidents like
DDoS attacks. Malware and Spear-Phishing. As this was a proof-of-
concept (PoC) exercise only example information (no real threats)
were shared as part of the exchanges.
Suzuki & Kampanakis Expires October 6, 2016 [Page 9]
Internet-Draft IODEF Guidance April 2016
____________ ____________
| Vendor X | | Vendor Y |
| RID Agent |_______-------------________| RID Agent |
|___________| | Internet | |___________|
-------------
---- RID Report message --->
-- carrying IODEF example ->
--------- over TLS -------->
<----- RID Ack message -----
<--- in case of failure ----
PoC peering topology
The figure above shows how RID interactions took place during the
PoC. Participating organizations were running RID Agent software on-
premises. The RID Agents formed peering relationships with other
participating organizations. When Entity X had a new incident to
exchange it would package it in IODEF and send it to Entity Y over
TLS in a RID Report message. In case there was an issue with the
message, Entity Y would send an RID Acknowledgement message back to
Entity X which included an application level message to describe the
issue. Interoperability between RID agents and the standards,
[RFC6545] and [RFC6546], was also proven in this exercise.
Appendix A includes some of the incident IODEF example information
that was exchanged by the organizations' RID Agents as part of this
proof-of-concept.
The first use-case included sharing of Malware Data Related to an
Incident between CSIRTs. After Entity X detected an incident, she
would put data about malware found during the incident in a backend
system. Entity X then decided to share the incident information with
Entity Y about the malware discovered. This could be a human
decision or part of an automated process.
Below are the steps followed for the malware information exchange
that was taking place:
(1) Entity X has a sharing agreement with Entity Y, and has already
been configured with the IP address of Entity Y's RID Agent
(2) Entity X's RID Agent connects to Entity Y's RID Agent, and
mutual authentication occurs using PKI certificates.
(3) Entity X pushes out a RID Report message which contains
information about N pieces of discovered malware. IODEF is used
in RID to discribe the
Suzuki & Kampanakis Expires October 6, 2016 [Page 10]
Internet-Draft IODEF Guidance April 2016
(a) Hash of malware files
(b) Registry settings changed by the malware
(c) C&C Information for the malware
(4) Entity Y receives RID Report message, sends RID Acknowledgement
message
(5) Entity Y stores the data in a format that makes it possible for
the back end to know which source the data came from.
Another use-case was sharing Distributed Denial of Service (DDoS) as
presented below information: Entity X, a Critical Infrastructure and
Key Resource (CIKR) company detects that their internet connection is
saturated with an abnormal amount of traffic. Further investigation
determines that this is an actual DDoS attack. Entity X's computer
incident response team (CIRT) contacts their ISP and shares
information with them about the attack traffic characteristics. In
addition, Entity X has an information sharing relationship with
Entity Y. It shares information with Entity Y on characteristics of
the attack to watch for. Entitty X's ISP is being overwhelmed by the
amount of traffic, so it shares attack signatures and IP addresses of
the most prolific hosts with its adjacent ISPs.
Below are the steps followed for a DDoS information exchange:
(1) Entity X has a sharing agreement with Entity Y, and has already
been configured with the IP address of Entity Y's RID Agent
(2) Entity X's RID Agent connects to Entity Y's RID Agent, and
mutual authentication occurs using PKI certificates.
(3) Entity X pushes out a RID Report message which contains
information about the DDoS attack. IODEF is used in RID to
discribe the
(a) Start and Detect dates and times
(b) IP Addresses of nodes sending DDoS Traffic
(c) Sharing and Use Restrictions
(d) Traffic characteristics (protocols and ports)
(e) HTTP User-Agents used
(f) IP Addresses of C&C for a botnet
Suzuki & Kampanakis Expires October 6, 2016 [Page 11]
Internet-Draft IODEF Guidance April 2016
(4) Entity Y receives RID Report message, sends RID Acknowledgement
message
(5) Entity Y stores the data in a format that makes it possible for
the back end to know which source the data came from.
One more use-case was sharing spear-phishing email information as
explained in the following scenario: The board members of several
defense contractors receive an email inviting them to attend a
conference in San Francisco. The board members are asked to provide
their personally identifiable information such as their home address,
phone number, corporate email, etc in an attached document which came
with the email. The board members were also asked to click on a URL
which would allow them to reach the sign up page for the conference.
One of the recipients believes the email to be a phishing attempt and
forwards the email to their corporate CSIRT for analysis. The CSIRT
identifies the email as an attempted spear phishing incident and
distributes the indicators to their sharing partners.
Below are the steps followed for a spear-phishing information
exchange between CSIRTs that was part of this PoC.
(1) Entity X has a sharing agreement with Entity Y, and has already
been configured with the IP address of Entity Y's RID Agent
(2) Entity X's RID Agent connects to Entity Y's RID Agent, and
mutual authentication occurs using PKI certificates.
(3) Entity X pushes out a RID Report message which contains
information about the spear-phishing email. IODEF is used in
RID to discribe the
(a) Attachment details (file Name, hash, size, malware family
(b) Target description (IP, domain, NSLookup)
(c) Email information (From, Subject, header information, date/
time, digital signature)
(d) Confidence Score
(4) Entity Y receives RID Report message, sends RID Acknowledgement
message
(5) Entity Y stores the data in a format that makes it possible for
the back end to know which source the data came from.
Suzuki & Kampanakis Expires October 6, 2016 [Page 12]
Internet-Draft IODEF Guidance April 2016
5.2. Implementations
In order to use IODEF, some tools that copes with IODEF documents,
such as the parsers of IODEF documents, are needed. Though arbitrary
implementations can be done, some guidelines are provided in
[I-D.ietf-mile-implementreport]. IODEF does not specify any MTI, but
provides this guideline document. The document provides a list of
implementations the authors have surveyed at the time of its
publication as well as some tips on the implementations. Readers are
requested to read the draft.
5.3. Other
IODEF is also used in various projects and products to consume and
share security information. Various vendor incident reporting
products have the ability to consume and export in IODEF format
[implementations]. Perl and Python modules (XML::IODEF, Iodef::Pb,
iodeflib) exist in order to parse IODEF documents and their
extensions. Additionally, some worldwide CERT organizations are
already able to use receive incident information in IODEF.
Future use-cases of IODEF could be:
(1) ISP notifying a national CERT or organization when it identifies
and acts upon an incident and CERTs notifying ISPs when they are
aware of incidents.
(2) Suspected phishing emails could be shared amongst organizations
and national agencies. Automation could validate web content
that the suspicious emails are pointing to. Identified
malicious content linked in a phishing email could then be
shared using IODEF. Phishing campaigns could thus be subverted
much faster by automating information sharing using IODEF.
(3) When finding a certificate that should be revoked, a thrid-party
would forward an automated IODEF message to the CA with the full
context of the certificate and the CA could act accordingly
after checking its validity. Alternatively, in the event of a
compromise of the private key of a certificate, a third-party
could alert the certificate owner about the compromise using
IODEF.
6. Updates
version -05 updates:
(1) Changed section title from "Restrictions in IODEF" to
"Disclosure level of IODEF" and added some description
Suzuki & Kampanakis Expires October 6, 2016 [Page 13]
Internet-Draft IODEF Guidance April 2016
(2) Mixed "Recommended classes to implement" section with
"Unnecessary Fields" section into "Minimal IODEF document"
section
(3) Added description to "Decide what IODEF will be used for"
section, "Implementations" section, and "Security
Considerations" section
version -04 updates:
(1) Expanded on the Extensions section using Take's suggestion.
(2) Moved Future use-cases under the Other section.
(3) CIF and APWG were consolidated in one "Implementation" section
(4) Added abstract of RFC7495 to the "External References" section
(5) Added Kathleen's example of malware delivery URL to "Appendix"
(6) Added a little description to "Recommended classes to implement"
section
version -03 updates:
(1) Added "Updates" section.
(2) Added details about the flow of information exchanges in "Inter-
vendor and Service Provider Exercise" section. Also updated the
usecases with more background information.
(3) Added future use-cases in the "Collective Intelligence
Framework" section
(4) Updated Perl and Python references with the actual module names.
Added IODEF implementation reference "implementations".
(5) Added Predicate logic section
(6) Updated Logic of watchlist of indicators section to simplify the
logic and include examples.
(7) Renamed Externally defined indicators section to Indicator
reference and elaborated on the use of indicator-uid and
indicator-set-uid attribute use.
version -02 updates:
Suzuki & Kampanakis Expires October 6, 2016 [Page 14]
Internet-Draft IODEF Guidance April 2016
(1) Updated the "Logic for watchlist of indications" section to
clarify the logic based on community feedback.
(2) Added "Inter-vendor and Service Provider Exercise" section.
(3) Added Appendix to include actual use-case IODEF examples.
7. Acknowledgements
8. Security Considerations
This document does not incur any new security issues, since it only
talks about the usage of IODEF, which is defined in RFC 5070
[RFC5070]. Nevertheless, readers of this document SHOULD refer to
the security consideration section of RFC 5070.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", RFC 5070,
DOI 10.17487/RFC5070, December 2007,
.
[RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document
Class for Reporting Phishing", RFC 5901,
DOI 10.17487/RFC5901, July 2010,
.
[RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)",
RFC 6545, DOI 10.17487/RFC6545, April 2012,
.
[RFC6546] Trammell, B., "Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS", RFC 6546,
DOI 10.17487/RFC6546, April 2012,
.
Suzuki & Kampanakis Expires October 6, 2016 [Page 15]
Internet-Draft IODEF Guidance April 2016
[RFC7203] Takahashi, T., Landfield, K., and Y. Kadobayashi, "An
Incident Object Description Exchange Format (IODEF)
Extension for Structured Cybersecurity Information",
RFC 7203, DOI 10.17487/RFC7203, April 2014,
.
[RFC7495] Montville, A. and D. Black, "Enumeration Reference Format
for the Incident Object Description Exchange Format
(IODEF)", RFC 7495, DOI 10.17487/RFC7495, March 2015,
.
9.2. Informative References
[APWG] "APWG", .
[CIF] "CIF", .
[I-D.ietf-mile-implementreport]
Inacio, C. and d. daisu-mi@nc.u-tokyo.ac.jp, "MILE
Implementation Report", draft-ietf-mile-implementreport-06
(work in progress), October 2015.
[I-D.ietf-mile-rfc5070-bis]
Danyliw, R., "The Incident Object Description Exchange
Format v2", draft-ietf-mile-rfc5070-bis-18 (work in
progress), March 2016.
[implementations]
"Implementations on IODEF",
.
Appendix A. Inter-vendor and Service Provider Exercise Examples
Below some of the incident IODEF example information that was
exchanged by the vendors as part of this proof-of-concept Inter-
vendor and Service Provider Exercise.
A.1. Malware
In this test, malware information was exchanged using RID and IODEF.
The information included file hashes, registry setting changes and
the C&C servers the malware uses.
Suzuki & Kampanakis Expires October 6, 2016 [Page 16]
Internet-Draft IODEF Guidance April 2016
189234
2013-03-07T16:14:56.757+05:30
Malware and related indicators identified
Malware with Command and Control Server
and System Changes
EXAMPLE CSIRT
emccirt@emc.com
Zeus
http://www.threatexpert.com/report.aspx?
md5=e2710ceb088dacdcb03678db250742b7
192.168.2.200
http://zeus.556677889900.com/log-bin/
lunch_install.php?aff_id=1&
lunch_id=1&maddr=&
action=install
Suzuki & Kampanakis Expires October 6, 2016 [Page 17]
Internet-Draft IODEF Guidance April 2016
MHg2NzUxQTI1MzQ4M0E2N0Q4NkUwRjg0NzYwRj
YxRjEwQkJDQzJFREZG
MHgyRTg4ODA5ODBENjI0NDdFOTc5MEFGQTg5NTE
zRjBBNA==
HKLM\Software\Microsoft\Windows\
CurrentVersion\Run\tamg
?\?\?%System%\wins\mc.exe\?\??
HKLM\Software\Microsoft\
Windows\CurrentVersion\Run\dqo
"\"\"%Windir%\Resources\
Themes\Luna\km.exe\?\?"
Cridex
http://www.threatexpert.com/report.aspx?
md5=c3c528c939f9b176c883ae0ce5df0001
Suzuki & Kampanakis Expires October 6, 2016 [Page 18]
Internet-Draft IODEF Guidance April 2016
10.10.199.100
8080
MHg3MjYzRkUwRDNBMDk1RDU5QzhFMEM4OTVBOUM
1ODVFMzQzRTcxNDFD
MHg0M0NEODUwRkNEQURFNDMzMEE1
QkVBNkYxNkVFOTcxQw==
MHg0M0NEODUwRkNEQURFNDMzMEE
1QkVBNkYxNkVFOTcxQw==
MHg3MjYzRkUwRDNBMDk1RDU5QzhFME
M4OTVBOUM1ODVFMzQzRTcxNDFD
Suzuki & Kampanakis Expires October 6, 2016 [Page 19]
Internet-Draft IODEF Guidance April 2016
HKLM\Software\Microsoft\Windows\
CurrentVersion\Run\KB00121600.exe
\?\?%AppData%\KB00121600.exe\?\?
http://foo.com:12345/evil/cc.php
evil.com
1.2.3.4
5.6.7.8
2001:dead:beef::
Suzuki & Kampanakis Expires October 6, 2016 [Page 20]
Internet-Draft IODEF Guidance April 2016
141accec23e7e5157de60853cb1e01bc3804
2d08f9086040815300b7fe75c184
HKLM\SYSTEM\CurrentControlSet\
Services\.Net CLR
HKLM\SYSTEM\CurrentControlSet\
Services\.Net CLR\Parameters
\"\"%AppData%\KB00121600.exe\"\"
HKLM\SYSTEM\CurrentControlSet\Services\
.Net CLR\Parameters\ServiceDll
C:\bad.exe
HKLM\SYSTEM\CurrentControlSet\
Services\.Net CLR\Parameters\Bar
Baz
Suzuki & Kampanakis Expires October 6, 2016 [Page 21]
Internet-Draft IODEF Guidance April 2016
A.2. Malware Delivery URL
This example indicates malware and related URL for file delivery.
189801
http://zeus.556677889900.example.com/log-bin/lunch_install.php?aff_id=1&lunch_id=1&maddr=&action=install
2012-12-05T12:20:00+00:00
2012-12-05T12:20:00+00:00
Malware and related indicators
Malware with C&C
example.com CSIRT
contact@csirt.example.com
192.0.2.200
A.3. DDoS
The DDoS test exchanged information that described a DDoS including
protocols and ports, bad IP addresses and HTTP User-Agent fields.
The IODEF version used for the data representation was based on
[I-D.ietf-mile-rfc5070-bis]
Suzuki & Kampanakis Expires October 6, 2016 [Page 22]
Internet-Draft IODEF Guidance April 2016
189701
2013-02-05T00:34:45+00:00
2013-02-05T01:15:45+00:00
2013-02-05T01:34:45+00:00
DDoS Traffic Seen
DDoS Traffic
90
Dummy Test
contact@dummytest.com
Dummy Test sharing with ISP1
Low Orbit Ion Cannon User Agent
http://blog.spiderlabs.com/2011/01/loic-ddos-
analysis-and-detection.html
http://en.wikipedia.org/wiki/Low_Orbit_Ion_Cannon
Suzuki & Kampanakis Expires October 6, 2016 [Page 23]
Internet-Draft IODEF Guidance April 2016
10.10.10.104
10.10.10.106
172.16.66.0/24
2001:db8:dead:beef::
1337
10.1.1.1
80
Information provided in FLow class instance is from
Inspection of traffic from network tap
A.4. Spear-Phishing
The Spear-Phishing test exchanged information that described a Spear-
Phishing email including DNS records and addresses about the sender,
malicious attached file information and email data. The IODEF
version used for the data representation was based on
[I-D.ietf-mile-rfc5070-bis].
Suzuki & Kampanakis Expires October 6, 2016 [Page 24]
Internet-Draft IODEF Guidance April 2016
189601
2013-01-04T08:01:34+00:00
2013-01-04T08:31:27+00:00
2013-01-04T08:06:12+00:00
2013-01-04T09:15:45+00:00
Zeus Spear Phishing E-mail with Malware Attachment
Malware with Command and Control Server and System
Changes
example.com CSIRT
contact@csirt.example.com
Targeting Defense Contractors,
specifically board members attending Dummy Con
Zeus
http://www.zeusevil.com
10.10.10.166
225
EXAMPLE-AS - University of Example"
172.16..0.0/16
mail1.evildave.com
172.16.55.6
225
EXAMPLE-AS - University of Example
evildaveexample.com
2013-01-04T09:10:24+00:00
evildaveexample.com MX prefernce = 10, mail exchanger
= mail1.evildave.com
mail1.evildaveexample.com
internet address = 172.16.55.6
zuesevil.com. IN TXT \"v=spf1 a mx -all\"
emaildave@evildaveexample.com
Join us at Dummy Con
StormRider 4.0
Suzuki & Kampanakis Expires October 6, 2016 [Page 26]
Internet-Draft IODEF Guidance April 2016
192.168.54.2
Dummy Con Sign Up Sheet.txt
152
141accec23e7e5157de60853cb1e01bc38042d
08f9086040815300b7fe75c184
FakeCA
EvilDaveExample
352bddec13e4e5257ee63854cb1f05de48043d09f9
Suzuki & Kampanakis Expires October 6, 2016 [Page 27]
Internet-Draft IODEF Guidance April 2016
076070845307b7ce76c185
Authors' Addresses
Mio Suzuki
NICT
4-2-1, Nukui-Kitamachi
Koganei, Tokyo 184-8795
JP
Email: mio@nict.go.jp
Panos Kampanakis
Cisco Systems
170 West Tasman Dr.
San Jose, CA 95134
US
Email: pkampana@cisco.com
Suzuki & Kampanakis Expires October 6, 2016 [Page 28]