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 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]