MILE Working Group P. Kampanakis Internet-Draft Cisco Systems Intended status: Informational October 18, 2013 Expires: April 21, 2014 IODEF Usage Guidance draft-ietf-mile-iodef-guidance-02 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 April 21, 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 April 21, 2014 [Page 1] Internet-Draft IODEF Usage Guidance October 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. Inter-vendor and Service Provider Exercise . . . . . . . . 7 5.3. Collective Intelligence Framework . . . . . . . . . . . . 7 5.4. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Inter-vendor and Service Provider Exercise Examples . . . . . . . . . . . . . . . . . . . . . . 9 A.1. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 A.2. Malware . . . . . . . . . . . . . . . . . . . . . . . . . 11 A.3. Spear-Phishing . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Kampanakis Expires April 21, 2014 [Page 2] Internet-Draft IODEF Usage Guidance October 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 April 21, 2014 [Page 3] Internet-Draft IODEF Usage Guidance October 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 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 April 21, 2014 [Page 4] Internet-Draft IODEF Usage Guidance October 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. In [RFC5070], predicate logic only consisted of logical AND. For example, if an Flow Class contained two System classes with "source" and "destination" as category attributes, it was assumed that both Systems should be present in order for the Flow to be true and thus marked as an indicator. [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-destination and they serve for watchlist indicator groupings. When a Flow Class that consists of multiple Systems with watchlist-source and watchlist-destination attributes (watchlist of Systems) the System information should be ORed for the Flow Class described. In other words, either System description should be considered as a watchlist indicator. The content in the EventData Class the Node belongs to should be combined with the watchlist of Systems using AND logic. Different Flow classes that consist of different System classes (with watchlist-source or destination as attributes) follow AND logic in their parent EventData Class. 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_watchlist, the list of hash details provided are just alternate representations for the same hash (SHA256. SHA1 etc). Kampanakis Expires April 21, 2014 [Page 5] Internet-Draft IODEF Usage Guidance October 2013 Similarly, if multiple HashInformation classes, with "watchlist" in their category attribute, 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 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. Kampanakis Expires April 21, 2014 [Page 6] Internet-Draft IODEF Usage Guidance October 2013 5.2. 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. ____________ ____________ | 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. 5.3. 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 browser plugins that a user can use to make informed decisions about Kampanakis Expires April 21, 2014 [Page 7] Internet-Draft IODEF Usage Guidance October 2013 threat information. 5.4. 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, some 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. [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6545, April 2012. [RFC6546] Trammell, B., "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS", RFC 6546, April 2012. 9.2. Informative References [APWG] "APWG", . [CIF] "CIF", . Kampanakis Expires April 21, 2014 [Page 8] Internet-Draft IODEF Usage Guidance October 2013 [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. [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. 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. DDoS 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 Kampanakis Expires April 21, 2014 [Page 9] Internet-Draft IODEF Usage Guidance October 2013 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 10.10.10.104 10.10.10.106 1172.16.66.0/24 2001:db8:dead:beef:: 1337 10.1.1.1 Kampanakis Expires April 21, 2014 [Page 10] Internet-Draft IODEF Usage Guidance October 2013 80 Information provided in FLow class instance is from Inspection of traffic from network tap A.2. Malware 189234 2013-03-07T16:14:56.757+05:30 Malware and related indicators identified Malware with Command and Control Server and System Changes EXAMPLE CIRT emccirt@emc.com Zeus http://www.threatexpert.com/report.aspx? md5=e2710ceb088dacdcb03678db250742b7 Kampanakis Expires April 21, 2014 [Page 11] Internet-Draft IODEF Usage Guidance October 2013 192.168.2.200 http://zeus.556677889900.com/log-bin/ lunch_install.php?aff_id=1&amp; lunch_id=1&amp;maddr=&amp; action=install MHg2NzUxQTI1MzQ4M0E2N0Q4NkUwRjg0NzYwRj YxRjEwQkJDQzJFREZG MHgyRTg4ODA5ODBENjI0NDdFOTc5MEFGQTg5NTE zRjBBNA== HKLM\Software\Microsoft\Windows\ CurrentVersion\Run\tamg ?\?\?%System%\wins\mc.exe\?\?? Kampanakis Expires April 21, 2014 [Page 12] Internet-Draft IODEF Usage Guidance October 2013 HKLM\Software\Microsoft\ Windows\CurrentVersion\Run\dqo "\"\"%Windir%\Resources\ Themes\Luna\km.exe\?\?" Cridex http://www.threatexpert.com/report.aspx? md5=c3c528c939f9b176c883ae0ce5df0001 10.10.199.100 8080 MHg3MjYzRkUwRDNBMDk1RDU5QzhFMEM4OTVBOUM 1ODVFMzQzRTcxNDFD Kampanakis Expires April 21, 2014 [Page 13] Internet-Draft IODEF Usage Guidance October 2013 MHg0M0NEODUwRkNEQURFNDMzMEE1 QkVBNkYxNkVFOTcxQw== MHg0M0NEODUwRkNEQURFNDMzMEE 1QkVBNkYxNkVFOTcxQw== MHg3MjYzRkUwRDNBMDk1RDU5QzhFME M4OTVBOUM1ODVFMzQzRTcxNDFD HKLM\Software\Microsoft\Windows\ CurrentVersion\Run\KB00121600.exe \?\?%AppData%\KB00121600.exe\?\? http://foo.com:12345/evil/cc.php evil.com Kampanakis Expires April 21, 2014 [Page 14] Internet-Draft IODEF Usage Guidance October 2013 1.2.3.4 5.6.7.8 2001:dead:beef:: 141accec23e7e5157de60853cb1e01bc3804 2d08f9086040815300b7fe75c184 HKLM\SYSTEM\CurrentControlSet\ Services\.Net CLR HKLM\SYSTEM\CurrentControlSet\ Services\.Net CLR\Parameters \"\"%AppData%\KB00121600.exe\"\" Kampanakis Expires April 21, 2014 [Page 15] Internet-Draft IODEF Usage Guidance October 2013 HKLM\SYSTEM\CurrentControlSet\Services\ .Net CLR\Parameters\ServiceDll C:\bad.exe HKLM\SYSTEM\CurrentControlSet\ Services\.Net CLR\Parameters\Bar Baz A.3. Spear-Phishing 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 Kampanakis Expires April 21, 2014 [Page 16] Internet-Draft IODEF Usage Guidance October 2013 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 Kampanakis Expires April 21, 2014 [Page 17] Internet-Draft IODEF Usage Guidance October 2013 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 192.168.54.2 Dummy Con Sign Up Sheet.txt 152 141accec23e7e5157de60853cb1e01bc38042d 08f9086040815300b7fe75c184 Kampanakis Expires April 21, 2014 [Page 18] Internet-Draft IODEF Usage Guidance October 2013 FakeCA EvilDaveExample 352bddec13e4e5257ee63854cb1f05de48043d09f9 076070845307b7ce76c185 Author's Address Panos Kampanakis Cisco Systems 170 West Tasman Dr. San Jose, CA 95134 US Email: pkampana@cisco.com Kampanakis Expires April 21, 2014 [Page 19]