Extended Incident Handling Working Group R. Danyliw Internet-Draft CERT Coordination Center Expires: September 7, 2004 March 09, 2004 The Incident Object Description Exchange Format (IODEF) Implementation Guide draft-ietf-inch-implement-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 September 7, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The purpose of this Internet-Draft is to provide implementation guidelines for Computer Security Incident Response Teams (CSIRT) adopting the Incident Object Description Exchange Format (IODEF). Danyliw Expires September 7, 2004 [Page 1] Internet-Draft IODEF Implementation Guide March 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 CSIRT Operations . . . . . . . . . . . . . . . . . . . . . 3 2. General Integration Considerations . . . . . . . . . . . . . . 4 2.1 Unique Identifiers . . . . . . . . . . . . . . . . . . . . 5 2.2 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1 Required Data . . . . . . . . . . . . . . . . . . . . 6 2.2.2 Semantics . . . . . . . . . . . . . . . . . . . . . . 6 2.2.3 Formatting . . . . . . . . . . . . . . . . . . . . . . 6 2.2.4 Transport issues . . . . . . . . . . . . . . . . . . . 6 2.3 Updating Incident Data . . . . . . . . . . . . . . . . . . 7 3. Importing and Processing Considerations . . . . . . . . . . . 7 3.1 Processing Algorithm . . . . . . . . . . . . . . . . . . . 7 3.2 IDMEF relationship . . . . . . . . . . . . . . . . . . . . 9 3.3 Types of Data . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1 Enumerated Values . . . . . . . . . . . . . . . . . . 9 3.3.2 Structured Values . . . . . . . . . . . . . . . . . . 10 3.3.3 Subjective Values . . . . . . . . . . . . . . . . . . 10 3.3.4 Free-form Values . . . . . . . . . . . . . . . . . . . 10 3.3.5 Extensions . . . . . . . . . . . . . . . . . . . . . . 11 3.4 Structure of the Data . . . . . . . . . . . . . . . . . . 11 3.4.1 Non-deterministic . . . . . . . . . . . . . . . . . . 11 3.4.2 Document unique idents . . . . . . . . . . . . . . . . 11 4. Export Considerations . . . . . . . . . . . . . . . . . . . . 11 4.1 Processing Algorithm . . . . . . . . . . . . . . . . . . . 11 5. Representation Examples . . . . . . . . . . . . . . . . . . . 12 5.1 Multiple Contacts . . . . . . . . . . . . . . . . . . . . 12 5.2 Expectation . . . . . . . . . . . . . . . . . . . . . . . 13 5.3 Sequence of Events . . . . . . . . . . . . . . . . . . . . 13 5.4 XML-Signature . . . . . . . . . . . . . . . . . . . . . . 13 5.5 XML-Encryption . . . . . . . . . . . . . . . . . . . . . . 13 5.6 Non-English example . . . . . . . . . . . . . . . . . . . 13 5.7 Translations . . . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. Appendix 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Normative References . . . . . . . . . . . . . . . . . . . . . 16 Informative References . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Danyliw Expires September 7, 2004 [Page 2] Internet-Draft IODEF Implementation Guide March 2004 1. Introduction 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 [4]. Definitions for some of the common computer security-related terminology used in this document can be found in Section 2 of [1]. 1.2 Overview The Incident Object Description Exchange Format (IODEF) [7] 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 [1]. Practically, [7] also provides an XML DTD (soon to be Schema) implementation of the data model. 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. This draft is incomplete. There are several sections marked as "TODO" either the document author has not completed the text, or the working group needs to provide clarification. 1.3 CSIRT Operations The key function of a CSIRT is to remediate security activity in their constituency. As security events can occur across administrative domains, CSIRTs also often play a coordination role to resolve incidents. In the IODEF context, a CSIRT is defined very broadly to include almost any entity that might exchange incident information. For example, this role might be fulfilled by a single security analyst in a network operations group, a help-desk operation center, or a national-level CSIRT. CSIRTs with responsibility over networks often build their operations around a system to manage the entire incident life-cycle. This incident handling system (IHS) must store all incident information and related communications; provide primitives to support the work-flow of the analysts; and tools to analyze the reported incident Danyliw Expires September 7, 2004 [Page 3] Internet-Draft IODEF Implementation Guide March 2004 data. It is commonly built around a ticket-tracking application adapted for a security role. The underlying data store is typically a relational database. See section 3 of [1] for additional details about the implicit operational assumptions for the IODEF. The IODEF is agnostic to most of the internal process and technology choices made by a CSIRT. The IODEF provides no improvements for user interface issues or new analytical techniques. It is in the communications with other parties that the IODEF can have an impact on operations. The current collaboration model requires significant effort to process incident reports because of a lack of standardization in incident information. The IODEF can simplify some of this communication by providing a well-documented format and structure, published as an XML DTD, to represent the incident data already being exchanged. The IODEF is not a replacement for all communication in and across constituencies. Any common format is useful when there is a need to inter-operate. Inside an organization, where processes can be mandated by fiat, standardization occurs implicitly. The value of IODEF comes when there is a need to exchange information across administrative domain. That said, the IODEF is not suitable for all users. The format is complex, making it unlikely that IODEF documents will be generated by hand as done with many incident reports today. Therefore, it will largely be employed only by a more sophisticated set of users that have the knowledge to reformat their incident data. In the foreseeable future, there will be a continued need to support free-form reporting mechanisms. As a middle ground, front-end tools gathering incident data (e.g., web forms) can be developed to export IODEF documents. 2. General Integration Considerations 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. Danyliw Expires September 7, 2004 [Page 4] Internet-Draft IODEF Implementation Guide March 2004 2.1 Unique Identifiers CSIRTs track incidents by assigning each an identifier unique in context of its constituency. In the IODEF data model, this identifier is represented by the mandatory IncidentID class. It is through this identifier that an IODEF document relates to the IHS. It is possible that this same activity could be reported to another CSIRT that in turn assigns its own unique identifier. Each CSIRT associates their own identifier for the identical incident in their respective IHS. However, to provide a framework for CSIRTs to refer to each other's data, the IODEF provides the optional AlternateID class to represent another CSIRT's tracking identifier for the same activity. Combining the name of a CSIRT and the incident identifier provides a globally unique identifier for an incident. TODO: How are IncidentIDs generated? What is the convention? It may be possible that multiple IODEF documents are exchanged about the same incident over its lifetime. Hence, the use of the id attribute of the IODEF-Document to uniquely identify a particular IODEF document. This global identifier is only relevant for the purposes of transport (e.g., duplicate detection, retransmission). It will change with each new IODEF document, regardless of the value of the IncidentID class value. TODO: Can an /IODEF-Document@id ever be reused? how is it generated? Is it globally unique? 2.2 Profiles While the IODEF data model is unambiguous, the usage and the semantics of the data will need to be further refined for a community of collaborators if incident data is to be exchanged. These data exchange policies are collectively referred to as a profile. The need for profiles, in addition to the format specification, is due to the wide variety of data that might be represented in an IODEF document. A well-specified profile is the key to machine-parsing the exchanged documents. A CSIRT may choose to publicly publish a profile for use by anyone wishing to communicate information to it. Such a model is helpful in a CSIRT with a wide constituency that might receive unsolicited reports. Likewise, in a smaller, closed community of CSIRTs, specific arrangements that apply only to the respective parties can be made. These profiles may cover organizational specific information that the parties will be sharing. Since a CSIRT may send IODEF documents to many other CSIRTS, it will have to maintain many profiles, each specific to the intended recipient. Danyliw Expires September 7, 2004 [Page 5] Internet-Draft IODEF Implementation Guide March 2004 The format for specifying a profile is outside the scope of this document and the INCH working group. However, Section 2.2.1 to Section 2.2.4 provide a cursory description of the types of information that should be included in a profile. 2.2.1 Required Data A profile MUST specify exactly the data that will be exchanged between peers. The IODEF specification mandates the presence of certain fields, but the profile should go further to define which optional fields are required. There is no point in sending data that a peer might not be interested in collected. Likewise, insufficient information will require a follow-up communication. Incident reports documenting different types of activity are not composed of the same type of data. For example, the data needed to describe an administrative compromise might be different from that of a policy violation. Therefore, a profile could distinguish between the different types of incidents and specify different mandatory fields for each. 2.2.2 Semantics Given the XML DTD and the profile, the recipient of an IODEF document should be able to understand the the contents. A profile MUST disambiguate the semantics of all the subjective values (see Section 3.3.3) that are exchanged. When not compromising the intent of the transformation, any sanitization performed on the data SHOULD be documented. Naming conventions for data commonly found in CSIRTs (e.g., incident numbers) SHOULD be documented. 2.2.3 Formatting To the the degree possible, formatting conventions SHOULD be standardized to aid in machine processing of IODEF documents. This specification is especially relevant when dealing with the free-form values (see Section 3.3.4). Agreeing on a natural language for these fields is also helpful within a diverse community. In addition the format of the content itself, the overall structure of the IODEF document should be documented. Given that the data model is non-deterministic (see Section 3.4.1), the profile SHOULD specify the required way to represent the information. 2.2.4 Transport issues In the absence of an IODEF transport protocol, the profile MUST Danyliw Expires September 7, 2004 [Page 6] Internet-Draft IODEF Implementation Guide March 2004 document how the peers will exchange the IODEF documents. The choice of protocols must take into account the properties of the XML IODEF documents. Ideally the channel between parties would provide reliable delivery, compression of the text stream, confidentiality, integrity, and authenticity. Non-repudiation may be desirable in certain situations. The process surrounding the use of the protocol will also need to be specified. The frequency of incident data exchange SHOULD be specified (e.g., batched at pre-determined intervals, or real-time). If cryptography is used, key management issues must be addressed. Choices of trust models must be decided; will trust be based on a hierarchy (ala, a PKI) or a web-of-trust (ala, PGP). Existing data exchange practices in CSIRT operations commonly make use of SOAP, TLS, or PGP encrypted and signed email messages. 2.3 Updating Incident Data TODO: The working group needs to decide how to perform updates, if at all 3. Importing and Processing Considerations Upon receiving an IODEF document, the IHS must process it so that normal work-flow processes can be applied. The task of importing an IODEF document involves extracting the relevant data and storing it in the IHS. 3.1 Processing Algorithm The processing of IODEF documents can be generalized into five steps. Depending on the specific exchange protocols used, and the particular IHS, certain steps may not be necessary. o Accepting the document. IODEF documents will likely be exchanged over a cryptographically secured medium. Prior to even examining the document, it may need to be decrypted. If the underlying transport does not already handling the issues of key management, the IHS must provide the correct decryption key. It may be necessary to use external information or properties of the document itself to determine the proper key to use. When possible, the authenticity of the document from the sender must also be verified (e.g., via public key signatures). If confidentiality and integrity are implemented via XML-Encryption and XML-Signature, validation of the XML MUST occur prior to this step. Danyliw Expires September 7, 2004 [Page 7] Internet-Draft IODEF Implementation Guide March 2004 o Structural Validation. To confirm proper formatting, the document must be examined with an XML parser to check that it is both well-formed and valid according to the IODEF DTD. If XML extensions are used in the AdditionalData or RecordItem classes, then the appropriate DTDs must be used. There are numerous free and commercial parsers for virtual all programming languages. Given a properly formatted XML document, any additional constraints on element and attribute cardinality imposed by a data sharing profile SHOULD be applied. o Data Validation. Verification of properly formatted XML document does not guarantee that the data itself is valid. Therefore, the individual element and attribute values must be checked that they conform to the data types specified by the data model (e.g., was an alphanumeric string value specified for a numeric TCP port). A profile might also impose formatting restrictions on the data. o Semantic Validation. Given properly formatted data, its semantics must be verified. This validation may be dictated by the profile specification (e.g., a particular value range), or from external information (e.g., are the timestamps in the future). Discerning the reason why this incident report was sent to the CSIRT and the expected response is key at this phase. o Transformation and Storage. Since IODEF documents must be imported, transformations may need to be applied to the data to convert it to the native representation of the IHS. Once natively formatted, the necessary invocation must be made to write into the data store (e.g., SQL statements). o Post-Processing. In the course of processing IODEF documents useful meta-data can be generated. This meta-information is often useful for work-flow, debugging and audit purposes. An IHS might note in a transaction logs when a document arrived, its size and source. Implementers can chose to store this information external to the IHS, or extend its underlying data store. Furthermore, when a new incident report arrives certain triggers in the IHS may need to be invoked to signal the presence of this new information. Automated analysis tools may be invoked to correlate the new information with the existing data set. Work-flow processes or tasking priorities may need to be adjusted. There will be instances where an IODEF document that cannot be processed is sent to a CSIRT. This situation may be due to invalid XML formatting, or a semantic misunderstanding. The CSIRT must decide how to handle this occurrence. The range of possibilities includes silently dropping these documents to manual intervention by an analyst. The IHS SHOULD keep at least cursory logs of these types Danyliw Expires September 7, 2004 [Page 8] Internet-Draft IODEF Implementation Guide March 2004 of documents. It will allow for debugging, as well as, a way to identify denial of service activity. 3.2 IDMEF relationship 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. For a list of classes from the IDMEF, see the "IDMEF" column of Appendix 1. 3.3 Types of Data Given that the IODEF is implemented in XML, the entire document is a single text string with an encoding specified in the leading XML processing instruction. The data model enforces a structure onto this string by segmenting distinct data into XML elements and attributes each of which is typed. However, the base data type only provides a formatting specification. A richer understanding of the data items found in the IODEF is necessary to process the data in an automated way. It is useful to segregate the various data item based on the different approaches that will be needed to process them. The IODEF data model has items that have the following types of values: enumerated, structured, subjective, free-form, and extensions. Appendix 1 associates a data type with every data item of the IODEF data model. 3.3.1 Enumerated Values An enumerated value is a specified list of possible values for a given data element. They are used when the domain of possible values is fixed. Practically speaking, all enumerated values in the IODEF are XML attributes. For a list of data items that are enumerated values, see those marked as "ENUM" in Appendix 1. In general, processing enumerated types is straightforward, since all possible values are known. However, there are certain enumerated values that provide an escaping mechanism whereby an unspecified value may be represented. This technique involves setting the XML attribute to "other", and encoding the desired value in the PCDATA of the XML element of the attribute. For a full list of such special attributes, see those that are marked as "ENUM+OTHER" in Appendix 1. In order to allow updates, all enumerated lists in the IODEF are registered and maintained by IANA. However, in a closed community, it would not be uncommon to extend an enumerated list by adding community-relevant data values. This addition would have to be noted Danyliw Expires September 7, 2004 [Page 9] Internet-Draft IODEF Implementation Guide March 2004 in the exchange profile, and the corresponding portion of the XML DTD updated. Otherwise, if an unrecognized value is provided for an enumerated value, it should be treated as an invalid XML document. 3.3.2 Structured Values Structured values are the bulk of the IODEF data model. These are data items that have a well-defined format, and unambiguous semantics. The IHS will be able to parse and interpret them with little or no transformation. The specific format of the data is either dictated outright by the data type of the class, or by other information present in the IODEF documents (e.g., the value of an attribute). For a full list of structured values, see the data items marked as "STRUCTURED" in Appendix 1. 3.3.3 Subjective Values Subjective values are identical to structured values with regard to formatting, but they have ambiguous semantics. Interpretation of subjective values requires further specification from a pre-negotiated profile. Since profiles between sites can vary, the semantics of the same value can depend of the profile used. For a full list of the subjective values, see the data items marked as "SUBJECTIVE" in Appendix 1. 3.3.4 Free-form Values Free-form values are text strings with no pre-defined structure used to represent natural language descriptions. These values often represent information too disparate or complex to easily specify. Machine parsing free-form text values to extract meaning is extremely difficult. Peers may agree in a profile to apply structure to these fields whereby imposing formatting constraints. However, short of such additional information, the IHS SHOULD extract these values and store them unmodified for later review by a human analyst. Free-form values can support a variety of natural languages. Hence, associated with each element are two attributes that aid in disambiguating the formatting. While the encoding of the entire XML document is specified in the initial XML processing instruction, free-form XML elements have an attribute named "encoding" that specifies the language encoding to apply to that element. Furthermore, enumerated XML attribute named "lang" allows the specification of the natural language of the element. Due to the processing complexity, free-form values SHOULD be used sparingly, favoring instead the existing structured data model to represent information. Danyliw Expires September 7, 2004 [Page 10] Internet-Draft IODEF Implementation Guide March 2004 For a full list of free-form values, see the data items marked "FREEFORM" in Appendix 1. 3.3.5 Extensions No standardization effort can represent all data elements of interest to its entire community. Hence, the IODEF includes well-defined ways to extend itself. The AdditionalData and RecordItem classes allow arbitrary data to be included in the document. The inclusion of these extensions and the semantics of this information MUST be documented in a profile. If XML extensions are used, then the appropriate DTD will need to be passed to the parser. 3.4 Structure of the Data 3.4.1 Non-deterministic The IODEF data model is non-deterministic in that two of the elements are recursive defined: Contact, and EventData. The implication of such a structure is that fixed XPaths to information might not always be valid. Making use of the recursion allows for a logical grouping of information that eliminated redundancy. The following is a simple example of this concept. TODO: include recursion examples 3.4.2 Document unique idents TODO: what are they used for? to what classes do they apply? 4. Export Considerations In order to share information with other CSIRTs, incident information must be exported from the IHS to the IODEF. 4.1 Processing Algorithm Once the intended recipient of an incident is identified, the process to export and transmit this party an IODEF document can be generalized into four steps. o Query the Incident. Initially, all the relevant data about the incident that will be encoded in the IODEF document must be extracted from the IHS. Based on negotiated profiles, different, or varying level of detail, might be shared about the same incident with different parties. Certain CSIRTs might receive all the information about an incident; another might only receive a Danyliw Expires September 7, 2004 [Page 11] Internet-Draft IODEF Implementation Guide March 2004 subset. If there is any sensitive data that must be sanitized, or classes of information to be filtering for certain parties, the appropriate policy should be enforced. o Reformat the Data. The internal representation of the incident data in the IHS may be quite different that the one used in the IODEF. This transformation may entail explicit reformatting of the individual data items into the IODEF data types. Furthermore, subjective values, if stored in a different way, may need to be remapped onto their equivalents in the IODEF data model and as specified in a data profile (e.g., the profile might specify a priorities from 1 to 4, with 1 being the lowest, but the IHS uses a scheme, were 4 is the lowest). Finally, during this conversion process, implementers must consider XML encoding issues. There are several special characters (see XML reference) that must be escaped. If binary data is included in the AdditionalData or RecordData classes, it must also be escaped. If whitespace is part of a data the xml:preserve attribute must be set correctly in the relevant XML element. A value of "preserve" for this attribute will require the IHS to treat any whitespace as significant. Otherwise, the default value of "default" allows the IHS to treat the whitespace as it likes. o Set Expectations. When sending an IODEF document to another CSIRT, the intent behind this communication and the desired handling of the information should be document. The enumerated attributed "purpose" of the Incident class should be set to convey the reason why this IODEF document was sent to the CSIRT. Likewise the Expectation class MUST be set to encapsulate the expectation the sender has for the recipient. Judicious use of the restriction attribute on the various data items will also allow the sender to convey how they would request their data to be used. With all of these settings, the recipient is free to ignore this information. o Transmission. Given a valid XML document, the proper exchange protocol, as specified in the profile associated with the recipient, will be used to send the document. In the absence of published profile for a recipient, out-of-band mechanisms MUST be used to contact the party to make arrangements. 5. Representation Examples 5.1 Multiple Contacts Danyliw Expires September 7, 2004 [Page 12] Internet-Draft IODEF Implementation Guide March 2004 5.2 Expectation 5.3 Sequence of Events 5.4 XML-Signature 5.5 XML-Encryption 5.6 Non-English example 5.7 Translations 6. Acknowledgments 7. Appendix 1 The following is a list of all elements and attributes of the IODEF and their associated datatypes. Element Name Attribute Datatype Class IDMEF ============================================================================ 1 access-time PCDATA DATETIME STRUCTURED Y 2 AdditionalData ------------ ANY Y type ENUM meaning STRING 3 Address ------------ ---------- ----------- Y vlan-num INTEGER vlan-name STRING ident INTEGER category ENUM 4 address PCDATA STRING Y 5 AlternativeID ------------ ---------- ----------- 6 Analyzer ------------ ---------- ----------- Y version STRING osversion STRING ostype STRING model STRING manufacterer STRING class STRING analyzerid STRING 7 arg PCDATA STRING Y 8 Assessment ------------ ---------- ------------ 9 cgi PCDATA STRING Y 10 change-time PCDATA DATETIME Y 11 Classification ----------- ---------- ------------ origin ENUM + O Danyliw Expires September 7, 2004 [Page 13] Internet-Draft IODEF Implementation Guide March 2004 12 c-major-device PCDATA INTEGER Y 13 c-minor-device PCDATA INTEGER Y 14 command PCDATA STRING Y 15 community PCDATA STRING Y 16 Confidence PCDATA REAL rating ENUM 17 Contact ------------ ---------- ------------ contacttype ENUM contactrole ENUM 18 create-time PCDATA DATETIME Y 19 data-size PCDATA INTEGER Y 20 DateTime PCDATA DATETIME 21 Description PCDATA STRING transform ENUM preserve ENUM lang ENUM 22 DetectTime PCDATA DATETIME ntpstamp NTPSTAMP 23 disk-size PCDATA INTEGER Y 24 Email PCDATA EMAIL 25 EndTime PCDATA DATETIME ntpstamp NTPSTAMP 26 env PCDATA STRING Y 27 EventData ------------ ---------- ------------ 28 Expectation ------------ ---------- ------------ priority ENUM category ENUM 29 Fax PCDATA PHONE 30 File ------------ ---------- ------------ Y ident STRING fstype STRING category ENUM 31 FileAccess ------------ ---------- ------------ Y 32 FileList ------------ ---------- ------------ Y category ENUM 33 History ----------- --------- ------------ type ENUM+O 34 HistoryItem ------------ ---------- ------------ 35 http-method PCDATA STRING Y 36 Impact PCDATA STRING type ENUM+O severity ENUM lang ENUM completion ENUM 37 Incident ------------ ---------- ------------ purpose ENUM+O 38 IncidentData ------------ ---------- ------------ 39 IncidentID PCDATA UID Danyliw Expires September 7, 2004 [Page 14] Internet-Draft IODEF Implementation Guide March 2004 name GUID 40 Inode ------------ ---------- ------------ Y 41 IODEF-Document ------------ ---------- ------------ version STRING 42 LifeImpact PCDATA INTEGER severity ENUM metric ENUM 43 Linkage ------------ ---------- ------------ Y category ENUM 44 Location PCDATA STRING lang ENUM 45 major-device PCDATA STRING Y 46 minor-device PCDATA STRING Y 47 Method ------------ ---------- ------------ 48 modify-time PCDATA DATETIME Y 49 MonetaryImpact PCDATA REAL severity ENUM currency ENUM 50 Name PCDATA STRING transform ENUM preserve ENUM lang ENUM 51 name PCDATA STRING lang ENUM 52 netmask PCDATA STRING Y 53 Node ------------ ---------- ------------ category ENUM 54 NodeRole PCDATA STRING lang ENUM category ENUM+O 55 number PCDATA INTEGER Y 56 oid PCDATA STRING Y 57 path PCDATA STRING Y 58 pid PCDATA STRING Y 59 port PCDATA INTEGER Y 60 portlist PCDATA PORTLIST Y 61 PostalAddresss PCDATA POSTAL lang ENUM 62 Process ------------ ---------- ------------ Y ident STRING 63 protocol PCDATA STRING Y 64 Record ------------ ---------- ------------ 65 RecordData ------------ ---------- ------------ ident STRING 66 RecordItem PCDATA ANY dtype ENUM 67 RegistryHandle PCDATA STRING type ENUM Danyliw Expires September 7, 2004 [Page 15] Internet-Draft IODEF Implementation Guide March 2004 68 RelatedActivity ------------ ---------- ------------ 69 ReportTime PCDATA DATETIME ntpstamp NTPSTAMP 70 Service PCDATA STRING Y ident STRING 71 SNMPService PCDATA Y 72 StartTime PCDATA DATETIME ntpstamp NTPSTAMP 73 System ----------- ---------- ------------ spoofed ENUM interface STRING category ENUM 74 Telephone PCDATA PHONE TimeImpact PCDATA REAL unit ENUM severity ENUM metric INTEGER 75 TimeZone PCDATA STRING 76 url PCDATA STRING Y 77 User ------------ ---------- ----------- Y ident STRING category ENUM 78 UserID PCDATA STRING Y type ENUM ident STRING 79 WebService PCDATA STRING Y Figure 1 Normative References [1] Demchenko, Y., Hiroyuki, H. and G. Keeni, "Requirements for Format for Incident Report Exchange", RFC XXX, September 2003. [2] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0 (Second Edition)", , October 2000, . [3] World Wide Web Consortium, "Extensible Stylesheet Language (XSL) Version 1.0", , October 2001, . [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [5] Alvestrand, H., "Tags for the Identification of Languages", RFC 3066, January 2001. Danyliw Expires September 7, 2004 [Page 16] Internet-Draft IODEF Implementation Guide March 2004 [6] Curry, D. and H. Debar, "Intrusion Detection Message Exchange Format", RFC XXX, January 2003. [7] Meijer, J., Danyliw, R. and Y. Demchenko, "Intrusion Detection Message Exchange Format", RFC XXX, January 2003. [8] Eastlake 3rd, D., Reagle, J. and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002. [9] Imamura, T., Dillaway, B. and E. Simon, "XML Encryption Syntax and Processing, W3C Recommendation", December 2002, . Informative References Author's Address Roman Danyliw CERT Coordination Center 4500 Fifth Ave. Pittsburgh, PA 15213 USA Phone: +1 412 268 7090 EMail: rdd@cert.org Danyliw Expires September 7, 2004 [Page 17] Internet-Draft IODEF Implementation Guide March 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Danyliw Expires September 7, 2004 [Page 18] Internet-Draft IODEF Implementation Guide March 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Danyliw Expires September 7, 2004 [Page 19]