idnits 2.17.1 draft-ietf-inch-implement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 109 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 09, 2004) is 7105 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 707, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 712, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 718, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 721, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 727, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 731, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 3066 (ref. '5') (Obsoleted by RFC 4646, RFC 4647) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 15 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INCH Working Group R. Danyliw 2 draft-ietf-inch-implement-01.txt CERT Coordination Center 3 Expires: May 10, 2005 November 09, 2004 5 The Incident Object Description Exchange Format (IODEF) 6 Implementation Guide 7 draft-ietf-inch-implement-01 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, or 13 will be disclosed, and any of which I become aware will be disclosed, 14 in accordance with RFC 3668. 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 10, 2005. 37 Abstract 39 The purpose of this Internet-Draft is to provide implementation 40 guidelines for Computer Security Incident Response Teams (CSIRT) 41 adopting the Incident Object Description Exchange Format (IODEF). 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.3 CSIRT Operations . . . . . . . . . . . . . . . . . . . . . 3 49 2. General Integration Considerations . . . . . . . . . . . . . . 5 50 2.1 Unique Identifiers . . . . . . . . . . . . . . . . . . . . 5 51 2.2 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 2.2.1 Required Data . . . . . . . . . . . . . . . . . . . . 6 53 2.2.2 Semantics . . . . . . . . . . . . . . . . . . . . . . 6 54 2.2.3 Formatting . . . . . . . . . . . . . . . . . . . . . . 7 55 2.2.4 Transport issues . . . . . . . . . . . . . . . . . . . 7 56 2.3 Updating Incident Data . . . . . . . . . . . . . . . . . . 7 57 3. Importing and Processing Considerations . . . . . . . . . . . 8 58 3.1 Processing Algorithm . . . . . . . . . . . . . . . . . . . 8 59 3.2 IDMEF relationship . . . . . . . . . . . . . . . . . . . . 9 60 3.3 Types of Data . . . . . . . . . . . . . . . . . . . . . . 9 61 3.3.1 Enumerated Values . . . . . . . . . . . . . . . . . . 10 62 3.3.2 Structured Values . . . . . . . . . . . . . . . . . . 10 63 3.3.3 Subjective Values . . . . . . . . . . . . . . . . . . 10 64 3.3.4 Free-form Values . . . . . . . . . . . . . . . . . . . 11 65 3.3.5 Extensions . . . . . . . . . . . . . . . . . . . . . . 11 66 3.4 Structure of the Data . . . . . . . . . . . . . . . . . . 11 67 3.4.1 Non-deterministic . . . . . . . . . . . . . . . . . . 11 68 3.4.2 Document unique idents . . . . . . . . . . . . . . . . 12 69 4. Export Considerations . . . . . . . . . . . . . . . . . . . . 13 70 4.1 Processing Algorithm . . . . . . . . . . . . . . . . . . . 13 71 5. Representation Examples . . . . . . . . . . . . . . . . . . . 15 72 5.1 Multiple Contacts . . . . . . . . . . . . . . . . . . . . 15 73 5.2 Expectation . . . . . . . . . . . . . . . . . . . . . . . 15 74 5.3 Sequence of Events . . . . . . . . . . . . . . . . . . . . 15 75 5.4 Summarization using the Counter class . . . . . . . . . . 15 76 5.5 XML-Signature . . . . . . . . . . . . . . . . . . . . . . 15 77 5.6 XML-Encryption . . . . . . . . . . . . . . . . . . . . . . 15 78 5.7 Non-English example . . . . . . . . . . . . . . . . . . . 15 79 5.8 Translations . . . . . . . . . . . . . . . . . . . . . . . 15 80 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 81 7. Appendix 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20 85 Intellectual Property and Copyright Statements . . . . . . . . 21 87 1. Introduction 89 1.1 Terminology 91 The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," 92 "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this 93 document are to be interpreted as described in RFC2119 [4]. 95 Definitions for some of the common computer security-related 96 terminology used in this document can be found in Section 2 of [1]. 98 1.2 Overview 100 The Incident Object Description Exchange Format (IODEF) [7] is an 101 abstract data model for representing computer security incidents 102 exchanged by Computer Security Incident Response Teams (CSIRTs). It 103 was designed to satisfy the requirements laid out in [1]. 104 Practically, [7] also provides an XML DTD (soon to be Schema) 105 implementation of the data model. 107 The purpose of this document is to provide additional informati 108 on for 109 IODEF implementers. Section 1 outlines the operational assumptions 110 and context in which the IODEF will be used. Section 2 discusses 111 general issues related to exchanging IODEF documents. The importing 112 and exporting IODEF documents with an IHS is covered in detail in 113 Section 3 and 4, respectively. Section 5 provides useful examples of 114 IODEF usage for given situations. 116 This draft is incomplete. There are several sections marked as 117 "TODO" either the document author has not completed the text, or the 118 working group needs to provide clarification. 120 1.3 CSIRT Operations 122 The key function of a CSIRT is to remediate security activity in 123 their constituency. As security events can occur across 124 administrative domains, CSIRTs also often play a coordination role to 125 resolve incidents. In the IODEF context, a CSIRT is defined very 126 broadly to include almost any entity that might exchange incident 127 information. For example, this role might be fulfilled by a single 128 security analyst in a network operations group, a help-desk operation 129 center, or a national-level CSIRT. 131 CSIRTs with responsibility over networks often build their operations 132 around a system to manage the entire incident life-cycle. This 133 incident handling system (IHS) must store all incident information 134 and related communications; provide primitives to support the 135 work-flow of the analysts; and tools to analyze the reported incident 136 data. It is commonly built around a ticket-tracking application 137 adapted for a security role. The underlying data store is typically 138 a relational database. See section 3 of [1] for additional details 139 about the implicit operational assumptions for the IODEF. 141 The IODEF is agnostic to most of the internal process and technology 142 choices made by a CSIRT. The IODEF provides no improvements for user 143 interface issues or new analytical techniques. It is in the 144 communications with other parties that the IODEF can have an impact 145 on operations. The current collaboration model requires significant 146 effort to process incident reports because of a lack of 147 standardization in incident information. The IODEF can simplify some 148 of this communication by providing a well-documented format and 149 structure, published as an XML DTD, to represent the incident data 150 already being exchanged. 152 The IODEF is not a replacement for all communication in and across 153 constituencies. Any common format is useful when there is a need to 154 inter-operate. Inside an organization, where processes can be 155 mandated by fiat, standardization occurs implicitly. The value of 156 IODEF comes when there is a need to exchange information across 157 administrative domain. That said, the IODEF is not suitable for all 158 users. The format is complex, making it unlikely that IODEF 159 documents will be generated by hand as done with many incident 160 reports today. Therefore, it will largely be employed only by a more 161 sophisticated set of users that have the knowledge to reformat their 162 incident data. In the foreseeable future, there will be a continued 163 need to support free-form reporting mechanisms. As a middle ground, 164 front-end tools gathering incident data (e.g., web forms) can be 165 developed to export IODEF documents. 167 2. General Integration Considerations 169 Integrating the IODEF into a CSIRT requires changing the IHS to 170 import and export IODEF documents. Effectively, this capability 171 involves the ability to convert from the native IHS data format to 172 XML, and vice versa. Since it merely introduces another 173 representation for existing data, the underlying storage mechanism 174 and schema of the IHS need not be changed to accommodate the IODEF. 175 Furthermore, the use of the IODEF as the explicit storage or archive 176 format is not recommended due to the space inefficiency of XML. 177 Importing IODEF documents will allow a CSIRT to rapidly process newly 178 reported incident information since the barriers of the semantics 179 ambiguity and data normalization will not be present. Exporting 180 IODEF documents allows a CSIRT to unambiguously share information 181 with collaborators. This capability becomes especially relevant when 182 coordinating with a CSIRT with whom no prior relationship might 183 exist. 185 2.1 Unique Identifiers 187 CSIRTs track incidents by assigning each an identifier unique in 188 context of its constituency. In the IODEF data model, this 189 identifier is represented by the mandatory IncidentID class. It is 190 through this identifier that an IODEF document relates to the IHS. 191 It is possible that this same activity could be reported to another 192 CSIRT that in turn assigns its own unique identifier. Each CSIRT 193 associates their own identifier for the identical incident in their 194 respective IHS. However, to provide a framework for CSIRTs to refer 195 to each other's data, the IODEF provides the optional AlternateID 196 class to represent another CSIRT's tracking identifier for the same 197 activity. Combining the name of a CSIRT and the incident identifier 198 provides a globally unique identifier for an incident. 200 TODO: How are IncidentIDs generated? What is the convention? 202 It may be possible that multiple IODEF documents are exchanged about 203 the same incident over its lifetime. Hence, the use of the id 204 attribute of the IODEF-Document to uniquely identify a particular 205 IODEF document. This global identifier is only relevant for the 206 purposes of transport (e.g., duplicate detection, retransmission). 207 It will change with each new IODEF document, regardless of the value 208 of the IncidentID class value. 210 TODO: Can an /IODEF-Document@id ever be reused? how is it generated? 211 Is it globally unique? 213 2.2 Profiles 215 While the IODEF data model is unambiguous, the usage and the 216 semantics of the data will need to be further refined for a community 217 of collaborators if incident data is to be exchanged. These data 218 exchange policies are collectively referred to as a profile. The 219 need for profiles, in addition to the format specification, is due to 220 the wide variety of data that might be represented in an IODEF 221 document. A well-specified profile is the key to machine-parsing the 222 exchanged documents. 224 A CSIRT may choose to publicly publish a profile for use by anyone 225 wishing to communicate information to it. Such a model is helpful in 226 a CSIRT with a wide constituency that might receive unsolicited 227 reports. Likewise, in a smaller, closed community of CSIRTs, 228 specific arrangements that apply only to the respective parties can 229 be made. These profiles may cover organizational specific 230 information that the parties will be sharing. Since a CSIRT may send 231 IODEF documents to many other CSIRTS, it will have to maintain many 232 profiles, each specific to the intended recipient. 234 The format for specifying a profile is outside the scope of this 235 document and the INCH working group. However, Section 2.2.1 to 236 Section 2.2.4 provide a cursory description of the types of 237 information that should be included in a profile. 239 2.2.1 Required Data 241 A profile MUST specify exactly the data that will be exchanged 242 between peers. The IODEF specification mandates the presence of 243 certain fields, but the profile should go further to define which 244 optional fields are required. There is no point in sending data that 245 a peer mig 246 ht not be interested in collected. Likewise, insufficient 247 information will require a follow-up communication. 249 Incident reports documenting different types of activity are not 250 composed of the same type of data. For example, the data needed to 251 describe an administrative compromise might be different from that of 252 a policy violation. Therefore, a profile could distinguish between 253 the different types of incidents and specify different mandatory 254 fields for each. 256 2.2.2 Semantics 258 Given the XML DTD and the profile, the recipient of an IODEF document 259 should be able to understand the contents. A profile MUST 260 disambiguate the semantics of all the subjective values (see Section 261 3.3.3) that are exchanged. When not compromising the intent of the 262 transformation, any sanitization performed on the data SHOULD be 263 documented. Naming conventions for data commonly found in CSIRTs 264 (e.g., incident numbers) SHOULD be documented. 266 2.2.3 Formatting 268 To the the degree possible, formatting conventions SHOULD be 269 standardized to aid in machine processing of IODEF documents. This 270 specification is especially relevant when dealing with the free-form 271 values (see Section 3.3.4). Agreeing on a natural language for these 272 fields is also helpful within a diverse community. 274 In addition the format of the content itself, the overall structure 275 of the IODEF document should be documented. Given that the data 276 model is non-deterministic (see Section 3.4.1), the profile SHOULD 277 specify the required way to represent the information. 279 2.2.4 Transport issues 281 In the absence of an IODEF transport protocol, the profile MUST 282 document how the peers will exchange the IODEF documents. The choice 283 of protocols must take into account the properties of the XML IODEF 284 documents. Ideally the channel between parties would provide 285 reliable delivery, compression of the text stream, confidentiality, 286 integrity, and authenticity. Non-repudiation may be desirable in 287 certain situations. 289 The process surrounding the use of the protocol will also need to be 290 specified. The frequency of incident data exchange SHOULD be 291 specified (e.g., batched at pre-determined intervals, or real-time). 292 If cryptography is used, key management issues must be addressed. 293 Choices of trust models must be decided; will trust be based on a 294 hierarchy (ala, a PKI) or a web-of-trust (ala, PGP). 296 Existing data exchange practices in CSIRT operations commonly make 297 use of SOAP, TLS, or PGP encrypted and signed email messages. 299 2.3 Updating Incident Data 301 TODO: The working group needs to decide how to perform updates, if at 302 all 304 3. Importing and Processing Considerations 306 Upon receiving an IODEF document, the IHS must process it so that 307 normal work-flow processes can be applied. The task of importing an 308 IODEF document involves extracting the relevant data and storing it 309 in the IHS. 311 3.1 Processing Algorithm 313 The processing of IODEF documents can be generalized into five steps. 314 Depending on the specific exchange protocols used, and the particular 315 IHS, certain steps may not be necessary. 317 o Accepting the document. IODEF documents will likely be exchanged 318 over a cryptographically secured medium. Prior to even examining 319 the document, it may need to be decrypted. If the underlying 320 transport does not already handling the issues of key management, 321 the IHS must provide the correct decryption key. It may be 322 necessary to use external information or properties of the 323 document itself to determine the proper key to use. When 324 possible, the authenticity of the document from the sender must 325 also be verified (e.g., via public key signatures). If 326 confidentiality and integrity are implemented via XML-Encryption 327 and XML-Signature, validation of the XML MUST occur prior to this 328 step. 330 o Structural Validation. To confirm proper formatting, the document 331 must be examined with an XML parser to check that it is both 332 well-formed and valid according to the IODEF DTD. If XML 333 extensions are used in the AdditionalData or RecordItem classes, 334 then the appropriate DTDs must be used. There are numerous free 335 and commercial parsers for virtual all programming languages. 336 Given a properly formatted XML document, any additional 337 constraints on element and attribute cardinality imposed by a data 338 sharing profile SHOULD be applied. 340 o Data Validation. Verification of properly formatted XML document 341 does not guarantee that the data itself is valid. Therefore, the 342 individual element and attribute values must be checked that they 343 conform to the data types specified by the data model (e.g., was 344 an alphanumeric string value specified for a numeric TCP port). A 345 profile might also impose formatting restrictions on the data. 347 o Semantic Validation. Given properly formatted data, its semantics 348 must be verified. This validation may be dictated by the profile 349 specification (e.g., a particular value range), or from external 350 information (e.g., are the timestamps in the future). Discerning 351 the reason why this incident report was sent to the CSIRT and the 352 expected response is key at this phase. 354 o Transformation and Storage. Since IODEF documents must be 355 imported, transformations may need to be applied to the data to 356 convert it to the native representation of the IHS. Once natively 357 formatted, the necessary invocation must be made to write into the 358 data store (e.g., SQL statements). 360 o Post-Processing. In the course of processing IODEF documents 361 useful meta-data can be generated. This meta-information is often 362 useful for work-flow, debugging and audit purposes. An IHS might 363 note in a transaction logs when a document arrived, its size and 364 source. Implementers can chose to store this information external 365 to the IHS, or extend its underlying data store. Furthermore, 366 when a new incident report arrives certain triggers in the IHS may 367 need to be invoked to signal the presence of this new information. 368 Automated analysis tools may be invoked to correlate the new 369 information with the existing data set. Work-flow processes or 370 tasking priorities may need to be adjusted. 372 There will be instances where an IODEF document that cannot be 373 processed is sent to a CSIRT. This situation may be due to invalid 374 XML formatting, or a semantic misunderstanding. The CSIRT must 375 decide how to handle this occurrence. The range of possibilities 376 includes silently dropping these documents to manual intervention by 377 an analyst. The IHS SHOULD keep at least cursory logs of these types 378 of documents. It will allow for debugging, as well as, a way to 379 identify denial of service activity. 381 3.2 IDMEF relationship 383 In constructing the IODEF data model, certain classes were reused 384 from the IDMEF. Therefore, their description was not included in the 385 specification. Instead referencing the IDMEF specification is 386 required. The relevant portions of the IDMEF DTD were copied 387 outright into the IODEF DTD for completeness. For a list of classes 388 from the IDMEF, see the "IDMEF" column of Appendix 1. 390 3.3 Types of Data 392 Given that the IODEF is implemented in XML, the entire document is a 393 single text string wit 394 h an encoding specified in the leading XML 395 processing instruction. The data model enforces a structure onto 396 this string by segmenting distinct data into XML elements and 397 attributes each of which is typed. However, the base data type only 398 provides a formatting specification. A richer understanding of the 399 data items found in the IODEF is necessary to process the data in an 400 automated way. It is useful to segregate the various data item based 401 on the different approaches that will be needed to process them. The 402 IODEF data model has items that have the following types of values: 403 enumerated, structured, subjective, free-form, and extensions. 404 Appendix 1 associates a data type with every data item of the IODEF 405 data model. 407 3.3.1 Enumerated Values 409 An enumerated value is a specified list of possible values for a 410 given data element. They are used when the domain of possible values 411 is fixed. Practically speaking, all enumerated values in the IODEF 412 are XML attributes. For a list of data items that are enumerated 413 values, see those marked as "ENUM" in Appendix 1. 415 In general, processing enumerated types is straightforward, since all 416 possible values are known. However, there are certain enumerated 417 values that provide an escaping mechanism whereby an unspecified 418 value may be represented. This technique involves setting the XML 419 attribute to "other", and encoding the desired value in the PCDATA of 420 the XML element of the attribute. For a full list of such special 421 attributes, see those that are marked as "ENUM+OTHER" in Appendix 1. 423 In order to allow updates, all enumerated lists in the IODEF are 424 registered and maintained by IANA. However, in a closed community, 425 it would not be uncommon to extend an enumerated list by adding 426 community-relevant data values. This addition would have to be noted 427 in the exchange profile, and the corresponding portion of the XML DTD 428 updated. Otherwise, if an unrecognized value is provided for an 429 enumerated value, it should be treated as an invalid XML document. 431 3.3.2 Structured Values 433 Structured values are the bulk of the IODEF data model. These are 434 data items that have a well-defined format, and unambiguous 435 semantics. The IHS will be able to parse and interpret them with 436 little or no transformation. The specific format of the data is 437 either dictated outright by the data type of the class, or by other 438 information present in the IODEF documents (e.g., the value of an 439 attribute). For a full list of structured values, see the data items 440 marked as "STRUCTURED" in Appendix 1. 442 3.3.3 Subjective Values 444 Subjective values are identical to structured values with regard to 445 formatting, but they have ambiguous semantics. Interpretation of 446 subjective values requires further specification from a 447 pre-negotiated profile. Since profiles between sites can vary, the 448 semantics of the same value can depend of the profile used. For a 449 full list of the subjective values, see the data items marked as 450 "SUBJECTIVE" in Appendix 1. 452 3.3.4 Free-form Values 454 Free-form values are text strings with no pre-defined structure used 455 to represent natural language descriptions. These values often 456 represent information too disparate or complex to easily specify. 457 Machine parsing free-form text values to extract meaning is extremely 458 difficult. Peers may agree in a profile to apply structure to these 459 fields whereby imposing formatting constraints. However, short of 460 such additional information, the IHS SHOULD extract these values and 461 store them unmodified for later review by a human analyst. 463 Free-form values can support a variety of natural languages. Hence, 464 associated with each element are two attributes that aid in 465 disambiguating the formatting. While the encoding of the entire XML 466 document is specified in the initial XML processing instruction, 467 free-form XML elements have an attribute named "encoding" that 468 specifies the language encoding to apply to that element. 469 Furthermore, enumerated XML attribute named "lang" allows the 470 specification of the natural language of the element. 472 Due to the processing complexity, free-form values SHOULD be used 473 sparingly, favoring instead the existing structured data model to 474 represent information. 476 For a full list of free-form values, see the data items marked 477 "FREEFORM" in Appendix 1. 479 3.3.5 Extensions 481 No standardization effort can represent all data elements of interest 482 to its entire community. Hence, the IODEF includes well-defined ways 483 to extend itself. The AdditionalData and RecordItem classes allow 484 arbitrary data to be included in the document. The inclusion of 485 these extensions and the semantics of this information MUST be 486 documented in a profile. If XML extensions are used, then the 487 appropriate DTD will need to be passed to the parser. 489 3.4 Structure of the Data 491 3.4.1 Non-deterministic 493 The IODEF data model is non-deterministic in that two of the elements 494 are recursive defined: Contact, and EventData. The implication of 495 such a structure is that fixed XPaths to information might not always 496 be valid. Making use of the recursion allows for a logical grouping 497 of information that eliminated redundancy. The following is a simple 498 example of this concept. 500 TODO: include recursion examples 502 3.4.2 Document unique idents 504 TODO: what are they used for? to what classes do they apply? 506 4. Export Considerations 508 In order to share information with other CSIRTs, incident information 509 must be exported from the IHS to the IODEF. 511 4.1 Processing Algorithm 513 Once the intended recipient of an incident is identified, the process 514 to export and transmit this party an IODEF document can be 515 generalized into four steps. 517 o Query the Incident. Initially, all the relevant data about the 518 incident that will be encoded in the IODEF document must be 519 extracted from the IHS. Based on negotiated profiles, different, 520 or varying level of detail, might be shared about the same 521 incident with different parties. Certain CSIRTs might receive all 522 the information about an incident; another might only receive a 523 subset. If there is any sensitive data that must be sanitized, or 524 classes of information to be filtering for certain parties, the 525 appropriate policy should be enforced. 527 o Reformat the Data. The internal representation of the incident 528 data in the IHS may be quite different that the one used in the 529 IODEF. This transformation may entail explicit reformatting of 530 the individual data items into the IODEF data types. Furthermore, 531 subjective values, if stored in a different way, may need to be 532 remapped onto their equivalents in the IODEF data model and as 533 specified in a data profile (e.g., the profile might specify a 534 priorities from 1 to 4, with 1 being the lowest, but the IHS uses 535 a scheme, were 4 is the lowest). Finally, during this conversion 536 process, implementers must consider XML encoding issues. There 537 are several special characters (see XML reference) that must be 538 escaped. If binary data 539 is included in the AdditionalData or 540 RecordData classes, it must also be escaped. If whitespace is 541 part of a data the xml:preserve attribute must be set correctly in 542 the relevant XML element. A value of "preserve" for this 543 attribute will require the IHS to treat any whitespace as 544 significant. Otherwise, the default value of "default" allows the 545 IHS to treat the whitespace as it likes. 547 o Set Expectations. When sending an IODEF document to another 548 CSIRT, the intent behind this communication and the desired 549 handling of the information should be document. The enumerated 550 attributed "purpose" of the Incident class should be set to convey 551 the reason why this IODEF document was sent to the CSIRT. 552 Likewise the Expectation class MUST be set to encapsulate the 553 expectation the sender has for the recipient. Judicious use of 554 the restriction attribute on the various data items will also 555 allow the sender to convey how they would request their data to be 556 used. With all of these settings, the recipient is free to ignore 557 this information. 559 o Transmission. Given a valid XML document, the proper exchange 560 protocol, as specified in the profile associated with the 561 recipient, will be used to send the document. In the absence of 562 published profile for a recipient, out-of-band mechanisms MUST be 563 used to contact the party to make arrangements. 565 5. Representation Examples 567 5.1 Multiple Contacts 569 5.2 Expectation 571 5.3 Sequence of Events 573 5.4 Summarization using the Counter class 575 5.5 XML-Signature 577 5.6 XML-Encryption 579 5.7 Non-English example 581 5.8 Translations 582 6. Acknowledgments 583 7. Appendix 1 585 The following is a list of all elements and attributes of the IODEF 586 and their associated datatypes. 588 Element Name Attribute Datatype Type IDMEF 589 ============================================================================ 590 1 AdditionalData ------------ ANY FREEFORM Y 591 type ENUM STRUCTURED 592 meaning STRING FREEFORM 593 2 Address PCDATA STRING FREEFORM 594 vlan-num INTEGER FREEFORM 595 vlan-name STRING FREEFORM 596 category ENUM STRUCTURED 597 3 AlternativeID ------------ ---------- ----------- 598 4 Analyzer ------------ ---------- ----------- Y 599 version STRING FREEFORM Y 600 osversion STRING FREEFORM Y 601 ostype STRING FREEFORM Y 602 model STRING FREEFORM Y 603 manufacterer STRING FREEFORM Y 604 class STRING FREEFORM Y 605 analyzerid STRING FREEFORM Y 606 5 arg PCDATA STRING FREEFORM Y 607 6 Assessment ------------ ---------- ------------ 608 7 Classification ----------- ---------- ------------ 609 origin ENUM + O STRUCTURED 610 8 command PCDATA STRING FREEFORM Y 611 9 Confidence PCDATA REAL SUBJECTIVE Y 612 rating ENUM SUBJECTIVE Y 613 10 Contact ------------ ---------- ------------ 614 contacttype ENUM STRUCTURED 615 contactrole ENUM STRUCTURED 616 11 Counter PCDATA INTEGER STRUCTURED 617 type ENUM STRUCTURED 618 meaning STRING FREEFORM 619 12 DateTime PCDATA DATETIME STRUCTURED 620 13 Description PCDATA STRING FREEFORM 621 transform ENUM STRUCTURED 622 preserve ENUM STRUCTURED 623 lang ENUM STRUCTURED 624 14 DetectTime PCDATA DATETIME STRUCTURED 625 15 Email PCDATA EMAIL STRUCTURED 626 16 EndTime PCDATA DATETIME STRUCTURED 627 17 env PCDATA STRING FREEFORM Y 628 18 EventData ------------ ---------- ------------ 629 19 Expectation ------------ ---------- ------------ 630 priority ENUM SUBJECTIVE 631 category ENUM STRUCTURED 632 20 Fax PCDATA PHONE STRUCTURED 633 21 Flow ----------- --------- ------------ 634 22 History ----------- --------- ------------ 635 type ENUM+O STRUCTURED 636 23 HistoryItem ------------ ---------- ------------ 637 24 Impact PCDATA STRING FREEFORM Y 638 type ENUM+O STRUCTURED Y 639 severity ENUM SUBJECTIVE Y 640 lang ENUM STRUCTURED Y 641 completion ENUM STRUCTURED Y 642 25 Incident ------------ ---------- ------------ 643 purpose ENUM+O STRUCTURED 644 26 IncidentID PCDATA UID SUBJECTIVE 645 name GUID STRUCTURED 646 27 IODEF-Document ------------ ---------- ------------ 647 version STRING STRUCTURED 648 28 Location PCDATA STRING FREEFORM 649 lang ENUM STRUCTURED 650 29 Method ------------ ---------- ------------ 651 30 MonetaryImpact PCDATA REAL STRUCTURED 652 severity ENUM SUBJECTIVE 653 currency ENUM STRUCTURED 654 31 Name PCDATA STRING STRUCTURED 655 transform ENUM STRUCTURED 656 preserve ENUM STRUCTURED 657 lang ENUM STRUCTURED 658 32 name PCDATA STRING FREEFORM 659 lang ENUM STRUCTURED 660 33 Node ------------ ---------- ------------ 661 category ENUM STRUCTURED 662 34 NodeRole PCDATA STRING FREEFORM 663 lang ENUM STRUCTURED 664 category ENUM+O STRUCTURED 665 35 path PCDATA STRING FREEFORM Y 666 36 pid PCDATA STRING FREEFORM Y 667 37 port PCDATA INTEGER STRUCTURED Y 668 38 portlist PCDATA PORTLIST STRUCTURED Y 669 39 PostalAddresss PCDATA POSTAL STRUCTURED 670 lang ENUM STRUCTURED 671 40 Process ------------ ---------- ------------ Y 672 ident STRING FREEFORM 673 41 Record ------------ ---------- ------------ 674 42 RecordData ------------ ---------- ------------ 675 ident STRING FREEFORM 676 43 RecordItem PCDATA ANY FREEFORM 677 dtype ENUM STRUCTURED 678 44 RegistryHandle PCDATA STRING FREEFORM 679 type ENUM STRUCTURED 680 45 RelatedActivity ------------ ---------- ------------ 681 46 ReportTime PCDATA DATETIME STRUCTURED 682 47 Service ------------ ---------- ------------ 683 ip_version INTEGER STRUCTURED 684 ip_protocol INTEGER STRUCTURED 685 48 StartTime PCDATA DATETIME STRUCTURED 686 49 System ----------- ---------- ------------ 687 spoofed ENUM STRUCTURED 688 interface STRING FREEFORM 689 category ENUM STRUCTURED 690 50 Telephone PCDATA PHONE STRUCTURED 691 51 TimeImpact PCDATA REAL STRUCTURED 692 unit ENUM STRUCTURED 693 severity ENUM SUBJECTIVE 694 metric INTEGER STRUCTURED 695 52 TimeZone PCDATA STRING STRUCTURED 696 53 url PCDATA STRING STRUCTURED Y 698 Figure 1 700 8. References 702 8.1 Normative References 704 [1] Demchenko, Y., Hiroyuki, H. and G. Keeni, "Requirements for 705 Format for Incident Report Exchange", RFC XXX, September 2003. 707 [2] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0 709 (Second Edition)", , October 2000, 710 . 712 [3] World Wide Web Consortium, "Extensible Stylesheet Language (XSL) 713 Version 1.0", , October 2001, . 715 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 716 Levels", RFC 2119, March 1997. 718 [5] Alvestrand, H., "Tags for the Identification of Languages", RFC 719 3066, January 2001. 721 [6] Curry, D. and H. Debar, "Intrusion Detection Message Exchange 722 Format", RFC XXX, January 2003. 724 [7] Meijer, J., Danyliw, R. and Y. Demchenko, "Intrusion Detection 725 Message Exchange Format", RFC XXX, January 2003. 727 [8] Eastlake 3rd, D., Reagle, J. and D. Solo, "(Extensible Markup 728 Language) XML-Signature Syntax and Processing", RFC 3275, March 729 2002. 731 [9] Imamura, T., Dillaway, B. and E. Simon, "XML Encryption Syntax 732 and Processing, W3C Recommendation", December 2002, 733 . 735 Author's Address 737 Roman Danyliw 738 CERT Coordination Center 739 4500 Fifth Ave. 740 Pittsburgh, PA 15213 741 USA 742 EMail: rdd@cert.org 744 Full Copyright Statement 746 Copyright (C) The Internet Society (2004). This document is subject 747 to the rights, licenses and restrictions contained in BCP 78, and 748 except as set forth therein, the authors retain all their rights. 750 This document and the information contained herein are provided on an 751 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE REPRESENTS 752 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 753 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 754 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 755 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 756 FOR A PARTICULAR PURPOSE.