IODEF Usage Guidance
draft-ietf-mile-iodef-guidance-00

MILE Working Group                                         P. Kampanakis
Internet-Draft                                             Cisco Systems
Intended status: Informational                            April 26, 2013
Expires: October 28, 2013

                          IODEF Usage Guidance
                   draft-ietf-mile-iodef-guidance-00.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 users and 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 October 28, 2013.

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

Kampanakis              Expires October 28, 2013                [Page 1]
Internet-Draft            IODEF Usage Guidance                April 2013

   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  . . . . . . . . . . . . . . . . . . . . . . . . . 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.  Logic for  Multi-Indicator use-cases  . . . . . . . . . . . 4
     4.2.  Unnecessary Fields  . . . . . . . . . . . . . . . . . . . . 5
     4.3.  Restrictions in IODEF . . . . . . . . . . . . . . . . . . . 5
     4.4.  Enumerations  . . . . . . . . . . . . . . . . . . . . . . . 5
     4.5.  Extensions  . . . . . . . . . . . . . . . . . . . . . . . . 5
     4.6.  External References . . . . . . . . . . . . . . . . . . . . 5
     4.7.  Groupings . . . . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Common Security Concepts and how to describe them in IODEF  . . 6
     5.1.  Sinkholes and C&C, Bots . . . . . . . . . . . . . . . . . . 6
     5.2.  Domain Data . . . . . . . . . . . . . . . . . . . . . . . . 6
     5.3.  Malware . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     5.4.  Email Abuse - Phishing  . . . . . . . . . . . . . . . . . . 6
     5.5.  DoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   9.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7

Kampanakis              Expires October 28, 2013                [Page 2]
Internet-Draft            IODEF Usage Guidance                April 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 users and 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 October 28, 2013                [Page 3]
Internet-Draft            IODEF Usage Guidance                April 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.  Logic for  Multi-Indicator use-cases

   This section describes how multiple indicators can be combined in an
   IODEF document.  An example is the Watchlist-source element of how to
   do AND / OR (watchlist means or).  [We want to make sure the logic
   was consistent throughout the schema and set in guidance.  For Node
   information, a watchlist of Systems means that the information is
   ORed with the other information in the Flow section and an AND with
   rest of the content in the EventData grouping.  As such, we need to
   replicate this pattern elsewhere, which is easy to do in the current
   format.  For HashInformation type, A watchlist type was added for
   each value.  In the Key class, a type was added with watchlist as an
   option.  If the watchlist is used, the data provided is just that, a
   watchlist of separate values.  Like the Node class, if information is
   grouped together, it represents the same thing.  With this pattern,
   if you set the type value for HashInformation to file_hash, the list
   provided are just alternate representations for the same hash
   (sha256, sha1, md5, etc.).  For the Key information, it's a little
   different as the grouping without it would just be part of a joined

Kampanakis              Expires October 28, 2013                [Page 4]
Internet-Draft            IODEF Usage Guidance                April 2013

   event as opposed to alternate ways to represent the same value.  To
   keep the pattern consistent.  It would make sense to have the
   different Keys provided have the tags at the higher level
   (WindowsRegistryKeyModified tag included), but have them all
   represented within the same EventData instance.  The included
   examples are following this logic pattern if examples are helpful to
   weigh in on this.  If agreed on the pattern for logic. ] "

   [...More to be removed and added...]

4.2.  Unnecessary Fields

   This section talks about fields that do not always play in important
   role like Assessment, Impact

   [...More to be added...]

4.3.  Restrictions in IODEF

   This section describes how Restriction can pose challenges

   [...More to be added...]

4.4.  Enumerations

   This section explains how enumerators have been expanded to include
   multiple indicators.  And also how external ones can be defines.

   [...More to be added...]

4.5.  Extensions

   This section explains how to describe things IODEF can't describe
   (SCI draft), or extensions not yet known, or implemented, when do you
   use another xml schema encapsulated in iodef

   [...More to be added...]

4.6.  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 October 28, 2013                [Page 5]
Internet-Draft            IODEF Usage Guidance                April 2013

4.7.  Groupings

   This section describes set-id, indicator-id

   [...More to be added...]

5.  Common Security Concepts and how to describe them in IODEF

5.1.  Sinkholes and C&C, Bots

   Describes how Bots and their C&C can be presented using the updated
   IODEF schema

   [...More to be added...]

5.2.  Domain Data

   Describes how DNS data (A record, PTR records) can be described using
   the new IODEF schema

   [...More to be added...]

5.3.  Malware

   Describes how a piece of malware can be descrivbed using the updated
   IODEF schema.

   [...More to be added...]

5.4.  Email Abuse - Phishing

   Using ARF and/or http://ietf.org/rfc/rfc5901.txt

   [...More to be added...]

5.5.  DoS

   Describes how a common DDoS attack can be described using IODEF

   [...More to be added...]

6.  Security Considerations

Kampanakis              Expires October 28, 2013                [Page 6]
Internet-Draft            IODEF Usage Guidance                April 2013

7.  Acknowledgements

8.  Security Considerations

9.  Normative References

   [I-D.ietf-mile-sci]
              Takahashi, T., Landfield, K., Millar, T., and Y.
              Kadobayashi, "IODEF-extension to support structured
              cybersecurity information", draft-ietf-mile-sci-06 (work
              in progress), February 2013.

   [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.

Author's Address

   Panos Kampanakis
   Cisco Systems
   170 West Tasman Dr.
   San Jose, CA  95134
   US

Kampanakis              Expires October 28, 2013                [Page 7]