MILE Working Group P. Kampanakis
Internet-Draft Cisco Systems
Intended status: Informational July 12, 2013
Expires: January 13, 2014
IODEF Usage Guidance
draft-ietf-mile-iodef-guidance-01.txt
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.
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 January 13, 2014.
Copyright Notice
Copyright (c) 2013 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
Kampanakis Expires January 13, 2014 [Page 1]
Internet-Draft IODEF Usage Guidance July 2013
(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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Implementation Strategy . . . . . . . . . . . . . . . . . . . . 3
3.1. Recommended classes to implement . . . . . . . . . . . . . 4
3.2. Decide what IODEF will be used for . . . . . . . . . . . . 4
4. IODEF considerations and how to address them . . . . . . . . . 4
4.1. Unnecessary Fields . . . . . . . . . . . . . . . . . . . . 4
4.2. External References . . . . . . . . . . . . . . . . . . . . 4
4.3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Logic for watchlist of indications . . . . . . . . . . . . 5
4.5. Externally defined Indicators . . . . . . . . . . . . . . . 6
4.6. Restrictions in IODEF . . . . . . . . . . . . . . . . . . . 6
5. Current uses of IODEF . . . . . . . . . . . . . . . . . . . . . 6
5.1. Anti-Phishing Working Group . . . . . . . . . . . . . . . . 6
5.2. Collective Intelligence Framework . . . . . . . . . . . . . 6
5.3. Other . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Kampanakis Expires January 13, 2014 [Page 2]
Internet-Draft IODEF Usage Guidance July 2013
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
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 RFC
5070 [RFC5070] and I-D.draft-ietf-mile-sci [I-D.ietf-mile-sci].
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.
Kampanakis Expires January 13, 2014 [Page 3]
Internet-Draft IODEF Usage Guidance July 2013
It is critical for an implementer to follow a strategy according to
which he will chose to implement various IODEF classes. It is also
important to know what 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.
3.1. Recommended classes to implement
This section explains the mandatory to implement IODEF classes that
are required more than once and also are useful.
[...More to be added...]
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) Also it explains that other external schemata
might be needed to describe incidents or indicators, based on SCI
draft extensions.
[...More to be added...]
4. IODEF considerations and how to address them
4.1. Unnecessary Fields
This section talks about fields that do not always play in important
role like Assessment, Impact
[...More to be added...]
4.2. External References
draft draft-montville-mile-enum-reference-format "This format allows
the <Version> to be associated with the id rather than the id_type.
By requiring that a specific type and version be associated with the
identifier, an implementer can look up the type in an IANA table to
understand exactly what the identifier in ReferenceName is and how
s/he may expect that identifier to be structured."
[...More to be added...]
Kampanakis Expires January 13, 2014 [Page 4]
Internet-Draft IODEF Usage Guidance July 2013
4.3. Extensions
This section explains how to describe things IODEF can't describe
([I-D.ietf-mile-sci] draft), or extensions not yet known, or
implemented, when do you use another xml schema encapsulated in iodef
[...More to be added...]
4.4. Logic for watchlist of indications
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 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. These are watchlist-source and watchlist-
destination and they serve for watchlist indicator groupings. When
an IODEF Node consists of two or more System Classes with various
watchlist-source and watchlist-destination attributes (watchlist of
Systems) the System information should be ORed with the information
in the Flow Class. In other words, either System description should
be considered as a watchlist indicator. The rest of the content in
the EventData Class the Node belongs to should be combined with the
watchlist of Systems using AND logic. In other words, the rest of
the EventData content describes a watchlist indicator for any of
System in the watchlist of Systems.
IODEF's grouping predicate logic follows the above pattern
consistently. [I-D.ietf-mile-rfc5070-bis] defined the
HashInformation Class that describes a file hash information as also
described in [RFC5901]. The HashInformation Class is of
HashSigDetails type which consists of elements that describe the file
hash details. Some of the attributes of the HashSigDetails are
introduced to describe watchlist groupings (i.e.
PKI_email_ds_watchlist, PGP_email_ds_watchlist, file_hash_watchlist,
email_hash_watchlist). If any of these attributes are used in two or
more HashInformation Classes of a Record then HashInformation content
is ORed for the Record. For example, if two HashInformation types
are set to file_hash, the list of hash details provided are just
alternate representations for the same hash (SHA256. SHA1 etc).
Similarly, if multiple HashInformation are in a Record using
Reference elements or others, they should all be treated as different
representations of the same file hash, assuming the FileName element
is not used in the HashInformation.
In some cases the predicate logic in IODEF can slightly change.
[I-D.ietf-mile-rfc5070-bis] introduces the WindowsRegistryKeyModified
Kampanakis Expires January 13, 2014 [Page 5]
Internet-Draft IODEF Usage Guidance July 2013
Class which is of type RegistryKeyModified. RegistryKeyModified has
an optional type attribute which has watchlist as an option in order
to include the ability to group WindowsRegistryKeyModified. In order
to group multiple WindowsRegistryKeyModified of the same watchlist of
indicators multiple WindowsRegistryKeysModified should be used in the
same RecordData or EventData Class. If the RegistryKeyModified
Classes are not under the same RecordData or EventData Class they
should be treated as different indicator Keys modified.
4.5. Externally defined Indicators
set-uid,uid and its use with SCI draft [I-D.ietf-mile-sci]
[...More to be added...]
4.6. Restrictions in IODEF
This section describes how Restriction can pose challenges
[...More to be added...]
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. Anti-Phishing Working Group
The Anti-Phishing Working Group ([APWG]) is using [RFC5070] to
represent email phishing information. [APWG] also uses IODEF to
aggregate and share Bot and Infected System Alerting and Notification
System (BISANS) and Cyber Bullying IODEF records. Special IODEF
extensions are used in order to mark the sensitivity of the exchanged
information. Shared infected system or email phishing records can
then be used by interested parties in order to provide mitigations.
[APWG] leverages tools of its eCRISP-X toolkit in order to share and
report e-Crime IODEF records.
5.2. Collective Intelligence Framework
The Collective Intelligence Framework [CIF] is a cyber threat
intelligence management system that uses IODEF to combine known
malicious threat information from multiple sources and use that it to
identify, detect and mitigate. The threat intelligence can be IP
addresses, domains and URLs that are involved in malicious activity.
IODEF records can be consumed by a CIF standalone client or CIF
Kampanakis Expires January 13, 2014 [Page 6]
Internet-Draft IODEF Usage Guidance July 2013
browser plugins that a user can use to make informed decisions about
threat information.
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.
Perl and Java modules exist in order to parse IODEF documents and
their extensions. Additionally worldwide CERT organizations are
already able to use receive incident information in IODEF.
6. Security Considerations
7. Acknowledgements
8. Security Considerations
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", RFC 5070,
December 2007.
[RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document
Class for Reporting Phishing", RFC 5901, July 2010.
9.2. Informative References
[APWG] "APWG", <http://apwg.org/>.
[CIF] "CIF", <https://code.google.com/p/
collective-intelligence-framework/wiki/WhatisCIF>.
[I-D.ietf-mile-rfc5070-bis]
Danyliw, R. and P. Stoecker, "The Incident Object
Description Exchange Format",
draft-ietf-mile-rfc5070-bis-00 (work in progress),
May 2013.
Kampanakis Expires January 13, 2014 [Page 7]
Internet-Draft IODEF Usage Guidance July 2013
[I-D.ietf-mile-sci]
Takahashi, T., Landfield, K., Millar, T., and Y.
Kadobayashi, "IODEF-extension for structured cybersecurity
information", draft-ietf-mile-sci-08 (work in progress),
July 2013.
Author's Address
Panos Kampanakis
Cisco Systems
170 West Tasman Dr.
San Jose, CA 95134
US
Email: pkampana@cisco.com
Kampanakis Expires January 13, 2014 [Page 8]
