Extended Incident Handling Working Group R. Danyliw Internet-Draft CERT/NetSA Intended status: Standards Track J. Meijer Expires: March 20, 2007 SURFnet bv Y. Demchenko University of Amsterdam September 16, 2006 The Incident Object Description Exchange Format draft-ietf-inch-iodef-10.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 20, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Danyliw, et al. Expires March 20, 2007 [Page 1] Internet-Draft IODEF September 2006 Abstract 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. This document describes the data model for the IODEF and provides the associated XML Schema. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . intro 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . termi 1.2. Notations . . . . . . . . . . . . . . . . . . . . . . . notat 1.3. About the IODEF Data Model . . . . . . . . . . . . . . about 1.4. About the IODEF Implementation . . . . . . . . . . . . about 2. IODEF Data Types . . . . . . . . . . . . . . . . . . . . . iodef 2.1. Integers . . . . . . . . . . . . . . . . . . . . . . . dt_in 2.2. Real Numbers . . . . . . . . . . . . . . . . . . . . . dt_re 2.3. Characters and Strings . . . . . . . . . . . . . . . . dt_ch 2.4. Multilingual Strings . . . . . . . . . . . . . . . . . dt_ml 2.5. Bytes . . . . . . . . . . . . . . . . . . . . . . . . . dt_by 2.6. Hexadecimal Bytes . . . . . . . . . . . . . . . . . . . dt_he 2.7. Enumerated Types . . . . . . . . . . . . . . . . . . . dt_en 2.8. Date-Time Strings . . . . . . . . . . . . . . . . . . . dt_da 2.9. Timezone string . . . . . . . . . . . . . . . . . . . . dt_ti 2.10. Port Lists . . . . . . . . . . . . . . . . . . . . . . dt_po 2.11. Postal Address . . . . . . . . . . . . . . . . . . . . dt_po 2.12. Person or Organization . . . . . . . . . . . . . . . . dt_pe 2.13. Telephone and Fax Numbers . . . . . . . . . . . . . . . dt_ph 2.14. Email string . . . . . . . . . . . . . . . . . . . . . dt_em 2.15. Uniform Resource Locator strings . . . . . . . . . . . dt_ur 3. The IODEF Data Model . . . . . . . . . . . . . . . . . . . datam 3.1. IODEF-Document class . . . . . . . . . . . . . . . . . IODEF 3.2. Incident class . . . . . . . . . . . . . . . . . . . . Incid 3.3. IncidentID class . . . . . . . . . . . . . . . . . . . Incid 3.4. AlternativeID class . . . . . . . . . . . . . . . . . . Alter 3.5. RelatedActivity class . . . . . . . . . . . . . . . . . Relat 3.6. AdditionalData . . . . . . . . . . . . . . . . . . . . Addit 3.7. Contact class . . . . . . . . . . . . . . . . . . . . . conta 3.7.1. RegistryHandle class . . . . . . . . . . . . . . . regis 3.8. Time classes . . . . . . . . . . . . . . . . . . . . . time_ 3.8.1. StartTime . . . . . . . . . . . . . . . . . . . . . Start 3.8.2. EndTime . . . . . . . . . . . . . . . . . . . . . . EndTi 3.8.3. DetectTime . . . . . . . . . . . . . . . . . . . . Detec 3.8.4. ReportTime . . . . . . . . . . . . . . . . . . . . Repor 3.8.5. DateTime . . . . . . . . . . . . . . . . . . . . . DateT 3.9. Method class . . . . . . . . . . . . . . . . . . . . . Metho Danyliw, et al. Expires March 20, 2007 [Page 2] Internet-Draft IODEF September 2006 3.9.1. Reference class . . . . . . . . . . . . . . . . . . Refer 3.10. Assessment class . . . . . . . . . . . . . . . . . . . Asses 3.10.1. Impact class . . . . . . . . . . . . . . . . . . . impac 3.10.2. TimeImpact class . . . . . . . . . . . . . . . . . timei 3.10.3. MonetaryImpact class . . . . . . . . . . . . . . . monet 3.10.4. Confidence class . . . . . . . . . . . . . . . . . confi 3.11. History class . . . . . . . . . . . . . . . . . . . . . Histo 3.11.1. HistoryItem class . . . . . . . . . . . . . . . . . Histo 3.12. EventData class . . . . . . . . . . . . . . . . . . . . Event 3.12.1. Relating the Incident and EventData classes . . . . Incid 3.12.2. Cardinality of EventData . . . . . . . . . . . . . event 3.13. Expectation class . . . . . . . . . . . . . . . . . . . Expec 3.14. Flow class . . . . . . . . . . . . . . . . . . . . . . Flow 3.15. System class . . . . . . . . . . . . . . . . . . . . . Syste 3.16. Node class . . . . . . . . . . . . . . . . . . . . . . Node 3.16.1. Counter class . . . . . . . . . . . . . . . . . . . Count 3.16.2. Address . . . . . . . . . . . . . . . . . . . . . . Addre 3.16.3. NodeRole class . . . . . . . . . . . . . . . . . . NodeR 3.17. Service class . . . . . . . . . . . . . . . . . . . . . Servi 3.17.1. Application class . . . . . . . . . . . . . . . . . Appli 3.18. OperatingSystem class . . . . . . . . . . . . . . . . . Opera 3.19. Record class . . . . . . . . . . . . . . . . . . . . . Recor 3.19.1. RecordData class . . . . . . . . . . . . . . . . . Recor 3.19.2. RecordPattern class . . . . . . . . . . . . . . . . Recor 3.19.3. RecordItem class . . . . . . . . . . . . . . . . . Recor 4. Processing Considerations . . . . . . . . . . . . . . . . . proce 4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . encod 4.2. IODEF Namespace . . . . . . . . . . . . . . . . . . . . ns 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . valid 5. Extending the IODEF . . . . . . . . . . . . . . . . . . . . exten 5.1. Extending the enumerated values of attributes . . . . . exten 5.2. Extending classes . . . . . . . . . . . . . . . . . . . exten 6. Internationalization issues . . . . . . . . . . . . . . . . inter 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . examp 7.1. Worm . . . . . . . . . . . . . . . . . . . . . . . . . ancho 7.2. Reconnaissance . . . . . . . . . . . . . . . . . . . . examp 7.3. Bot-Net Reporting . . . . . . . . . . . . . . . . . . . examp 7.4. Watch List . . . . . . . . . . . . . . . . . . . . . . examp 8. The IODEF Schema . . . . . . . . . . . . . . . . . . . . . schem 9. Security considerations . . . . . . . . . . . . . . . . . . secur 10. IANA considerations . . . . . . . . . . . . . . . . . . . . iana_ 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . ackno 12. References . . . . . . . . . . . . . . . . . . . . . . . . ancho 12.1. Normative References . . . . . . . . . . . . . . . . . ancho 12.2. Informative References . . . . . . . . . . . . . . . . ancho Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 0 Intellectual Property and Copyright Statements . . . . . . . . Danyliw, et al. Expires March 20, 2007 [Page 3] Internet-Draft IODEF September 2006 1. Introduction 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: o increased automation in processing of incident data since the resources of security analysts to parse free-form textual documents will be reduced; o decreased effort in normalizing similar data (even when highly structured) from different sources; and o a common format on which to build interoperable tools for incident handling and subsequent analysis, specifically when data comes from multiple constituencies. Coordinating with other CSIRTs is not strictly a technical problem. There are numerous procedural, trust, and legal considerations that might prevent an organization from sharing information. The IODEF does not attempt to address them. However operational implementations of the IODEF will need to consider this broader context. 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. Processing considerations, the handling of extensions, and internationalization Danyliw, et al. Expires March 20, 2007 [Page 4] Internet-Draft IODEF September 2006 issues related to the data model are covered in Sections 4, 5, and 6 respectively. Examples are listed in Section 7. Section 1 provides the background for the IODEF, and Section 9 documents the security considerations. 1.1. Terminology 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 RFC2119 [6]. Definitions for some of the common computer security-related terminology used in this document can be found in Section 2 of [17]. 1.2. Notations The IODEF is specified in two ways, as an abstract data model and as an XML Schema. Section 3 provides a Unified Modeling Language (UML) model describing the individual classes and their relationship with each other. The semantics of each class are discussed and their attributes explained. In Section 8, this UML model is converted in an XML Schema. For clarity in this document, the term "XML document" will be used when referring generically to any instance of an XML document. The term "IODEF document" will be used to refer to specific elements and attributes of the IODEF schema. Finally, the terms "class", and "element" will be used interchangeably to reference either a given UML class in the data model or its corresponding schema implementation. 1.3. About the IODEF Data Model The IODEF data model is a data representation that provides a framework for sharing information commonly exchanged by CSIRTs about computer security incidents. A number of considerations were made in the design of the data model. o The data model serves as a transport format. Therefore, its specific representation is not the optimal representation for on- disk storage, long-term archiving, or in-memory processing. o As there is no precise, widely agreed upon definition for an incident, the data model does not attempt to dictate one through its implementation. Rather, a broad understanding is assumed in the IODEF that is flexible enough to encompass most operators. Danyliw, et al. Expires March 20, 2007 [Page 5] Internet-Draft IODEF September 2006 o Describing an incident for all definitions would require an extremely complex data model. Therefore, the IODEF only intends to be a framework to convey commonly exchanged incident information. It ensures that there are ample mechanisms for extensibility to support organization-specific information, and techniques to reference information kept outside of the explicit data model. o The domain of security analysis is not fully standardized and must rely on free-form textual descriptions. The IODEF attempts to strike a balance between supporting this free-form content, while still allowing automated processing of incident information. o 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 [18] influenced the design of the IODEF. Further discussion of the desirable properties for the IODEF can be found in the Requirements for the Format for Incident Information Exchange (FINE) [17]. 1.4. About the IODEF Implementation The IODEF implementation is specified as an Extensible Markup Language (XML) [1] Schema [2] in Section 8. 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. However, XML is fundamentally a text representation which makes it inherently inefficient when binary data must be embedded or large volumes of data must be exchanged. Danyliw, et al. Expires March 20, 2007 [Page 6] Internet-Draft IODEF September 2006 2. IODEF Data Types The various data elements of the IODEF data model are typed. This section discusses these data types. When possible, these types are enforced in the XML Schema. 2.1. Integers An integer is represented by the INTEGER data type. Integer data MUST be encoded in Base 10. The INTEGER data type is implemented as an "xs:integer" [3] in the schema. 2.2. Real Numbers Real (floating-point) attributes are represented by the REAL data type. Real data MUST be encoded in Base 10. The REAL data type is implemented as an "xs:float" [3] in the schema. 2.3. Characters and Strings A single character is represented by the CHARACTER data type. A character string is represented by the STRING data type. Special characters must be encoded using entity references. See Section 4.1. The CHARACTER and STRING data types are implement as an "xs:string" [3] in the schema. 2.4. Multilingual Strings STRING data that represents multi-character attributes in a language different than the default encoding of the document are of the ML_STRING data type. The ML_STRING data type is implemented as an "iodef:MLStringType" in the schema. 2.5. Bytes A binary octet is represented by the BYTE data type. A sequence of binary octets is represented by the BYTE[] data type. These octets are encoded using base64. The BYTE data type is implemented as an "xs:base64Binary" [3] in the schema. Danyliw, et al. Expires March 20, 2007 [Page 7] Internet-Draft IODEF September 2006 2.6. Hexadecimal Bytes A binary octet is represented by the HEXBIN (and HEXBIN[]) data type. This octet is encoded as a character tuple consisting of two hexadecimal digits. The HEXBIN data type is implemented as an "xs:hexBinary" [3] in the schema. 2.7. Enumerated Types Enumerated types are represented by the ENUM data type, and consist of an ordered list of acceptable values. Each value has a representative keyword. Within the IODEF schema, the enumerated type keywords are used as attribute values. The ENUM data type is implemented as a series of "xs:NMTOKEN" in the schema. 2.8. Date-Time Strings Date-time strings are represented by the DATETIME data type. Each date-time string identifies a particular instant in time; ranges are not supported. Date-time strings are formatted according to a subset of ISO 8601: 2000 [14] documented in RFC 3339 [13]. The DATETIME data type is implemented as an "xs:dateTime" [3] in the schema. 2.9. Timezone string A timezone offset from UTC is represented by the TIMEZONE data type. It is formatted according to the following regular expression: "Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]". The TIMEZONE data type is implemented as an "xs:string" with a regular expression constraint in the schema. This regular expression is identical to the timezone representation implemented in an "xs: dateTime". 2.10. Port Lists A list of network ports are represented by the PORTLIST data type. A PORTLIST consists of a comma-separated list of numbers and ranges (N-M means ports N through M, inclusive). It is formatted according to the following regular expression: "\d+(\-\d+)?(,\d+(\-\d+)?)*". Danyliw, et al. Expires March 20, 2007 [Page 8] Internet-Draft IODEF September 2006 For example, "2,5-15,30,32,40-50,55-60". The PORTLIST data type is implemented as an "xs:string" with a regular expression constraint in the schema. 2.11. Postal Address A postal address is represented by the POSTAL data type. This data type is a ML_STRING whose format is documented in Sections 6.27 of RFC 2252 [11]. It defines a postal address as a free-form multi-line string separated by the "$" character. The POSTAL data type is implemented as an "xs:string" in the schema. 2.12. Person or Organization The name of an individual or organization is represented by the NAME data type. This data type is an ML_STRING whose format is documented in Section 5.4 of RFC 2256 [10]. The NAME data type is implemented as an "xs:string" in the schema. 2.13. Telephone and Fax Numbers A telephone number is represented by the PHONE data type. The format of the PHONE data type is documented in Section 6.30 of RFC 2252 [10]. The PHONE data type is implemented as an "xs:string" in the schema. 2.14. Email string An email address is represented by the EMAIL data type. The format of the EMAIL data type is documented in Section 3.4.1 RFC 2822 [12] The EMAIL data type is implemented as an "xs:string" in the schema. 2.15. Uniform Resource Locator strings A uniform resource locator (URL is represented by the URL data type. The format of the URL data type is documented in RFC 2396 [8]. The URL data type is implemented as an "xs:anyURI" in the schema. Danyliw, et al. Expires March 20, 2007 [Page 9] Internet-Draft IODEF September 2006 3. The IODEF Data Model In this section, the individual components of the IODEF data model will be discussed in detail. For each class, the semantics will be described and the relationship with other classes will be depicted with UML. When necessary, specific comments will be made about corresponding definition in the schema in Section 8 3.1. IODEF-Document class The IODEF-Document class is the top level class in the IODEF data model. All IODEF documents are an instance of this class. +-----------------+ | IODEF-Document | +-----------------+ | STRING version |<>--{1..*}--[ Incident ] | ENUM lang | | STRING formatid | +-----------------+ Figure 1: IODEF-Document class The aggregate class that constitute IODEF-Document is: Incident One or more. The information related to a single incident. The IODEF-Document class has three attributes: version Required. STRING. The IODEF specification version number to which this IODEF document conforms. The value of this attribute MUST be "1.00" lang Required. ENUM. A valid language code per RFC 3066 [7] constrained by the definition of "xs:language". The interpretation of this code is described in Section 6. formatid Optional. STRING. A free-form string to convey processing instructions to the recipient of the document. Its semantics must be negotiated out-of-band. Danyliw, et al. Expires March 20, 2007 [Page 10] Internet-Draft IODEF September 2006 3.2. Incident class Every incident is represented by an instance of the Incident class. This class provides a standardized representation for commonly exchanged incident data. +--------------------+ | Incident | +--------------------+ | ENUM purpose |<>----------[ IncidentID ] | STRING ext-purpose |<>--{0..1}--[ AlternativeID ] | ENUM lang |<>--{0..1}--[ RelatedActivity ] | ENUM restriction |<>--{0..1}--[ DetectTime ] | |<>--{0..1}--[ StartTime ] | |<>--{0..1}--[ EndTime ] | |<>----------[ ReportTime ] | |<>--{0..*}--[ Description ] | |<>--{1..*}--[ Assessment ] | |<>--{0..*}--[ Method ] | |<>--{1..*}--[ Contact ] | |<>--{0..*}--[ EventData ] | |<>--{0..1}--[ History ] | |<>--{0..*}--[ AdditionalData ] +--------------------+ Figure 2: the Incident class The aggregate classes that constitute Incident are: IncidentID One. An incident tracking number assigned to this incident by the CSIRT that generated the IODEF document. AlternativeID Zero or one. The incident tracking numbers used by other CSIRTs to refer to the incident described in the document. RelatedActivity Zero or one. The incident tracking numbers of related incidents. DetectTime Zero or one. The time the incident was first detected. StartTime Zero or one. The time the incident started. Danyliw, et al. Expires March 20, 2007 [Page 11] Internet-Draft IODEF September 2006 EndTime Zero or one. The time the incident ended. ReportTime One. The time the incident was reported. Description Zero or more. ML_STRING. A free-form textual description of the incident. Assessment One or more. A characterization of the impact of the incident. Method Zero or more. The techniques used by the intruder in the incident. Contact One or more. Contact information for the parties involved in the incident. EventData Zero or more. Description of the events comprising the incident, History Zero or one. A log of significant events or actions that occurred during the course of handling the incident. AdditionalData Zero or more. Mechanism by which to extend the data model. The Incident class has four attributes: purpose Required. ENUM. The purpose attribute represents the reason why the IODEF document was created. It is closely related to the Expectation class (Section 3.13). This attribute is defined as an enumerated list: 1. traceback. The document was sent for trace-back purposes; 2. mitigation. The document was sent to request aid in mitigating the described activity; 3. reporting. The document was sent to comply with reporting requirements; Danyliw, et al. Expires March 20, 2007 [Page 12] Internet-Draft IODEF September 2006 4. other. The document was sent for purposes specified in the Expectation class. 5. ext-value. An escape value used to extend this attribute. See Section 5.1. ext-purpose Optional. STRING. A means by which to extend the purpose attribute. See Section 5.1. lang Optional. ENUM. A valid language code per RFC 3066 [7] constrained by the definition of "xs:language". The interpretation of this code is described in Section 6. restriction Optional. ENUM. This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere. This guideline provides no real security since it is the choice of the recipient of the document to honor it. The value of this attribute is logically inherited by the children of this class. That is to say, the disclosure rules applied to this class, also apply to its children. It is possible to set a granular disclosure policy, since all of the high-level classes (i.e., children of the Incident class) have a restriction attribute. Therefore, a child can override the guidelines of a parent class, be it to restrict or relax the disclosure rules (e.g., a child has a weaker policy than an ancestor; or an ancestor has a weak policy, and the children selectively apply more rigid controls). The implicit value of the restriction attribute for a class that did not specify one can be found in the closest ancestor that did specify a value. This attribute is defined as an enumerated value with a default value of "private". Note that the default value of the restriction attribute is only defined in the context of the Incident class. In other classes where this attribute is used, no default is specified. 1. public. There are no restrictions placed in the information; 2. need-to-know. The information may be shared with other parties that are involved in the incident (e.g., multiple victim sites can be informed of each other); Danyliw, et al. Expires March 20, 2007 [Page 13] Internet-Draft IODEF September 2006 3. private. The information may not be shared. 4. default. The information can be shared according to an information disclosure policy pre-arranged by the communicating parties. 3.3. IncidentID class The IncidentID class represents an incident tracking number that is unique in the context of the CSIRT and identifies the activity characterized in an IODEF Document. This identifier would serve as an index into the CSIRT incident handling system. The combination of the name attribute and the string in the element content MUST be a globally unique identifier describing the activity. Documents generated by a given CSIRT MUST NOT reuse the same value unless they are referencing the same incident. +------------------+ | IncidentID | +------------------+ | STRING | | | | STRING name | | STRING instance | +------------------+ Figure 3: the IncidentID class The IncidentID class has two attributes: name Required. STRING. An identifier describing the CSIRT that created the document. In order to have a globally unique CSIRT name, the fully qualified domain name associated with the CSIRT MUST be used. instance Optional. STRING. An identifier referencing a subset of the named incident. 3.4. AlternativeID class The AlternativeID class lists the incident tracking numbers used by CSIRTs, other than the one generating the document, to refer to the identical activity described the IODEF document. A tracking number listed as an AlternativeID references the same incident detected by another CSIRT. The incident tracking numbers of the CSIRT that Danyliw, et al. Expires March 20, 2007 [Page 14] Internet-Draft IODEF September 2006 generated the IODEF document should never be considered an AlternativeID. +------------------+ | AlternativeID | +------------------+ | ENUM restriction |<>--{1..*}--[ IncidentID ] | | +------------------+ Figure 4: the AlternativeID class The aggregate class that constitutes AlternativeID is: IncidentID One or more. The incident tracking number of another CSIRT. The AlternativeID class has one attribute: restriction Optional. ENUM. This attribute has been defined in Section 3.2. 3.5. RelatedActivity class The RelatedActivity class lists either incident tracking numbers of incidents or URLs (not both) that refer to activity related to the one described in the IODEF document. These references may be to local incident tracking numbers or to those of other CSIRTs. The specifics of how a CSIRT comes to believe that two incidents are related are considered out of scope. +------------------+ | RelatedActivity | +------------------+ | ENUM restriction |<>--{1..*}--[ IncidentID ] | |<>--{1..*}--[ URL ] +------------------+ Figure 5: RelatedActivity class The aggregate classes that constitutes RelatedActivity are: Danyliw, et al. Expires March 20, 2007 [Page 15] Internet-Draft IODEF September 2006 IncidentID One or more. The incident tracking number of a related incident. URL One or more. URL. A URL to activity related to this incident. The RelatedActivity class has one attribute: restriction Optional. ENUM. This attribute has been defined in Section 3.2. 3.6. AdditionalData The AdditionalData class serves as an extension mechanism for information not otherwise represented in the data model. For relatively simple information, atomic data types (e.g., integers, strings) are provided with a mechanism to annotate their meaning. The class can also be used to extend the data model (and the associated Schema) to support proprietary extensions by encapsulating entire XML documents conforming to another Schema (e.g., IDMEF). A detailed discussion for extending the data model and the schema can be found in Section 5. Unlike XML, which is self-describing, atomic data must be documented to convey its meaning. This information is described in the 'meaning' attribute. Since these description are outside the scope of the specification, some additional coordination may be required to ensure that a recipient of a document using the AdditionalData classes can make sense of the custom extensions. +------------------+ | AdditionalData | +------------------+ | ANY | | | | ENUM dtype | | STRING ext-dtype | | STRING meaning | | STRING formatid | | ENUM restriction | +------------------+ Figure 6: the AdditionalData class The AdditionalData class has five attributes: Danyliw, et al. Expires March 20, 2007 [Page 16] Internet-Draft IODEF September 2006 dtype Required. ENUM. The data type of the element content. The permitted values for this attribute are shown below. The default value is "string". 1. boolean. The element content is of type BOOLEAN. 2. byte. The element content is of type BYTE. 3. character. The element content is of type CHARACTER. 4. date-time. The element content is of type DATETIME. 5. integer. The element content is of type INTEGER. 6. portlist. The element content is of type PORTLIST. 7. real. The element content is of type REAL. 8. string. The element content is of type STRING. 9. file. The element content is a base64 encoded binary file encoded as a BYTE[] type. 10. frame. The element content is a layer-2 frame encoded as a HEXBIN type. 11. packet. The element content is a layer-3 packet encoded as a HEXBIN type. 12. ipv4-packet. The element content is an IPv4 packet encoded as a HEXBIN type. 13. ipv6-packet. The element content is an IPv6 packet encoded as a HEXBIN type. 14. path. The element content is a file-system path encoded as a STRING type; 15. url. The element content is of type URL. 16. csv. The element content is a common separated value list encoded as a STRING type. 17. winreg. The element content is a Windows registry key encoded as a STRING type. Danyliw, et al. Expires March 20, 2007 [Page 17] Internet-Draft IODEF September 2006 18. xml. The element content is XML (see Section 5). 19. ext-value. An escape value used to extend this attribute. See Section 5.1. ext-dtype Optional. STRING. A means by which to extend the dtype attribute. See Section 5.1. meaning Optional. STRING. A free-form description of the element content. formatid Optional. STRING. An identifier referencing the format and semantics of the element content. restriction Optional. ENUM. This attribute has been defined in Section 3.2. 3.7. Contact class The Contact class describes contact information for organizations and personnel involved in the incident. This class allows for the naming of the involved party, specifying contact information for them, and identifying their role in the incident. People and organizations are treated interchangeably as contacts; one can be associated with the other using the recursive definition of the class (the Contact class is aggregated into the Contact class). The 'type' attribute disambiguates the type of contact information being provided. This recursive definition provides a way to relate information without requiring the explicit use of identifiers in the classes. For example, separate contact information for two individuals from the same organization would not require duplicating the organization information. Danyliw, et al. Expires March 20, 2007 [Page 18] Internet-Draft IODEF September 2006 +------------------+ | Contact | +------------------+ | ENUM role |<>--{0..1}--[ ContactName ] | STRING ext-role |<>--{0..*}--[ Description ] | ENUM type |<>--{0..*}--[ RegistryHandle ] | STRING ext-type |<>--{0..1}--[ PostalAddress ] | ENUM restriction |<>--{0..*}--[ Email ] | |<>--{0..*}--[ Telephone ] | |<>--{0..1}--[ Fax ] | |<>--{0..1}--[ Timezone ] | |<>--{0..*}--[ Contact ] | |<>--{0..*}?-[ AdditionalData ] +------------------+ Figure 7: the Contact class The aggregate classes that constitute the Contact class are: ContactName Zero or one. ML_STRING. The name of the contact. The contact may either be an organization or a person. The type attribute disambiguates the semantics. Description Zero or many. ML_STRING. A free-form description of this contact. In the case of a person, this is often the organizational title of the individual. RegistryHandle Zero or many. A handle name into the registry of the contact. PostalAddress Zero or one. POSTAL. The postal address of the contact formatted according to Section 2.11. Email Zero or many. EMAIL. The email address of the contact formatted according to Section 2.14. Telephone Zero or many. PHONE. The telephone number of the contact formatted according to Section 2.13. Fax Zero or one. PHONE. The facsimile telephone number of the contact formatted according to Section 2.13. Danyliw, et al. Expires March 20, 2007 [Page 19] Internet-Draft IODEF September 2006 Timezone Zero or one. TIMEZONE. The timezone in which the contact resides formatted according to Section 2.9. Contact Zero or many. A Contact instance contained within another Contact instance inherits the values of the parent(s). This recursive definition can be used to group common data pertaining to multiple points of contact and is especially useful when listing multiple contacts at the same organization. When Contact elements are defined recursively, only the leaf instances (those Contact instances not containing other Contact instances) represent actual points of contact. AdditionalData Zero or many. A mechanism by which to extend the data model. At least one of the aggregate classes MUST be present in an instance of the Contact class. This is not enforced in the IODEF schema as there is no simple way to accomplish it. The Contact class has five attributes: role Required. ENUM. Indicates the role the contact fulfills. This attribute is defined as an enumerated list: 1. creator. The entity that generate the document. 2. admin. An administrative contact for a host or network. 3. tech. A technical contact for a host or network. 4. irt. The CSIRT involved in handling the incident. 5. cc. An entity that is to be kept informed about the handling of the incident. 6. ext-value. An escape value used to extend this attribute. See Section 5.1. ext-role Optional. STRING. A means by which to extend the role attribute. See Section 5.1. Danyliw, et al. Expires March 20, 2007 [Page 20] Internet-Draft IODEF September 2006 type Required. ENUM. Indicates the type of contact being described. This attribute is defined as an enumerated list: 1. person. The information for this contact references an individual. 2. organization. The information for this contact references an organization. 3. ext-value. An escape value used to extend this attribute. See Section 5.1. ext-type Optional. STRING. A means by which to extend the type attribute. See Section 5.1. restriction Optional. ENUM. This attribute is defined in Section 3.2. 3.7.1. RegistryHandle class The RegistryHandle class represents a handle into an Internet registry or community-specific database. The handle is specified in the element content and the type attribute specifies the database. +---------------------+ | RegistryHandle | +---------------------+ | STRING | | | | ENUM registry | | STRING ext-registry | +---------------------+ Figure 8: The RegistryHandle class The RegistryHandle class has one attribute: registry Required. ENUM. The database to which the handle belongs. The default value is 'local'. The possible values are: 1. internic. Internet Network Information Center 2. apnic. Asia Pacific Network Information Center Danyliw, et al. Expires March 20, 2007 [Page 21] Internet-Draft IODEF September 2006 3. arin. American Registry for Internet Numbers 4. lacnic. Regional Latin-American and Caribbean IP Address Registry 5. ripe. Reseaux IP Europeens 6. afrinic. African Internet Numbers Registry 7. local. A database local to the CSIRT. 8. ext-value. An escape value used to extend this attribute. See Section 5.1. ext-registry Optional. STRING. A means by which to extend the registry attribute. See Section 5.1. 3.8. Time classes The data model uses five different classes to represent a timestamp. Their definition is identical, but each has a distinct name to convey a difference in semantics. The element content of each class is a timestamp formatted according to the DATETIME data type (see Section 2.8). +----------------------------------+ | {Start| End| Report| Detect}Time | +----------------------------------+ | DATETIME | +----------------------------------+ Figure 9: the Time classes 3.8.1. StartTime The StartTime class represents the time the incident began. 3.8.2. EndTime The EndTime class represents the time the incident ended. 3.8.3. DetectTime The DetectTime class represents the time the first activity of the incident was detected. Danyliw, et al. Expires March 20, 2007 [Page 22] Internet-Draft IODEF September 2006 3.8.4. ReportTime The ReportTime class represents the time the incident was reported. This timestamp SHOULD coincide to the time at which the IODEF document is generated. 3.8.5. DateTime The DateTime class is a generic representation of a timestamp. Its semantics should be inferred from the parent class in which it is aggregated. 3.9. Method class The Method class describes the methodology used by the intruder to perpetrate the events of the incident. This class consists of a list of references describing the attack method and a free form description of the technique. +------------------+ | Method | +------------------+ | ENUM restriction |<>--{0..*}--[ Reference ] | |<>--{0..*}--[ Description ] | |<>--{0..*}--[ AdditionalData ] +------------------+ Figure 10: The Method class The Method class is composed of two aggregate classes. Reference Zero or many. A reference to a vulnerability, malware sample, advisory, or analysis of an attack technique. Description Zero or many. ML_STRING. A free-form text description of the methodology used by the intruder. AdditionalData Zero or many. A mechanism by which to extend the data model. Either an instance of the Reference or Description class MUST be present. The Method class has one attribute: Danyliw, et al. Expires March 20, 2007 [Page 23] Internet-Draft IODEF September 2006 restriction Optional. ENUM. This attribute is defined in Section 3.2. 3.9.1. Reference class The Reference class is a reference to a vulnerability, IDS alert, malware sample, advisory, or attack technique. A reference consists of a name, a URL to this reference, and an optional description. +------------------+ | Reference | +------------------+ | |<>----------[ ReferenceName ] | |<>--{0..*}--[ URL ] | |<>--{0..*}--[ Description ] +------------------+ Figure 11: The Reference class The aggregate classes that constitute Reference: ReferenceName One. ML_STRING. Name of the reference. URL Zero or many. URL. A URL associated with the reference. Description Zero or many. ML_STRING. A free-form text description of this reference. 3.10. Assessment class The Assessment class describes the technical and non-technical repercussions of the incident on the CSIRT's constituency. This class was derived from the IDMEF[18]. Danyliw, et al. Expires March 20, 2007 [Page 24] Internet-Draft IODEF September 2006 +------------------+ | Assessment | +------------------+ | ENUM restriction |<>--{0..*}--[ Impact ] | |<>--{0..*}--[ TimeImpact ] | |<>--{0..*}--[ MonetaryImpact ] | |<>--{0..1}--[ Confidence ] | |<>--{0..*}--[ AdditionalData ] +------------------+ Figure 12: Assessment class The aggregate classes that constitute Assessment are: Impact Zero or many. Technical impact of the incident on a network. TimeImpact Zero or many. Impact of the activity measured with respect to time. MonetaryImpact Zero or many. Impact of the activity measured with respect to financial loss. Confidence Zero or one. An estimate of confidence in the assessment. AdditionalData Zero or many. A mechanism by which to extend the data model. A least one instance of the possible three impact classes (i.e., Impact, TimeImpact, or MonetaryImpact) MUST be present. The Assessment class has one attribute: restriction Optional. ENUM. This attribute is defined in Section 3.2. 3.10.1. Impact class The Impact class allows for categorizing and describing the technical impact of the incident on the network of an organization. This class is based on the IDMEF [18]. Danyliw, et al. Expires March 20, 2007 [Page 25] Internet-Draft IODEF September 2006 +------------------+ | Impact | +------------------+ | ML_STRING | | | | STRING lang | | ENUM severity | | ENUM completion | | ENUM type | | STRING ext-type | +------------------+ Figure 13: Impact class The element content will be a free-form textual description of the impact. The Impact class has three attributes: lang Required. ENUM. A valid language code per RFC 3066 [7] constrained by the definition of "xs:language". The interpretation of this code is described in Section 6. severity Optional. ENUM. An estimate of the relative severity of the activity. The permitted values are shown below. There is no default value. 1. low. Low severity 2. medium. Medium severity 3. high. High severity completion Optional. ENUM. An indication whether the described activity was successful. The permitted values are shown below. There is no default value. 1. failed. The attempted activity was not successful. 2. succeeded. The attempted activity succeeded. Danyliw, et al. Expires March 20, 2007 [Page 26] Internet-Draft IODEF September 2006 type Required. ENUM. Classifies the malicious activity into incident categories. The permitted values are shown below. The default value is "other". 1. admin. Administrative privileges were attempted. 2. dos. A denial of service was attempted. 3. file. An action that impacts the integrity of a file or database was attempted. 4. info-leak. An attempt was made to exfiltrate information. 5. misconfiguration. An attempt was made to exploit a mis- configuration in a system. 6. policy. Activity violating site's policy was attempted 7. recon. Reconnaissance activity was attempted. 8. social-engineering. A social engineering attack was attempted. 9. user. User privileges were attempted. 10. unknown. The classification of this activity is unknown. 11. ext-value. An escape value used to extend this attribute. See Section 5.1. ext-type Optional. STRING. A means by which to extend the type attribute. See Section 5.1. 3.10.2. TimeImpact class The TimeImpact class describes the impact of the incident on an organization as a function of time. It provides a way to convey down time and recovery time. Danyliw, et al. Expires March 20, 2007 [Page 27] Internet-Draft IODEF September 2006 +---------------------+ | TimeImpact | +---------------------+ | REAL | | | | ENUM severity | | ENUM metric | | STRING ext-metric | | ENUM duration | | STRING ext-duration | +---------------------+ Figure 14: TimeImpact class The element content is a positive, floating point (REAL) number specifying a unit of time. The duration and metric attributes will imply the semantics of the element content. The TimeImpact class has three attributes: severity Optional. ENUM. An estimate of the relative severity of the activity. The permitted values are shown below. There is no default value. 1. low. Low severity 2. medium. Medium severity 3. high. High severity metric Required. ENUM. Defines the metric in which the time is expressed. The permitted values are shown below. There is no default value. 1. labor. Total staff-time to recovery from the activity (e.g., 2 employees working 4 hours each would be 8 hours). 2. elapsed. Elapsed time from the beginning of the recovery to its completion (i.e., wall-clock time). 3. downtime. Duration of time for which some provided service(s) was not available. 4. ext-value. An escape value used to extend this attribute. See Section 5.1. Danyliw, et al. Expires March 20, 2007 [Page 28] Internet-Draft IODEF September 2006 ext-metric Optional. STRING. A means by which to extend the metric attribute. See Section 5.1. duration Required. ENUM. Defines a unit of time, that when combined with the metric attribute, fully describes a metric of impact that will be conveyed in the element content. The permitted values are shown below. The default value is "hour". 1. second. The unit of the element content is seconds. 2. minute. The unit of the element content is minutes. 3. hour. The unit of the element content is hours. 4. day. The unit of the element content is days. 5. month. The unit of the element content is months. 6. quarter. The unit of the element content is quarters. 7. year. The unit of the element content is years. 8. ext-value. An escape value used to extend this attribute. See Section 5.1. ext-duration Optional. STRING. A means by which to extend the duration attribute. See Section 5.1. 3.10.3. MonetaryImpact class The MonetaryImpact class describes the financial impact of the activity on an organization. For example, this impact may consider losses due to the cost of the investigation or recovery, diminished productivity of the staff, or a tarnished reputation that will affect future opportunities. Danyliw, et al. Expires March 20, 2007 [Page 29] Internet-Draft IODEF September 2006 +------------------+ | MonetaryImpact | +------------------+ | REAL | | | | ENUM severity | | STRING currency | +------------------+ Figure 15: MonetaryImpact class The element content is a positive, floating point number (REAL) specifying a unit of currency described in the currency attribute. The MonetaryImpact class has two attributes: severity Optional. ENUM. An estimate of the relative severity of the activity. The permitted values are shown below. There is no default value. 1. low. Low severity 2. medium. Medium severity 3. high. High severity currency Required. STRING. Defines the currency in which the monetary impact is expressed. The permitted values are defined in ISO 4217:2001, Codes for the representation of currencies and funds [15]. There is no default value. 3.10.4. Confidence class The Confidence class represents a best estimate of the validity and accuracy of the described impact (see Section 3.10) of the incident activity. This estimate can be expressed as a category or a numeric calculation. This class if based upon the IDMEF [18]). Danyliw, et al. Expires March 20, 2007 [Page 30] Internet-Draft IODEF September 2006 +------------------+ | Confidence | +------------------+ | REAL | | | | ENUM rating | +------------------+ Figure 16: Confidence class The element content expresses a numerical assessment in the confidence of the data when the value of the rating attribute is "numeric". Otherwise, this element should be empty. The Confidence class has one attribute. rating Required. ENUM. A rating of the analytical validity of the specified Assessment. The permitted values are shown below. There is no default value. 1. low. Low confidence in the validity. 2. medium. Medium confidence in the validity. 3. high. High confidence in the validity. 4. numeric. The element content contains a number that conveys the confidence of the data. The semantics of this number outside the scope of this specification. 3.11. History class The History class is a log of the significant events or actions performed by the involved parties during the course of handling the incident. The level of detail maintained in this log is left up to the discretion of those handling the incident. +------------------+ | History | +------------------+ | ENUM restriction |<>--{1..*}--[ HistoryItem ] | | +------------------+ Danyliw, et al. Expires March 20, 2007 [Page 31] Internet-Draft IODEF September 2006 Figure 17: The History class The class that constitutes History is: HistoryItem One or many. Entry in the history log of significant events or actions performed by the involved parties. The History class has one attribute: restriction Optional. ENUM. This attribute is defined in Section 3.2. 3.11.1. HistoryItem class The HistoryItem class is an entry in the History (Section 3.11) log that documents a particular action or event that occurred in the course of handling the incident. The details of the entry are a free-form description, but each can be categorized with the type attribute. +-------------------+ | HistoryItem | +-------------------+ | ENUM restriction |<>----------[ DateTime ] | ENUM action |<>--{0..1}--[ IncidentId ] | STRING ext-action |<>--{0..1}--[ Contact ] | STRING ext-action |<>--{0..*}--[ Description ] | |<>--{0..*}--[ AdditionalData ] +-------------------+ Figure 18: HistoryItem class The aggregate classes that constitute HistoryItem are: DateTime One. Timestamp of this entry in the history log (e.g., when the action described in the Description was taken). IncidentID Zero or One. In a history log created by multiple parties, the IncidentID provides a mechanism to specify which CSIRT created a particular entry and references this organization's incident tracking number. When a single organization is maintaining the log, this class can be ignored. Danyliw, et al. Expires March 20, 2007 [Page 32] Internet-Draft IODEF September 2006 Contact Zero or One. Provides contact information for the person that performed the action documented in this class. Description Zero or many. ML_STRING. A free-form textual description of the action or event. AdditionalData Zero or many. A mechanism by which to extend the data model. The HistoryItem class has three attributes: restriction Optional. ENUM. This attribute has been defined in Section 3.2. action Required. ENUM. Classifies a performed action or occurrence documented in this history log entry. As activity will likely have been instigated either through a previously conveyed expectation or internal investigation, this attribute is identical to category attribute of the Expectation class. The difference is only one of tense. When an action is in this class, it has been completed. See Section 3.13. ext-action Optional. STRING. A means by which to extend the action attribute. See Section 5.1. 3.12. EventData class The EventData class describes a particular event of the incident for a given set of hosts or networks. This description includes the systems from which the activity originated and those targeted, an assessment of the techniques used by the intruder, the impact of the activity on the organization, and any forensic evidence discovered. Danyliw, et al. Expires March 20, 2007 [Page 33] Internet-Draft IODEF September 2006 +------------------+ | EventData | +------------------+ | ENUM restriction |<>--{0..*}--[ Description ] | |<>--{0..1}--[ DetectTime ] | |<>--{0..1}--[ StartTime ] | |<>--{0..1}--[ EndTime ] | |<>--{0..*}--[ Contact ] | |<>--{0..1}--[ Assessment ] | |<>--{0..*}--[ Method ] | |<>--{0..*}--[ Flow ] | |<>--{0..*}--[ Expectation ] | |<>--{0..1}--[ Record ] | |<>--{0..*}--[ EventData ] | |<>--{0..*}--[ AdditionalData ] +------------------+ Figure 19: The EventData class The aggregate classes that constitute EventData are: Description Zero or more. ML_STRING. A free-form textual description of the event. DetectTime Zero or one. The time the event was detected. StartTime Zero or one. The time the event started. EndTime Zero or one. The time the event ended. Contact Zero or more. Contact information for the parties involved in the event. Assessment Zero or one. The impact of the event on the target and the actions taken. Method Zero or more. The technique used by the intruder in the event. Danyliw, et al. Expires March 20, 2007 [Page 34] Internet-Draft IODEF September 2006 Flow Zero or more. A description of the systems or networks involved. Expectation Zero or more. The expected action to be performed by the recipient for the described event. Record Zero or one. Supportive data (e.g., log files) that provides additional information about the event. EventData Zero or more. EventData instances contained within another EventData instance inherit the values of the parent(s); this recursive definition can be used to group common data pertaining to multiple events. When EventData elements are defined recursively, only the leaf instances (those EventData instances not containing other EventData instances) represent actual events. AdditionalData Zero or more. An extension mechanism for data not explicitly represented in the data model. At least one of the aggregate classes MUST be present in an instance of the EventData class. This is not enforced in the IODEF schema as there is no simple way to accomplish it. The EventData class has one attribute: restriction Optional. ENUM. This attribute is defined in Section 3.2. 3.12.1. Relating the Incident and EventData classes There is substantial overlap in the Incident and EventData classes. Nevertheless, the semantics of these classes are quite different. The Incident class provides summary information about the entire incident, while the EventData class provides information about the individual events comprising the incident. In the most common case, the EventData class will provide more specific information for the general description provided in the Incident class. However, it may also be possible that the overall summarized information about the incident conflicts with some individual information in an EventData class when there is a substantial composition of various events in the incident. In such as case, the interpretation of the more specific EventData MUST supersede the more generic information provided in IncidentData. Danyliw, et al. Expires March 20, 2007 [Page 35] Internet-Draft IODEF September 2006 3.12.2. Cardinality of EventData The EventData class can be thought of as a container for the properties of an event in an incident. These properties include: the hosts involved, impact of the incident activity on the hosts, forensic logs, etc. With an instance of the EventData class, hosts (i.e., System class) are grouped around these common properties. The recursive definition (or instance property inheritance) of the EventData class (the EventData class is aggregated into the EventData class) provides a way to related information without requiring the explicit use of unique attribute identifiers in the classes or duplicating information. Instead, the relative depth (nesting) of a class is used to group (relate) information. For example, an EventData class might be used to describe two machines involved in an incident. This description can be achieved using multiple instances of the Flow class. It happens that there is a common technical contact (i.e., Contact class) for these two machines, but the impact (i.e., Assessment class) on them is different. A depiction of the representation for this situation can be found in Figure 20. +------------------+ | EventData | +------------------+ | |<>----[ Contact ] | | | |<>----[ EventData ]<>----[ Flow ] | | [ ]<>----[ Assessment ] | | | |<>----[ EventData ]<>----[ Flow ] | | [ ]<>----[ Assessment ] +------------------+ Figure 20: Recursion in the EventData class 3.13. Expectation class The Expectation class conveys to the recipient of the IODEF document the actions the sender is requesting. The scope of the requested action is limited to purview of the EventData class in which this class is aggregated. Danyliw, et al. Expires March 20, 2007 [Page 36] Internet-Draft IODEF September 2006 +-------------------+ | Expectation | +-------------------+ | ENUM restriction |<>--{0..*}--[ Description ] | ENUM severity |<>--{0..1}--[ StartTime ] | ENUM action |<>--{0..1}--[ EndTime ] | STRING ext-action |<>--{0..1}--[ Contact ] +-------------------+ Figure 21: the Expectation class The aggregate classes that constitute Expectation are: Description Zero or many. ML_STRING. A free-form description of the desired action(s). StartTime Zero or one. The time at which the action should be performed. A timestamp that is earlier than the ReportTime specified in the Incident class denotes that the expectation should be fulfilled as soon as possible. The absence of this element leaves the execution of the expectation to the discretion of the recipient. EndTime Zero or one. The time by which the action should be completed. If the action is not carried out by this time, it should no longer be performed. Contact Zero or one. The expected actor for the action. The Expectations class has three attributes: restriction Optional. ENUM. This attribute is defined in Section 3.2. severity Optional. ENUM. Indicates the desired priority of the action. This attribute is an enumerated list with no default value, and the semantics of these relative measures are context dependant. 1. low. Low priority 2. medium. Medium priority 3. high. High priority Danyliw, et al. Expires March 20, 2007 [Page 37] Internet-Draft IODEF September 2006 action Optional. ENUM. Classifies the type of action requested. This attribute is an enumerated list with no default value. 1. nothing. No action is requested. Do nothing with the information. 2. contact-source-site. Contact the site(s) identified as the source of the activity. 3. contact-target-site. Contact the site(s) identified as the target of the activity. 4. contact-sender. Contact the originator of the document. 5. investigate. Investigate the systems(s) listed in the event. 6. block-host. Block traffic from the machine(s) listed as sources the event. 7. block-network. Block traffic from the network(s) lists as sources in the event. 8. block-port. Block the port listed as sources in the event. 9. rate-limit-host. Rate-limit the traffic from the machine(s) listed as sources in the event. 10. rate-limit-network. Rate-limit the traffic from the network(s) lists as sources in the event. 11. rate-limit-port. Rate-limit the port(s) listed as sources in the event. 12. remediate-other. Remediate the activity in a way other than by rate limiting or blocking. 13. status-triage. Conveys receipts and the triaging of an incident. 14. status-new-info. Conveys that new information was received for this incident. 15. other. Perform some custom action described in the Description class. 16. ext-value. An escape value used to extend this attribute. See Section 5.1. Danyliw, et al. Expires March 20, 2007 [Page 38] Internet-Draft IODEF September 2006 ext-action Optional. STRING. A means by which to extend the action attribute. See Section 5.1. 3.14. Flow class The Flow class groups related the source and target hosts. +------------------+ | Flow | +------------------+ | |<>--{1..*}--[ System ] +------------------+ Figure 22: the Flow class The aggregate class that constitutes Flow is: System One or More. A host or network involved in an event. The Flow System class has no attributes. 3.15. System class The System class describes a system or network involved in an event. The systems or networks represented by this class are categorized according to the role they played in the incident through the category attribute. The value of this category attribute dictates the semantics of the aggregated classes in the System class. If the category attribute has a value of "source", then the aggregated classes denote the machine and service from which the activity is originating. With a category attribute value of "target" or "intermediary", then the machine or service is the one targeted in the activity. A value of "sensor" dictates that this System was part of an instrumentation to monitor the network. Danyliw, et al. Expires March 20, 2007 [Page 39] Internet-Draft IODEF September 2006 +---------------------+ | System | +---------------------+ | ENUM restriction |<>----------[ Node ] | ENUM category |<>--{0..*}--[ Service ] | STRING ext-category |<>--{0..*}--[ OperatingSystem ] | STRING interface |<>--{0..*}--[ Counter ] | ENUM spoofed |<>--{0..*}--[ Description ] | |<>--{0..*}--[ AdditionalData ] +---------------------+ Figure 23: the System class The aggregate classes that constitute System are: Node One. A host or network involved in the incident. Service Zero or more. A network service running on the system. OperatingSystem Zero or one. The operating system running on the system. Counter Zero or more. A counter with which to summarize properties of this host or network. Description Zero or more. ML_STRING. A free-form text description of the System. AdditionalData Zero or many. A mechanism by which to extend the data model. The System class has five attribute: restriction Optional. ENUM. This attribute is defined in Section 3.2. category Required. ENUM. Classifies the role the host or network played in the incident. The possible values are: 1. source. The System was the source of the event. 2. target. The System was the target of the event. Danyliw, et al. Expires March 20, 2007 [Page 40] Internet-Draft IODEF September 2006 3. intermediate. The System was an intermediary in the event. 4. sensor. The System was a sensor monitoring the event. 5. infrastructure. The System was an infrastructure node of IODEF document exchange. 6. ext-value. An escape value used to extend this attribute. See Section 5.1. ext-category Optional. STRING. A means by which to extend the category attribute. See Section 5.1. interface Optional. STRING. Specifies the interface on which the event(s) on this System originated. If the Node class specifies a network rather than a host, this attribute has no meaning. spoofed Optional. ENUM. An indication of confidence in whether this System was the true target or attacking host. The permitted values for this attribute are shown below. The default value is "unknown". 1. unknown. The accuracy of the category attribute value is unknown 2. yes. The category attribute value is probably incorrect. In the case of a source, the System is likely a decoy; with a target, the System was likely not the intended victim. 3. no. The category attribute value is believed to be correct. 3.16. Node class The Node class names a system (e.g., PC, router) or network. This class was derived from the IDMEF [18]. Danyliw, et al. Expires March 20, 2007 [Page 41] Internet-Draft IODEF September 2006 +---------------+ | Node | +---------------+ | |<>--{0..*}--[ NodeName ] | |<>--{0..*}--[ Address ] | |<>--{0..1}--[ Location ] | |<>--{0..1}--[ DateTime ] | |<>--{0..*}--[ NodeRole ] | |<>--{0..*}--[ Counter ] +---------------+ Figure 24: The Node class The aggregate classes that constitute Node are: NodeName Zero or more. ML_STRING. The name of the Node (e.g., fully qualified domain name). This information MUST be provided if no Address information is given. Address Zero or more. The hardware, network, or application address of the Node. If a NodeName is not provided, at least one Address MUST be specified. Location Zero or one. ML_STRING. A free-from description of the physical location of the equipment. DateTime Zero or one. A timestamp of when the resolution between the name and address was performed. This information SHOULD be provided if both an Address and NodeName are specified. NodeRole Zero or more. The intended purpose of the Node. Counter Zero or more. A counter with which to summarizes properties of this host or network. 3.16.1. Counter class The Counter class summarize multiple occurrences of some event, or conveys counts or rates on various features (e.g., packets, sessions, events). The value of the counter is the element content with its units Danyliw, et al. Expires March 20, 2007 [Page 42] Internet-Draft IODEF September 2006 represented in the type attribute. A rate for a given feature can be expressed by setting the duration attribute. The complete semantics are entirely context dependant based on the class in which the Counter is aggregated. +------------------+ | Counter | +------------------+ | REAL | | | | ENUM type | | STRING ext-type | | STRING meaning | | ENUM duration | +------------------+ Figure 25: the Counter class The Counter class has three attribute: type Required. ENUM. Specifies the units of the element content. 1. byte. Count of bytes. 2. packet. Count of packets. 3. flow. Count of flow (e.g., NetFlow records). 4. session. Count of sessions 5. alert. Count of notifications generated by another system (e.g., IDS or SIM). 6. message. Count of messages (e.g., mail messages). 7. event. Count of events 8. ext-value. An escape value used to extend this attribute. See Section 5.1. ext-type Optional. STRING. A means by which to extend the type attribute. See Section 5.1. Danyliw, et al. Expires March 20, 2007 [Page 43] Internet-Draft IODEF September 2006 duration Optional. ENUM. If present, the Counter class represents a rate rather than a count over the entire event. In that case, this attribute specifies the denominator of the rate (where the type attribute specified the nominator). The possible values of this attribute are defined in Section 3.10.2 3.16.2. Address The Address class represents a hardware (layer-2), network (layer-3), or application (layer-7) address. This class was derived from the IDMEF [18]. +---------------------+ | Address | +---------------------+ | ENUM category | | STRING ext-category | | STRING vlan-name | | INTEGER vlan-num | +---------------------+ Figure 26: the Address class The Address class has four attributes: category Required. ENUM. The type of address represented. The permitted values for this attribute are shown below. The default value is "ipv4-addr". 1. asn. Autonomous System Number 2. atm. Asynchronous Transfer Mode (ATM) address 3. e-mail. Electronic mail address (RFC 822) 4. ipv4-addr. IPv4 host address in dotted-decimal notation (a.b.c.d) 5. ipv4-net. IPv4 network address in dotted-decimal notation, slash, significant bits (a.b.c.d/nn) 6. ipv4-net-mask. IPv4 network address in dotted-decimal notation, slash, network mask in dotted-decimal notation (a.b.c.d/w.x.y.z) Danyliw, et al. Expires March 20, 2007 [Page 44] Internet-Draft IODEF September 2006 7. ipv6-addr. IPv6 host address 8. ipv6-net. IPv6 network address, slash, significant bits 9. ipv6-net-mask. IPv6 network address, slash, network mask 10. mac. Media Access Control (MAC) address 11. ext-value. An escape value used to extend this attribute. See Section 5.1. ext-category Optional. STRING. A means by which to extend the category attribute. See Section 5.1. vlan-name Optional. STRING. The name of the Virtual LAN to which the address belongs. vlan-num Optional. STRING. The number of the Virtual LAN to which the address belongs. 3.16.3. NodeRole class The NodeRole class describes the intended function performed by a particular host. +---------------------+ | NodeRole | +---------------------+ | ML_STRING | | | | ENUM category | | STRING ext-category | | ENUM lang | +---------------------+ Figure 27: The NodeRole class The element content should be empty in all cases other than when the category attribute is set to "other". The NodeRole class has two attributes: Danyliw, et al. Expires March 20, 2007 [Page 45] Internet-Draft IODEF September 2006 category Required. ENUM. Functionality provided by a node. If a value of "other" is specified, a description SHOULD be provided in the element content. 1. client. Client computer 2. server-internal. Server with internal services 3. server-public. Server with public services 4. www. WWW server 5. mail. Mail server 6. messaging. Messaging server (e.g., NNTP, IRC, IM) 7. streaming. Streaming-media server 8. voice. Voice server (e.g., SIP, H.323) 9. file. File server (e.g., SMB, CVS, AFS) 10. ftp. FTP server 11. p2p. Peer-to-peer node 12. name. Name server (e.g., DNS, WINS) 13. directory. Directory server (e.g., LDAP, finger, whois) 14. credential. Credential server (e.g., domain controller, Kerberos) 15. print. Print server 16. application. Application server 17. database. Database server 18. infra. Infrastructure server (e.g., router, firewall, DHCP) 19. log. Logserver (e.g., syslog) 20. other. The node performs a role documented in the element content. Danyliw, et al. Expires March 20, 2007 [Page 46] Internet-Draft IODEF September 2006 21. ext-value. An escape value used to extend this attribute. See Section 5.1. ext-category Optional. STRING. A means by which to extend the category attribute. See Section 5.1. lang Required. ENUM. A valid language code per RFC 3066 [7] constrained by the definition of "xs:language". The interpretation of this code is described in Section 6. 3.17. Service class The Service class describes a network service of a host or network. The service is identified by specific port or list of ports, along with the application listening on that port. When Service occurs as an aggregate class of a System that is a source, then this service is the one from which activity of interest is originating. Conversely, when Service occurs as an aggregate class of a System that is a target, then that service is the one to which activity of interest is directed. This class was derived from the IDMEF [18]. +---------------------+ | Service | +---------------------+ | ENUM ip_version |<>--{0..1}--[ Port ] | INTEGER ip_protocol |<>--{0..1}--[ Portlist ] | |<>--{0..1}--[ ProtoCode ] | |<>--{0..1}--[ ProtoType ] | |<>--{0..1}--[ ProtoFlags ] | |<>--{0..1}--[ Application ] +---------------------+ Figure 28: The Service class The aggregate classes that constitute Service are: Port Zero or one. INTEGER. A port number. Danyliw, et al. Expires March 20, 2007 [Page 47] Internet-Draft IODEF September 2006 Portlist Zero or one. PORTLIST. A list of port numbers formatted according to Section 2.10. ProtoCode Zero or one. INTEGER. A layer-4 protocol-specific code field. ProtoType Zero or one. INTEGER. A layer-4 protocol specific type field. ProtoFlags Zero or one. INTEGER. A layer-4 protocol specific flag field. Application Zero or more. The application bound to the specified Port or Portlist. Either a Port or Portlist class MUST be specified for a given instance of a Service class. For a given source, System@type="source", a corresponding target, System@type="target", maybe defined, or vice versa. When a Portlist class is defined in the Service class of both the source and target in a given instance of the Flow class, there MUST be symmetry in the enumeration of the ports. Thus, if n-ports are listed for a source, n-ports should be listed for the target. Likewise, the ports should be listed in an identical sequence such that the n-th port in the source corresponds to the n-th port of the target. This symmetry in listing and sequencing of ports applies whether there are 1-to-1, 1-to-many, or many-to-many sources-to-targets. In the 1-to-many or many-to-many, the exact order in which the System classes are enumerated in the Flow class is significant. The Service class has two attributes: ip_version Required. ENUM. The IP version number specified as either "4" or "6". ip_protocol Required. INTEGER. The IANA protocol number. 3.17.1. Application class The Application class describes an application running on a System providing a Service. Danyliw, et al. Expires March 20, 2007 [Page 48] Internet-Draft IODEF September 2006 +--------------------+ | Application | +--------------------+ | STRING swid |<>--{0..1}--[ URL ] | STRING configid | | STRING vendor | | STRING family | | STRING name | | STRING version | | STRING patch | +--------------------+ Figure 29: The Application class The aggregate classes that constitute Application are: URL Zero or one. URL. A URL describing the application. The Application class has seven attributes: swid Optional. STRING. An identifier that can be used to reference this software. configid Optional. STRING. An identifier that can be used to reference a particular configuration of this software. vendor Optional. STRING. Vendor name of the software. family Optional. STRING. Family of the software. name Optional. STRING. Name of the software. version Optional. STRING. Version of the software. patch Optional. STRING. Patch or service pack level of the software. Danyliw, et al. Expires March 20, 2007 [Page 49] Internet-Draft IODEF September 2006 3.18. OperatingSystem class The OperatingSystem class describes the operating system running on a System. The definition is identical to the Application class (Section 3.17.1). 3.19. Record class The Record class is a container class for log and audit data that provides supportive information about the incident. The source of this data will often be the output of monitoring tools. These logs should substantiate the activity described in the document. +------------------+ | Record | +------------------+ | ENUM restriction |<>--{1..*}--[ RecordData ] +------------------+ Figure 30: Record class The aggregate class that constitutes Record is: RecordData One or more. Log or audit data generated by a particular type of sensor. Separate instances of the RecordData class SHOULD be used for each sensor type. The Record class has one attribute: restriction Optional. ENUM. This attribute has been defined in Section 3.2. 3.19.1. RecordData class The RecordData class groups log or audit data from a given sensor (e.g., IDS, firewall log) and provides a way to annotate the output. Danyliw, et al. Expires March 20, 2007 [Page 50] Internet-Draft IODEF September 2006 +------------------+ | RecordData | +------------------+ | ENUM restriction |<>--{0..1}--[ DateTime ] | |<>--{0..*}--[ Description ] | |<>--{0..1}--[ Application ] | |<>--{0..*}--[ RecordPattern ] | |<>--{1..*}--[ RecordItem ] | |<>--{0..*}--[ AdditionalData ] +------------------+ Figure 31: The RecordData class The aggregate classes that constitutes RecordData is: DateTime Zero or one. Timestamp of the RecordItem data. Description Zero or more. ML_STRING. Free-form textual description of the provided RecordItem data. At minimum, this description should convey the significance of the provided RecordItem data. Application Zero or one. Information about the sensor used to generate the RecordItem data. RecordItem One or more. Log, audit, or forensic data. AdditionalData Zero or one. An extension mechanism for data not explicitly represented in the data model. The RecordData class has one attribute: restriction Optional. ENUM. This attribute has been defined in Section 3.2. 3.19.2. RecordPattern class The RecordPattern class describes where in the content of the RecordItem relevant information can be found. It provides a way to reference subsets of information, identified by a pattern, in a large log file, audit trail, or forensic data. Danyliw, et al. Expires March 20, 2007 [Page 51] Internet-Draft IODEF September 2006 +-----------------------+ | RecordPattern | +-----------------------+ | STRING | | | | ENUM type | | STRING ext-type | | INTEGER offset | | ENUM offsetunit | | STRING ext-offsetunit | | INTEGER instance | +-----------------------+ Figure 32: The RecordPattern class The specific pattern to search with in the RecordItem is defined in the body of the element. It is further annotated by four attributes: type Required. ENUM. Describes the type of pattern being specified in the element content. The default is "regex". 1. regex. PERL regular expression 2. binary. Binhex encoded binary pattern, per the HEXBIN data type 3. xpath. XML Path (XPath) [5] 4. ext-value. An escape value used to extend this attribute. See Section 5.1. ext-type Optional. STRING. A means by which to extend the type attribute. See Section 5.1. offset Optional. INTEGER. Amount of units (determined by the offsetunit attribute) to seek into the RecordItem data before matching the pattern. offsetunit Optional. ENUM. Describes the units of the offset attribute. The default is "line". 1. line. Offset is a count of lines. Danyliw, et al. Expires March 20, 2007 [Page 52] Internet-Draft IODEF September 2006 2. binary. Offset is a count of bytes. 3. ext-value. An escape value used to extend this attribute. See Section 5.1. ext-offsetunit Optional. STRING. A means by which to extend the offsetunit attribute. See Section 5.1. instance Optional. INTEGER. Number of types to apply the specified pattern. 3.19.3. RecordItem class The RecordItem class provides a way to incorporate relevant logs, audit trails, or forensic data to support the conclusions made during the course of analyzing the incident. The class supports both the direct encapsulation of the data, as well as, provides primitives to reference data stored elsewhere. This class is identical to AdditionalData class (Section 3.6). Danyliw, et al. Expires March 20, 2007 [Page 53] Internet-Draft IODEF September 2006 4. Processing Considerations This section defines additional requirements on creating and parsing IODEF documents. 4.1. Encoding Every IODEF document MUST begin with an XML declaration, and MUST specify the XML version used. If UTF-8 encoding is not used, the character encoding MUST also be explicitly specified. The IODEF conforms to all XML data encoding conventions and constraints. The XML declaration with no character encoding will read as follows: When a character encoding is specified, the XML declaration will read like the following: Where "charset" is the name of the character encoding as registered with the Internet Assigned Numbers Authority (IANA), see [9]. The following characters have special meaning in XML and MUST be escaped with their entity reference equivalent: "&", "<", ">", "\"" (double quotation mark), and "'" (apostrophe). These entity references are "&", "<", ">", """, and "'" respectively. 4.2. IODEF Namespace The IODEF schema declares a namespace of "iodef-1.0" and registers it per [4]. Each IODEF document MUST use the "iodef-1.0" namespace in the top-level element IODEF-Document. It can be referenced as follows: A given extension attribute MUST NOT be set unless the corresponding extensible attribute has been set to "ext-value". 5.2. Extending classes The classes of the data model can be extended only through the use of the AdditionalData and RecordItem classes. These container classes, collectively referred to as the extensible classes, are implemented with the iodef:ExtensionType data type in the schema. They provide the ability to have new atomic or XML-encoded data elements in all of the top-level classes of the Incident class and a few of the more Danyliw, et al. Expires March 20, 2007 [Page 56] Internet-Draft IODEF September 2006 complicated subordinate classes. As there are multiple instances of the extensible classes in the data model, there is discretion on where to add a new data element. It is RECOMMENDED that the extension be placed in the most closely related class to the new information. Extensions using the atomic data types (i.e., all values of the dtype attributes other than "xml") MUST: 1. Set the element content of extensible class to the desired value, and 2. Set the dtype attribute to correspond to the data type of the element content. The following guidelines exist for extensions using XML: 1. The element content of the extensible class MUST be set to the desired value and the dtype attribute MUST be set to "xml". 2. The extension schema MUST declare a separate namespace. It is RECOMMENDED that these extensions have the prefix "iodef-". 3. It is RECOMMENDED that extension schemas follow the naming convention of the IODEF data model. The names of all elements are capitalized. For composed names, a capital letter is used for each word. Attribute names are lower case. The following schema and XML document excerpt provide a template for an extension schema and its use in the IODEF document. This example schema defines a namespace of "iodef-extension1" and a single element named "newdata". attributeFormDefault="unqualified" elementFormDefault="qualified"> The following XML excerpt demonstrates the use of the above schema as Danyliw, et al. Expires March 20, 2007 [Page 57] Internet-Draft IODEF September 2006 an extension to the IODEF. ... Field that could not be represented elsewhere 189493 2001-09-13T23:19:24+00:00 Host sending out Code Red probes Example.com CSIRT example-com contact@csirt.example.com
192.0.2.200
57
192.0.2.16/28
 80 Danyliw, et al. Expires March 20, 2007 [Page 60] Internet-Draft IODEF September 2006 2001-09-13T18:11:21+02:00 Web-server logs 192.0.2.1 - - [13/Sep/2001:18:11:21 +0200] "GET /default.ida? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX http://mylogs.example.com/logs/httpd_access 2001-09-14T08:19:01+00:00 Notification sent to constituency-contact@192.0.2.200 7.2. Reconnaissance An example of a CSIRT reporting a scanning activity. 59334 2006-08-02T05:54:02-05:00 Danyliw, et al. Expires March 20, 2007 [Page 61] Internet-Draft IODEF September 2006 nmap http://nmap.toolsite.example.com CSIRT for example.com contact@csirt.example.com +1 412 555 12345 Joe Smith smith@csirt.example.com
192.0.2.200
 60524,60526,60527,60531
192.0.2.201
 137-139,445 Danyliw, et al. Expires March 20, 2007 [Page 62] Internet-Draft IODEF September 2006
192.0.2.240
192.0.2.64/28
 445 7.3. Bot-Net Reporting An example of a CSIRT reporting a bot-network. 908711 2006-06-08T05:44:53-05:00 Large bot-net GT Bot CA-2003-22 http://www.cert.org/advisories/CA-2003-22.html Root compromise via this IE vulnerability to install the GT Bot Joe Smith jsmith@csirt.example.com These hosts are compromised and acting as bots communicating with irc.example.com.
192.0.2.1
 10000 bot
192.0.2.3
 250000 bot irc.example.com
192.0.2.20
2006-06-08T01:01:03-05:00 IRC server on #give-me-cmd channel Confirm the source and take machines off-line and Danyliw, et al. Expires March 20, 2007 [Page 64] Internet-Draft IODEF September 2006 remediate 7.4. Watch List An example of a CSIRT conveying a watch-list. 908711 2006-08-01T00:00:00-05:00 Watch-list of known bad IPs or networks CSIRT for example.com contact@csirt.example.com
192.0.2.53
 Source of numerous attacks Danyliw, et al. Expires March 20, 2007 [Page 65] Internet-Draft IODEF September 2006
192.0.2.16/28
 Source of heavy scanning over past 1-month
192.0.2.241
 C2 IRC server Danyliw, et al. Expires March 20, 2007 [Page 66] Internet-Draft IODEF September 2006 8. The IODEF Schema Incident Object Description Exchange Format v1.00, see RFC XXX Danyliw, et al. Expires March 20, 2007 [Page 68] Internet-Draft IODEF September 2006 Danyliw, et al. Expires March 20, 2007 [Page 69] Internet-Draft IODEF September 2006 Danyliw, et al. Expires March 20, 2007 [Page 70] Internet-Draft IODEF September 2006 Danyliw, et al. Expires March 20, 2007 [Page 72] Internet-Draft IODEF September 2006 Danyliw, et al. Expires March 20, 2007 [Page 73] Internet-Draft IODEF September 2006 Danyliw, et al. Expires March 20, 2007 [Page 74] Internet-Draft IODEF September 2006 Danyliw, et al. Expires March 20, 2007 [Page 76] Internet-Draft IODEF September 2006 Danyliw, et al. Expires March 20, 2007 [Page 79] Internet-Draft IODEF September 2006 Danyliw, et al. Expires March 20, 2007 [Page 80] Internet-Draft IODEF September 2006 Danyliw, et al. Expires March 20, 2007 [Page 81] Internet-Draft IODEF September 2006 Danyliw, et al. Expires March 20, 2007 [Page 82] Internet-Draft IODEF September 2006 Danyliw, et al. Expires March 20, 2007 [Page 83] Internet-Draft IODEF September 2006 Danyliw, et al. Expires March 20, 2007 [Page 84] Internet-Draft IODEF September 2006 Danyliw, et al. Expires March 20, 2007 [Page 85] Internet-Draft IODEF September 2006 Danyliw, et al. Expires March 20, 2007 [Page 86] Internet-Draft IODEF September 2006 9. Security considerations The IODEF data model itself does not directly introduce security issues. Rather, it defines a data representation for incident information that will likely be considered sensitive. The underlying messaging format and protocol used to exchange instances of the IODEF MUST provide appropriate guarantees of confidentiality, integrity, and authenticity. A transport protocol such as the Real-time Inter-network Defense (RID) protocol [19] and its associated transport binding IODEF/RID over SOAP [20] provide such security. Danyliw, et al. Expires March 20, 2007 [Page 87] Internet-Draft IODEF September 2006 10. IANA considerations This document uses URNs to describe an XML namespace and schema conforming to a registry mechanism described in [16] Registration request for the IODEF namespace: o URI: urn:ietf:params:xml:ns:iodef-1.0 o Registrant Contact: See the first author of the "Author's Address" section of this document. o XML: None. Namespace URIs do not represent an XML specification. Registration request for the IODEF XML schema: o URI: urn:ietf:params:xml:schema:iodef-1.0 o Registrant Contact: See the first author of the "Author's Address" section of this document. o XML: See the "IODEF Schema" in Section 8 of this document. Danyliw, et al. Expires March 20, 2007 [Page 88] Internet-Draft IODEF September 2006 11. Acknowledgments The following groups and individuals, listed alphabetically, contributed substantially to this document and should be recognized for their efforts. o Patrick Cain, Cooper-Cain Group, Inc. o The eCSIRT.net Project o The Incident Object Description and Exchange Format Working-Group of the TERENA task-force (TF-CSIRT) o Glenn Mansfield Keeni, Cyber Solutions, Inc. o Hiroyuki Kido, NARA Institute of Science and Technology o Kathleen Moriarty, MIT Lincoln Labs o Brian Trammell, CERT/NetSA Danyliw, et al. Expires March 20, 2007 [Page 89] Internet-Draft IODEF September 2006 12. References 12.1. Normative References [1] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation , October 2000, . [2] World Wide Web Consortium, "XML XML Schema Part 1: Structures Second Edition", W3C Recommendation , October 2004, . [3] World Wide Web Consortium, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation , October 2004, . [4] World Wide Web Consortium, "Namespaces in XML", W3C Recommendation , January 1999, . [5] World Wide Web Consortium, "XML Path Language (XPath) 2.0", W3C Candidate Recommendation , June 2006, . [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [7] Alvestrand, H., "Tags for the Identification of Languages", RFC 3066, January 2001. [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [9] Freed, N., "IANA Charset Registration Procedures", BCP 2278, January 1998. [10] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997. [11] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [12] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [13] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. Danyliw, et al. Expires March 20, 2007 [Page 90] Internet-Draft IODEF September 2006 [14] International Organization for Standardization, "International Standard: Data elements and interchange formats - Information interchange - Representation of dates and times", ISO 8601, Second Edition, December 2000. [15] International Organization for Standardization, "International Standard: Codes for the representation of currencies and funds, ISO 4217:2001", ISO 4217:2001, August 2001. [16] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. 12.2. Informative References [17] Keeni, G., Demchenko, Y., and R. Danyliw, "Requirements for the Format for Incident Information Exchange (FINE)", RFC XXX, December 2005. [18] Curry, D. and H. Debar, "Intrusion Detection Message Exchange Format", RFC XXX, March 2006. [19] Moriarty, K., "Incident Handling: Real-time Inter-network Defense", RFC XXX, June 2006. [20] Moriarty, K. and B. Trammell, "IODEF/RID over SOAP", RFC XXX, June 2006. Danyliw, et al. Expires March 20, 2007 [Page 91] Internet-Draft IODEF September 2006 Authors' Addresses Roman Danyliw CERT Program Pittsburgh USA Email: rdd@cert.org Jan Meijer SURFnet bv Utrecht Netherlands Email: jan.meijer@surfnet.nl Yuri Demchenko University of Amsterdam Amsterdam Netherlands Email: demch@chello.nl Danyliw, et al. Expires March 20, 2007 [Page 92] Internet-Draft IODEF September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Danyliw, et al. Expires March 20, 2007 [Page 93]