IODEF Overview

IODEF Overview

The The Incident Object Description Exchange Format (IODEF) specification was developed by members of the IETF Extended Incident Handling (INCH) Working Group, part of the IETF Security Area.

The Incident Object Description and Exchange Format (IODEF) is a format for Computer Security Incident Response Teams (CSIRTs) to exchange operational and statistical incident information among themselves, their constituency, and their collaborators. It can also provide the basis for the development of interoperable tools and procedures for incident reporting.

By using the IODEF in their workflow and incident handling system, an organization can benefit from:

• a single data schema that can represent information from a variety of subordinate teams or CSIRTs
• a common incident data format that facilities collaboration among affected members of the security community (e.g., users, vendors, response teams, law enforcement)
• the simplification in building an incident correlation and statistics system that process incident reports from different CSIRTs [from the October 29, 2002 spec Introduction]

"The purpose of the Incident Object Description and Exchange Format is to define a common data format for describing and exchanging incident information between collaborating Computer Security Incident Response Teams (CSIRTs)... One of the design principles in the IODEF is compatibility with the Intrusion Detection Message Exchange Format (IDMEF) developed for intrusion detection systems. For this reason, IODEF is heavily based on the IDMEF and provides upward compatibility with it." From the October 22, 2002 Requirements document

The IETF Extended Incident Handling Working Group was chartered to "define data formats for communication between: (1) a CSIRT and its constituency (e.g., users, customers, trusted reporters) which reports system misuse; (2) a CSIRT and parties involved in an incident investigation (e.g., law enforcement, attacking site); and (3) collaborating CSIRTs sharing information. This format will support the now largely human-intensive dimension of the incident handling process. It will represent the product of various incremental data gathering and analysis operations performed by a CSIRT from the time when the system misuse was initially reported (perhaps by an automated system) till ultimate resolution. Specifically, the working group will address the issues related to representing the source(s) and target(s) of system misuse, as well as the analysis of their behavior; the evidence to support any analysis results; a scheme to document the incident investigation and analysis process; and constructs to facilitate the exchange of security information across administrative domains (e.g., internationalization, data sensitivity). From the Charter.

Principal References

• IETF Extended Incident Handling (INCH) Working Group Charter
• INCH Working Group Status Pages
• Discussion mailing list of the IETF Incident Handling working group. INCH@NIC.SURFNET.NL.
• IETF Extended Incident Handling (INCH) Working Group. Unofficial IETF INCH WG Status Page.
• IODEF/IDMEF Solutions. From eCSIRT.net Project. "By applying new established protocols (IODEF and IDMEF) communication should be formalized and integrated into the internal workflows. This will enable semi-automated handling of new incoming reports and facilitate complete and timely reporting to other CSIRTs."
• IODEF Schema Information Page. Maintained by Yuri Demchenko.
• IODEF WG. Information from Terena.nl.
• See also: "Intrusion Detection Message Exchange Format."
• See also: Application Security Standards - Local reference collection.

Publication Milestones

• [July 2008] "Extensions to the IODEF-Document Class for Reporting Phishing, Fraud, and Other Crimeware." Edited by Patrick Cain (The Cooper-Cain Group, Inc) and David Jevans (The Anti-Phishing Working Group). IETF Network Working Group, Internet Draft. July 30, 2008, expires January 31, 2009. 60 pages. "This document extends The Incident Object Description Exchange Format (RFC 5070) to support the reporting of phishing, fraud, other types of electronic crime, and widespread spam incidents. Background: "Deception activities, such as receiving an email purportedly from a bank requesting you to confirm your account information, are an expanding attack type on the Internet. The terms phishing and fraud are used interchangeably in this document to characterize broadly- launched social engineering attacks in which an electronic identity is misrepresented in an attempt to trick individuals into revealing their personal credentials (e.g., passwords, account numbers, personal information, ATM PINs, etc.). A successful phishing attack on an individual allows the phisher (i.e., the attacker) to exploit the individual's credentials for financial or other gain. Phishing attacks have morphed from directed email messages from alleged financial institutions to more sophisticated lures that may also include malware. This document defines a data format extension to the Incident Object Description Exchange Format (IODEF) that can be used to describe information about a phishing incident or wide-spread spam incident. Sections 2 and 3 of this document introduce the high-level report format and how to use it. Sections 4 and 5 describe the data elements of the fraud extensions. This document includes an XML schema for the extensions and a few example fraud reports. The extensions defined in this document may be used to report targeted ('spear') phishing, broad multi-recipient phishing, wide- spread spam events, the distribution of malware, and evolving Internet-based fraud attempts. Receipt of single spam message must NOT be reported via these extensions as these formats are for more general, widespread events... The IODEF defines a flexible and extensible format and supports a granular level of specificity. This phishing extension reuses subsets of the IODEF data model and, where appropriate, specifies new data elements. Leveraging an existing specification allows for more rapid adoption and reuse of existing tools in organizations. For clarity, and in order to eliminate duplication, only the additional structures necessary for describing the exchange of phishing and e-crime activity are provided... Fraudulent events are reported in a Fraud Activity Report which is an instance of an XML IODEF-Document Incident element with added EventData and AdditionalData elements. The additional fields in the EventData specific to phishing and fraud are enclosed into a PhraudReport XML element. Fraudulent activity may include multiple emails, instant messages, or network messages, scattered over various times, locations, and methodologies. The PhraudReport within an EventData may include information about the email header and body, details of the actual phishing lure, correlation to other attacks, and details of the removal of the web server or credential collector. As a phishing attack may generate multiple reports to an incident team, multiple PhraudReports may be combined into one EventData structure and multiple EventData structures may be combined into one Incident Report. One IODEF Incident report may record one or more individual phishing events and may include multiple EventData elements. This document defines new extension elements for the EventData and Record Item IODEF XML elements and identifies those required in a PhraudReport..."

• [Januery 11, 2008] "IODEF/RID over SOAP." By Kathleen M. Moriarty (MIT Lincoln Laboratory) and Brian H. Trammell (CERT Network Situational Awareness). IETF Internet Draft 'draft-moriarty-post-inch-rid-soap-02'. December 27, 2007, expires June 27, 2008. "The Incident Object Description Exchange Format (IODEF) specification describes an XML document format for the purpose of exchanging data between CSIRTS or those responsible for security incident handling for network providers (NPs). The defined document format provides an easy way for CSIRTS to exchange data in a way which can be easily parsed. In order for the IODEF documents to be shared between entities, a uniform method for transport is necessary. SOAP will provide a layer of abstraction and enable the use of multiple transport protocol bindings. IODEF documents and extensions will be contained in an XML Real-time Inter-network Defense (RID) envelope inside the body of a SOAP message. For some message types, the IODEF document or RID document may stand alone in the body of a SOAP message. The RIDPolicy class of RID (e.g., policy information that may affect message routing) will appear in the SOAP message header. HTTP/TLS (RFC 4346) has been selected as the required SOAP binding for exchanging IODEF/RID messages. The primary reason for selecting HTTP/TLS is due to the existence of multiple successful implementations of SOAP over HTTP/TLS, and to its being widely understood, despite the additional overhead associated with this combination. Excellent tool support exists to ease the development of applications using SOAP over HTTP. BEEP may actually be better suited as a transport for RID messages containing IODEF documents, but does not yet have wide adoption. Standards exist for the HTTPS or HTTP/TLS binding for SOAP, and a standard is in development for SOAP over BEEP... Documents intended to be shared among multiple constituencies must share a common format and transport mechanism. The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange. This draft outlines the SOAP wrapper for all IODEF documents and extensions to facilitate an interoperable and secure communication of documents. The SOAP wrapper allows for flexibility in the selection of a transport protocol. SOAP will be used to provide the messaging framework and can make distinctions as to how messages should be handled by each participating system. SOAP has been selected because of the flexibility it provides for binding with transport protocols, which can be independent of the IODEF/RID messaging system."

• [October 11, 2007] "The Incident Object Description Exchange Format." Edited by Roman Danyliw (CERT Program), Jan Meijer (SURFnet bv), and Yuri Demchenko (University of Amsterdam). IETF Internet Draft. Produced by members of the IETF Extended Incident Handling Working Group. See the extracted XML Schema, and I-D Tracker. Status: Approved by the IESG as a Proposed Standard. July 31, 2007. 96 pages. The IESG has announced the approval of "The Incident Object Description Exchange Format" specification as an IETF Proposed Standard. This document has been produced by members of the IETF Extended Incident Handling Working Group. There was consensus in the WG to publish this document, though Working Group has now closed. There are seven implementations of the IODEF that provided useful feedback on the completeness and quality of the specification. These implementations come from CERT-Verbund (SIRIOS), Cooper-Cain Inc.* (Anti-Phishing WG), Cyber Solutions Inc.*, DFLabs*, eCSIRT.net, MIT Lincoln Labs*, and NTT*. Furthermore, a subset of these organizations [noted by an asterisk] participated in a semantics interoperability event that also yielded additional feedback on the data model. "The Incident Object Description Exchange Format (IODEF) 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 I-D document describes the information model for the IODEF and provides an associated data model specified with XML Schema. Organizations require help from other parties to mitigate malicious activity targeting their network and to gain insight into potential threats. This coordination might entail working with an ISP to filter attack traffic, contacting a remote site to take down a bot-network, or sharing watch-lists of known malicious IP addresses in a consortium. IODEF provides an XML representation for conveying incident information across administrative domains between parties that have an operational responsibility of remediation or a watch-and-warning over a defined constituency. The data model encodes information about hosts, networks, and the services running on these systems; attack methodology and associated forensic evidence; impact of the activity; and limited approaches for documenting workflow. The IODEF is only one of several security relevant data representations being standardized. Attempts were made to ensure they were complimentary. The data model of the Intrusion Detection Message Exchange Format influenced the design of the IODEF... Implementing the IODEF in XML provides numerous advantages. Its extensibility makes it ideal for specifying a data encoding framework that supports various character encodings. Likewise, the abundance of related technologies (e.g., XSL, XPath, XML-Signature) makes for simplified manipulation..."

• [April 26, 2007] "The Incident Object Description Exchange Format." By Roman Danyliw (CERT Program Pittsburgh, USA), Jan Meijer (SURFnet bv Utrecht, Netherlands), and Yuri Demchenko (University of Amsterdam Amsterdam, Netherlands). IETF Extended Incident Handling Working Group, Standards Track I-D. April 26, 2007. I-D Tracker citation See also the XML Schema. The "Incident Object Description Exchange Format" specification is an IETF Standards Track I-D produced by members of the IETF Extended Incident Handling Working Group. Organizations require help from other parties to mitigate malicious activity targeting their network and to gain insight into potential threats. This coordination might entail working with an ISP to filter attack traffic, contacting a remote site to take down a bot-network, or sharing watch-lists of known malicious IP addresses in a consortium. The Incident Object Description Exchange Format (IODEF) is a format for representing computer security information commonly exchanged between Computer Security Incident Response Teams (CSIRTs). It provides an XML representation for conveying incident information across administrative domains between parties that have an operational responsibility of remediation or a watch-and-warning over a defined constituency. The data model encodes information about hosts, networks, and the services running on these systems; attack methodology and associated forensic evidence; impact of the activity; and limited approaches for documenting workflow. The overriding purpose of the IODEF is to enhance the operational capabilities of CSIRTs. Community adoption of the IODEF provides an improved ability to resolve incidents and convey situational awareness by simplifying collaboration and data sharing. This structured format provided by the IODEF allows for: (1) increased automation in processing of incident data since the resources of security analysts to parse free-form textual documents will be reduced; (2) decreased effort in normalizing similar data (even when highly structured) from different sources; and (3) a common format on which to build interoperable tools for incident handling and subsequent analysis, specifically when data comes from multiple constituencies... Section 3 describes the abstract IODEF data model and Section 8 provides the corresponding XML Schema implementation. The types used by the data model are covered in Section 2.

• [April 9, 2007,] "Real-time Inter-network Defense." By Kathleen M. Moriarty (MIT Lincoln Laboratory, 244 Wood Street, Lexington, MA 02420). IETF Extended Incident Handling Working Group, Internet Draft 'draft-moriarty-post-inch-rid-01.txt'. April 9, 2007, expires October 9, 2007. I-D Tracker citation. Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms across for a complete incident handling solution... The communication mechanism described in this paper, Real-time Inter-network Defense (RID), takes into consideration the information needed by various single network trace implementations and the requirement for network providers to decide if a trace request should be permitted to continue. The data in RID messages will be represented in an Extensible Markup Language (XML) document using the Incident Object Description Exchange Format (IODEF) and RID. By following this model, integration with other aspects of the network for incident handling is simplified. Finally, methods are incorporated into the communication system to indicate what actions need to be taken closest to the source in order to halt or mitigate the effects of the attack at hand. RID is intended to provide a method to communicate the relevant information between Computer Security Incident Response Teams (CSIRTs) while being compatible with a variety of existing and possible future detection tracing and response approaches. Security and privacy considerations are of high concern since potentially sensitive information may be passed through RID messages. RID messaging will take advantage of XML security, security, and privacy policy information set in the RID schema. The RID schema acts as an XML envelope to support the communication of IODEF documents for exchanging or tracing information security incidents. RID messages will be encapsulated in a SOAP wrapper. The authentication, integrity, and authorization features each layer has to offer will be used to achieve the level of security that is necessary. SOAP is used as a message wrapper to direct messages appropriately, and the SOAP binding will be used with a specific transport protocol, HyperText Transfer Protocol (HTTP) and Transport Layer Security (TLS) set as the mandatory to implement protocol and others are optional such as BEEP, S/MIME, and XML SNMP..."

• [April 9, 2007] "IODEF/RID over SOAP." By Kathleen M. Moriarty (MIT Lincoln Laboratory, 244 Wood Street, Lexington, MA 02420). IETF Extended Incident Handling Working Group, Internet Draft 'draft-moriarty-post-inch-rid-soap-01.txt'. April 9, 2007, expires October 9, 2007. I-D Tracker citation. "Documents intended to be shared among multiple constituencies must share a common format and transport mechanism. The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange. This draft outlines the SOAP wrapper for all IODEF documents and extensions to facilitate an interoperable and secure communication of documents. The SOAP wrapper allows for flexibility in the selection of a transport protocol. The transport protocols will be provided through existing standards and SOAP binding, such as SOAP over HTTP/TLS and SOAP over BEEP... HTTP/TLS has been selected as the REQUIRED SOAP binding for exchanging IODEF/RID messages. The primary reason for selecting HTTP/TLS is due to the existence of multiple successful implementations of SOAP over HTTP/TLS, and to its being widely understood, despite the additional overhead associated with this combination. Excellent tool support exists to ease the development of applications using SOAP over HTTP. BEEP may actually be better suited as a transport for RID messages containing IODEF documents, but does not yet have wide adoption. Standards exist for the HTTPS or HTTP/TLS binding for SOAP... IODEF/RID documents, including all supported extensions, intended to be shared between CSIRTS or NPs MUST use a SOAP wrapper, along with a supported transport protocol binding, for transport. The transport is independent of the wrapper. SOAP will be used to provide the messaging framework and can make distinctions as to how messages should be handled by each participating system. SOAP has been selected because of the flexibility it provides for binding with transport protocols, which can be independent of the IODEF/RID messaging system..."

• [March 2007] "How to Share Transaction Fraud (Thraud) Report Data." By David M'Raihi (VeriSign, Inc) [primary contact]. Other Authors' contact information: Sharon Boeyen (Entrust Inc), Michael Grandcolas (Grandcolas Consulting LLC), and Siddharth Bajaj (VeriSign, Inc). IETF Network Group, Internet Draft 'draft-mraihi-inch-thraud-02.txt'. March 2007, expires September 2007. I-D Tracker citation. "This document describes a data-format and protocol for defining and exchanging Transaction Fraud (Thraud) Report Data. It extends the INCH WG's IODEF XML incident reporting format. Both inbound (Thraud Reports) and outbound (Thraud Watchlists) mechanisms are presented. This work has been endorsed by the Initiative for Open AuTHentication (OATH)... Financial institutions and merchants are confronted with online fraud attacks targeted against their customers through various means. Today there is no standardized data format and open protocol that organizations and law enforcement can use to share known/suspicious transaction fraud data. There is a clear opportunity for creating an open framework to enable organizations, using a variety of fraud monitoring products, to contribute information related to known or suspicious fraud activity. The very same framework should also formalize mechanisms for distributing correlated updates to all participating members... The specific focus of this document is the proposal of XML document definitions for Fraud Reports and the protocols by which they can be exchanged. The document proposes a definition for both inbound (Thraud Reports) and outbound (Thraud Watchlists) mechanisms. In section 3 we introduce the different components of a transaction fraud. The reporting method via an IODEF-document is described in section 4, and we define the report elements in section 5. In the next section we describe the required elements with respect to the IODEF format and follow with security considerations in section 7..." See also Initiative for Open Authentication (OATH).

• [October 15, 2006] "Extensions to the IODEF-Document Class for Phishing, Fraud, and Other Crimeware." By Patrick Cain (The Cooper-Cain Group, Inc., P.O. Box 400992, Cambridge, MA, USA) and David Jevans (The Anti-Phishing Working Group, 5150 El Camino Real, Suite A20, Los Altos, CA 94022, USA). IETF Network Working Group, Internet Draft 'draft-cain-post-inch-phishingextns-00'. October 15, 2006, expires April 18, 2007. I-D Tracker citation. "Deception-driven activities on the Internet, such as receiving an email purportedly from a bank requesting you to confirm your account information, are an expanding attack type on the Internet. The terms phishing and fraud are used interchangeably in this document to characterize a broadly-launched social engineering attacks in which an electronic identity is misrepresented in an attempt to trick individuals into revealing their personal credentials ( e.g., passwords, account numbers, personal information, ATM PINs, etc.). A successful phishing attack on an individual allows the phisher (i.e. the attacker) to exploit the individual's credentials for financial or other gain. Phishing attacks have morphed from directed email messages from alleged financial institutions to more sophisticated lures that may also include malware. This document defines a data format extension to the Incident Object Description Exchange Format (IODEF) that can be used to describe information about a phishing incident or wide-spread spam incident. Sections 1 and 2 of this document introduce the high-level report format. Sections 3 and 4 describe the data elements of the fraud extensions. This document includes an XML schema for the extensions and a few example fraud reports... The IODEF defines a flexible and extensible format and supports a granular level of specificity. This phishing extension reuses subsets of the IODEF data model and, where appropriate, specifies new data elements. Leveraging an existing specification allows for more rapid adoption and reuse of existing tools in organizations. For clarity, and in order to eliminate duplication, only the additional structures necessary for describing the exchange of phishing and e-crime activity are provided. The use of this already existent and operational format, based on the Intrusion Detection Message Exchange Format (IDMEF), allows for quicker vendor adoption and reuse of existing tools in organizations. To reduce duplication and to be compatible with forward modifications to the base IODEF definitions this document only identifies additional structures necessary for exchanging phishing and e-crime information..."

• [June 25, 2006] "Requirements for the Format for Incident Information Exchange (FINE)." IETF INCH Working Group, Internet Dtaft 'draft-ietf-inch-requirements-08.txt'. June 25, 2006, expires December 24, 2006. I-D Tracker citation. Glenn Mansfield Keeni (Cyber Solutions Inc. Sendai, Japan Roman Danyliw (CERT Coordination Center, 4500 Fifth Ave., Pittsburgh, PA 15213, USA Yuri Demchenko (University of Amsterdam, The Netherlands). Credits: Hiroyuki Kido, Hiroyuki Ohno, Kathleen M. Moriarty, and Jan Meijer. "Computer security incidents occur across administrative domains, often spanning different organizations and national borders. Hence, a response requires coordination and collaboration between the involved parties and the responsible computer security incident response teams (CSIRTs). The basis for this interaction is often data and statistics describing the nature of the incident. This information, referred to as an incident report in this document, will not only support response activity to the specific incident, but may also be used for historical analysis or proactive responses. This document defines the high-level functional requirements for a format that can support the exchange of incident reports. The abstract format being discussed is referred to as the Format for INcident information Exchange (FINE). The implementation of the requirements, the format itself, is out of the scope of this document... The intent of FINE is to enable rapid and effective response to incidents by improving the ability of CSIRTs to exchange and process incident reports... The security properties of FINE reports SHOULD be independent of the communication mechanism. The exchange of incident reports is typically conducted using standard communication protocols (e.g., SMTP, HTTP, FTP, XML Web Services). The security properties of FINE MUST NOT be tied to a particular communications protocol. Provisions for authenticity, integrity, and confidentiality should be made in FINE..."

• [November 09, 2004] The Incident Object Description Exchange Format (IODEF) Implementation Guide." By Roman Danyliw. IETF INCH Working Group, Internet Draft 'draft-ietf-inch-implement-01'. November 09, 2004. Expires May 10, 2005. I-D Tracker citation. "The Incident Object Description Exchange Format (IODEF) is an abstract data model for representing computer security incidents exchanged by Computer Security Incident Response Teams (CSIRTs). It was designed to satisfy the requirements laid out in '"Requirements for Format for Incident Report Exchange'. Practically, [the draft document 'Intrusion Detection Message Exchange Format'] also provides an XML DTD (soon to be Schema) implementation of the data model. The purpose of this document is to provide additional informati on for IODEF implementers. Section 1 outlines the operational assumptions and context in which the IODEF will be used. Section 2 discusses general issues related to exchanging IODEF documents. The importing and exporting IODEF documents with an IHS is covered in detail in Section 3 and 4, respectively. Section 5 provides useful examples of IODEF usage for given situations..."

• [March 09, 2004] "The Incident Object Description Exchange Format (IODEF) Implementation Guide." By Roman Danyliw (CERT Coordination Center). Reference: IETF Extended Incident Handling Working Group, 'draft-ietf-inch-implement-00.txt'. March 09, 2004, expires September 7, 2004. 19 pages. "The Incident Object Description Exchange Format (IODEF) is an abstract data model for representing computer security incidents exchanged by Computer Security Incident Response Teams (CSIRTs). It was designed to satisfy the requirements presented in "Requirements for Format for Incident Report Exchange". Practically, the IDMEF specification ("Intrusion Detection Message Exchange Format") also provides an XML DTD implementation of the data model; it will soon be expressed in W3C XML Schema notation. The purpose of this document is to provide additional information for IODEF implementers. Section 1 outlines the operational assumptions and context in which the IODEF will be used. Sections 2 discusses general issues related to exchanging IODEF documents. The importing and exporting IODEF documents with an IHS is covered in detail in Section 3 and 4, respectively. Section 5 provides useful examples of IODEF usage for given situations... Integrating the IODEF into a CSIRT requires changing the IHS to import and export IODEF documents. Effectively, this capability involves the ability to convert from the native IHS data format to XML, and vice versa. Since it merely introduces another representation for existing data, the underlying storage mechanism and schema of the IHS need not be changed to accommodate the IODEF. Furthermore, the use of the IODEF as the explicit storage or archive format is not recommended due to the space inefficiency of XML. Importing IODEF documents will allow a CSIRT to rapidly process newly reported incident information since the barriers of the semantics ambiguity and data normalization will not be present. Exporting IODEF documents allows a CSIRT to unambiguously share information with collaborators. This capability becomes especially relevant when coordinating with a CSIRT with whom no prior relationship might exist... In constructing the IODEF data model, certain classes were reused from the IDMEF. Therefore, their description was not included in the specification. Instead referencing the IDMEF specification is required. The relevant portions of the IDMEF DTD were copied outright into the IODEF DTD for completeness..."

• [September 29, 2003] "The Incident Data Exchange Format Data Model and XML Implementation." By Jan Meijer (SURFnet bv), Roman Danyliw (CERT Coordination Center), and Yuri Demchenko (NLnet Labs). Reference: IETF Network Working Group, 'draft-ietf-inch-iodef-02.txt'. September 29, 2003, expires March 29, 2004. 85 pages. "The purpose of the Incident Data Exchange Format (IODEF) is to define data formats for information related to computer security incidents typically exchanged between collaborating Computer Security Incident Response Teams (CSIRTs). This Internet-Draft describes a data model for representing commonly exchanged incident information exported from incident handling systems managed by CSIRTs. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided... Terminology, notation, and conventions of the data model and XML DTD are presented in Sections 2. The data model is described in Section 3, and the implementation considerations are covered in Sections 4 through 6, and 9. Section 7 provides several examples of IODEF documents for representative incidents. Section 8 formally specifies the XML DTD implementation of the data model... The IODEF and the IDMEF are complementary formats. The latter represents data generated by an intrusion detection system. Such event data is commonly used by a CSIRT as the basis for an incident report or investigation which is represented by the IODEF. The IODEF data model makes use of certain classes defined in the IDMEF, although the semantics of some of these classes has changed. Due to their related nature, the data in an IDMEF message can be easily represented in an IODEF document. Through various extension mechanisms, it is possible to include IDMEF messages outright in an IODEF document. Alternatively, the similarity in structure of the data model makes it possible to decompose the key IDMEF data and include it in the corresponding IODEF classes. However, this transformation may not preserve the original semantics of the data... This document uses three notations: the Unified Modeling Language (UML) to describe the data model, an Extensible Markup Language (XML) Document Type Definition (DTD) to define the IODEF syntax, and IODEF XML markup conforming to the specified DTD to represent the incident data..."

• [October 29, 2002] "Incident Object Description and Exchange Format Data Model and Extensible Markup Language (XML) Document Type Definition." By Jan Meijer (SURFnet), Roman Danyliw (CERT Coordination Center), and Yuri Demchenko (Terena). IETF INCH Working Group, Internet-Draft. Reference: 'draft-ietf-inch-iodef-00.txt'. October 29, 2002, expires April 29, 2003. 114 pages, with 19 references. Document built on the work done by the Incident Object Description and Exchange Format Working-Group of the Terena task-force TF-CSIRT. "The purpose of the Incident Object Description and Exchange Format is to define a common data format for describing and exchanging incident information between collaborating Computer Security Incident Response Teams (CSIRTs). The specific goals and requirements of the IODEF are described in ['TERENA's Incident Object Description and Exchange Format Requirements,' RFC 3067, February 2001]. One of the design principles in the IODEF is compatibility with the Intrusion Detection Message Exchange Format (IDMEF) developed for intrusion detection systems. For this reason, IODEF is heavily based on the IDMEF and provides upward compatibility with it. This document describes a data model for representing information produced by incident handling systems managing security incident data, and explains the rationale for using this model. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided..."

• [October, 2002] Incident Object Description and Exchange Format Requirements. Reference: 'draft-ietf-inch-iodef-rfc3067bis-requirements-00.txt'. [cache]

• [February 2001] "TERENA's Incident Object Description and Exchange Format Requirements." By Jimmy Arvidsson (Telia CERT), Andrew Cormack (JANET-CERT), Yuri Demchenko (TERENA), and Jan Meijer (SURFnet). IETF Network Working Group. Informational Request for Comments #3067. February 2001. "This document defines requirements for the Incident object Description and Exchange Format (IODEF), which is the intended product of the Incident Taxonomy Working Group (ITDWG) at TERENA [2]. IODEF is planned to be a standard format which allows CSIRTs to exchange operational and statistical information; it may also provide a basis for the development of compatible and inter-operable tools for Incident recording, tracking and exchange. Another aim is to extend the work of IETF IDWG (currently focused on Intrusion Detection exchange format and communication protocol) to the description of incidents as higher level elements in Network Security. This will involve CSIRTs and their constituency related issues. The IODEF set of documents of which this document is the first will contain IODEF Data Model and XML DTD specification. Further discussion of this document will take place in the ITDWG mailing lists..." [source]

General: Articles, Papers, News, Implementation Reports

• [May 21, 2007] "XML Format for Antiphishing Info to Go Live in July [2007]." By Sandra Rossi. From ComputerWorld (May 21, 2007 ). "A common format to electronically report fraudulent activities will be fully operational by July 2007. Anti-Phishing Working Group (APWG) secretary general, Peter Cassidy, said a structured data model is necessary to improve incident reporting, share information and allow forensic searches and investigations. Cassidy said the first base specification was submitted in June 2005 and the Incident Object Description Exchange Format (IODEF) XML Schema with e-crime relevant extensions will be a recognized IETF standard in about six weeks. He said reporting will be automated with greater ease using a standard schema: "For example, a Korean CERT (Computer Emergency Response Team) reporting an incident can send it to a French bank." To date, 2.5 million records of attacks and 13,500 URLs are added to the database every month. Cassidy said the block list is updated every five minutes and is a 10MB file used as a historical archive, most commonly used by browser developers. Cassidy said the APWG first started collecting data in October 2003. He estimates there are upwards of 50 full-time phishing gangs operating worldwide at any given time. The APWG is also in the process of establishing a Contact System for Abuse Managers. It is currently in beta with 1600 companies. Cassidy said it allows companies to communicate and costs about $21 (U.S.) to enroll..."

• [July 12, 2006] IODEF Interoperability Report." By Brian Trammell. July 12, 2006. Presented at IETF 66 — Montréal, QC, Canada. [cache]

• [November 22, 2002] Implementing the IODEF at the CERT/CC." By Roman Danyliw. Presented at INCH — IETF 55. November 22, 2002. [cache]

• eCSIRT.net: The European CSIRT Network. EU research project funded through the IST programme (New Methods of Work and Electronic Commerce), 6/2002 - 12/2003. IETF IODEF and IDMEF are being implemented on a trial basis. Participants: CERT-POLSKA, Poland; DFN-CERT, Germany; DK-CERT, Denmark; GARR-CERT, Italy; IRIS-CERT, Spain; JANET-CERT, United Kingdom; RENATER, France.