idnits 2.17.00 (12 Aug 2021) /tmp/idnits36661/draft-meijer-inch-iodef-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 8 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 12 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([2], [3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 28 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (April 2002) is 7334 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'IDMEF' on line 4492 -- Looks like a reference, but probably isn't: 'RFC2045' on line 4932 -- Looks like a reference, but probably isn't: 'RFC1766' on line 4937 -- Looks like a reference, but probably isn't: 'ISO10646' on line 4941 == Unused Reference: '8' is defined on line 5661, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 5700, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3067 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2396 (ref. '8') (Obsoleted by RFC 3986) == Outdated reference: draft-mealling-iana-xmlns-registry has been published as RFC 3688 -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 2278 (ref. '11') (Obsoleted by RFC 2978) ** Obsolete normative reference: RFC 3066 (ref. '12') (Obsoleted by RFC 4646, RFC 4647) -- Possible downref: Non-RFC (?) normative reference: ref. '13' ** Obsolete normative reference: RFC 1305 (ref. '14') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2030 (ref. '15') (Obsoleted by RFC 4330) == Outdated reference: draft-ietf-xmldsig-core has been published as RFC 3075 -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INCH Working Group J.J. Meijer 2 INTERNET-DRAFT SURFnet bv 3 Expires in six months R. Danyliw 4 CERT Coordination Center 5 Y. Demchenko 6 TERENA 7 April 2002 9 Incident Object Description and Exchange Format 10 Data Model and Extensible Markup Language (XML) 11 Document Type Definition 12 14 Status of this Memo 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 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use 27 Internet-Drafts as reference material or to cite them other than 28 as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Distribution of this memo is unlimited. 38 This Internet Draft expires October, 2002. 40 Copyright Notice 42 Copyright (C) The Internet Society (2001). All Rights Reserved. 44 Abstract 46 The purpose of the Incident Object Description and Exchange Format is 47 to define a common data format for describing and exchanging incident 48 information between collaborating Computer Security Incident Response 49 Teams (CSIRTs). The specific goals and requirements of the IODEF are 50 described in [2]. One of the design principles in the IODEF is 51 compatibility with the Intrusion Detection Message Exchange Format 52 (IDMEF) [3] developed for intrusion detection systems. For this 53 reason, IODEF is heavily based on the IDMEF and provides upward 54 compatibility with it. 56 This document describes a data model for representing information 57 produced by incident handling systems managing security incident 58 data, and explains the rationale for using this model. An 59 implementation of the data model in the Extensible Markup Language 60 (XML) is presented, an XML Document Type Definition is developed, and 61 examples are provided. 63 TABLE OF CONTENTS 65 1. Conventions Used in This Document................................4 66 2. Introduction ....................................................4 67 2.1 About the IODEF Data Model ..................................5 68 2.1.1 Problems Addressed by the Data Model ...................6 69 2.1.2 Data Model Design Goals ................................7 70 2.2 About the IODEF XML Implementation ..........................7 71 2.3 Relation between IODEF and IDMEF ............................9 72 3. Notational Conventions and Formatting Issues ....................9 73 3.1 UML Conventions used for Data Model Description .............9 74 3.1.1 Relationships..........................................10 75 3.1.2 Occurrence Indicators..................................11 76 3.2 XML Document Type Definitions ..............................12 77 3.2.2 Element Declarations ..................................12 78 3.2.2.1 Occurrence Indicators.............................13 79 3.2.2.2 Alternative Content and Grouping..................13 80 3.2.2.3 Element Content...................................14 81 3.2.3 Attribute Declarations ................................15 82 3.2.3.1 Attribute Types...................................15 83 3.2.3.2 Attribute Content.................................16 84 3.2.4 Entity Declarations ...................................16 85 3.3 XML Documents ...............................................17 86 3.3.1 The Document Prolog ...................................17 87 3.3.1.1 XML Declaration ..................................17 88 3.3.1.2 IODEF DTD Formal Public Identifier ...............18 89 3.3.1.3 IODEF DTD Document Type Declaration ..............18 90 3.3.2 Character Data Processing in XML and IODEF ............19 91 3.3.2.1 Character Entity References.......................20 92 3.3.2.2 Character Code References.........................20 93 3.3.2.3 White Space Processing............................21 94 3.3.3 Languages in XML and IODEF ............................21 95 3.3.4 Inheritance and Aggregation ...........................22 96 3.4 IODEF Data Types ............................................22 97 3.4.1 Integers ..............................................23 98 3.4.2 Real Numbers ..........................................23 99 3.4.3 Characters and Strings ................................23 100 3.4.4 Bytes .................................................24 101 3.4.5 Enumerated Types ......................................24 102 3.4.6 Date-Time Strings .....................................24 103 3.4.7 NTP Timestamps ........................................26 104 3.4.8 Port Lists ............................................26 105 3.4.9 Unique Identifiers ....................................27 106 3.4.10 Personal name.........................................28 107 3.4.11 Organization name.....................................28 108 3.4.12 Postal address........................................28 109 3.4.13 Telephone and Fax numbers.............................29 110 4. The IODEF Data Model and XML DTD................................29 111 4.1 Data Model Overview.........................................29 112 4.2 The IODEF-Description Class.................................32 113 4.3 The Incident Class..........................................33 114 4.4 The CorrelationIncident Class...............................36 115 4.5 The IncidentAlert Class.....................................37 116 4.6 The Core Classes............................................38 117 4.6.1 The Attack Class.......................................39 118 4.6.2 The Source Class.......................................42 119 4.6.3 The Target Class.......................................44 120 4.6.4 The Method Class.......................................46 121 4.6.5 The Attacker Class.....................................47 122 4.6.6 The Victim Class.......................................48 123 4.6.7 The Evidence Class.....................................50 124 4.6.8 The Assessment Class...................................51 125 4.6.8.1 The Impact Class..................................52 126 4.6.8.2 The Action Class..................................53 127 4.6.8.3 The Confidence Class..............................54 128 4.6.9 The Authority Class...................................56 129 4.6.10 The History Class.....................................56 130 4.6.11 The AdditionalData Class..............................58 131 4.7 The Time Classes............................................59 132 4.7.1 The DetectTime Class...................................59 133 4.7.2 The StartTime Class....................................60 134 4.7.3 The EndTime Class......................................60 135 4.7.4 The DateTime Class.....................................60 136 4.8 The Support Classes.........................................61 137 4.8.1 The Node Class.........................................61 138 4.8.1.1 The Address Class.................................63 139 4.8.1.2 The NodeRole Class................................65 140 4.8.2 The User Class.........................................66 141 4.8.2.1 The UserId Class..................................67 142 4.8.3 The Process Class......................................69 143 4.8.4 The Service Class......................................71 144 4.8.4.1 The WebService Class..............................72 145 4.8.4.2 The SNMPService Class.............................73 146 4.8.5 The Classification Class...............................74 147 4.8.6 The EvidenceData Class.................................76 148 4.8.6.1 The EvidenceDesc Class............................77 149 4.8.6.2 The EventList Class...............................78 151 4.8.7 The Organization Class.................................79 152 4.8.8 The Contact Class......................................81 153 4.8.9 The Reported Class.....................................82 154 4.8.10 The Received Class....................................83 155 4.8.11 The ActionList Class..................................85 156 4.8.12 The FileList Class....................................86 157 4.8.12.1 The File Class...................................86 158 4.8.12.2 The FileAccess Class.............................89 159 4.8.12.3 The Linkage Class................................90 160 4.8.12.4 The Inode Class..................................92 161 4.8.13 The Analyzer Class....................................94 162 4.9 The Simple Classes..........................................96 163 4.9.1 The Description Class..................................96 164 4.9.2 The IRTcontact Class...................................96 165 4.9.3 The EvidenceItem Class.................................97 166 4.9.4 The CorrEvidence Class.................................98 167 4.9.5 The Name Class.........................................98 168 5. Extending the IODEF ............................................99 169 5.1 Extending the Data Model ...................................99 170 5.2 Extending the XML DTD ......................................99 171 6. Special Considerations ........................................101 172 6.1 XML Validity and Well-Formedness ..........................102 173 6.2 Unrecognized XML Tags .....................................102 174 6.3 Digital Signatures ........................................103 175 7. Examples ......................................................103 176 8. The IODEF Document Type Definition ............................104 177 9. References ....................................................119 178 10. Security Considerations ......................................120 179 11. IANA Considerations ..........................................120 180 12. Acknowledgements .............................................120 181 13. Authors' Addresses ...........................................121 182 14. Full Copyright Statement .....................................121 184 1. Conventions Used in This Document 186 The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," 187 "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this 188 document are to be interpreted as described in RFC 2119 [2]. 190 Network and Computer Security related terminology used in this 191 documents is of common use, however it contains some specific 192 conventions described in [2] and [4]. 194 2. Introduction 196 The Incident Object Description and Exchange Format (IODEF) is 197 intended to be a standard format for Computer Security Incident 198 Response Teams (CSIRTs) to exchange operational and statistical 199 incident information among themselves and their collaborators. It 200 can also provide the basis for the development of interoperable tools 201 and procedures for incident reporting. 203 By using IODEF in their workflow and incident handling system, a 204 CSIRT can benefit from: 206 + a single organizational data schema that can represent information 207 from a variety of subordinate teams or CSIRTs; 209 + a common incident data format that facilities collaboration among 210 affected members of the security community (e.g. users, vendors, 211 response teams, law enforcement); 213 + the simplification in building an incident correlation and 214 statistics system that process incident reports from different 215 CSIRTs. 217 One of the design principles of the IODEF is complete compatibility 218 with the Intrusion Detection Message Exchange Format (IDMEF) [3] 219 developed for intrusion detection systems. For this reason, IODEF is 220 heavily based on the IDMEF and provides upward compatibility with it. 221 IDMEF messages may be entirely encapsulated into an explicit IDMEF 222 container provided in the IODEF data model. A goal of this version of 223 the Internet Draft is to provide context to discuss compatibility 224 issues between the IODEF and the IDMEF. 226 The IODEF description also intends to be capable of referencing 227 relevant external computer security information (e.g., vulnerability 228 and virus databases). 230 The computer security related terminology used in this document is 231 described in [1] and [4]. Specific terminology, notation, and 232 conventions related to the data model and XML DTD are presented in 233 Sections 3 and 4. The data model is described in Section 5 with 234 examples of its use in Section 8. Recognizing the potentially 235 diverse user-base implementing IODEF, Section 6 discusses the 236 ability to extend the model. 238 2.1 IODEF Data Model Design principles 240 The IODEF data model is an object-oriented representation of 241 information reported and maintained by a CSIRT about a computer 242 security incident. 244 2.1.1 Problems Addressed by the Data Model 246 The data model addresses several problems in representing 247 incident description data: 249 + Incident data is inherently heterogeneous. It may encompass 251 many functional purposes such as a description of intruder 252 behavior, a vulnerability report, or analysis results 253 correlating related incidents. However, even in a single 254 type of incident, seemingly disparate information from many 255 sources may need to be represented. 257 This representation of the data is further complicated by 258 the fact that incidents may consist of varying levels of 259 detail depending on their stage in the lifecycle. For 260 example, newly reported incidents may only contain a short 261 description of the involved parties. On the other hand, 262 closed incidents can contain a full description complete 263 with the associated evidence and annotation of actions taken 264 by the CSIRT. The data model that represents this 265 information must be flexible to accommodate different needs. 267 An object-oriented model provides extensible via aggregation 268 and sub-classing while preserving the consistency of the 269 model. If the data model required modification, it is 270 extended with new classes. In implementations that do not 271 recognize these extensions, the basic subset of the data 272 model will still be understood. 274 In order to address the various types of incidents, the 275 IODEF data model creates top-level classes for each of the 276 different incident profiles. Just as another other 277 extensions to the data model, creating new profiles is 278 possible through sub-classing or aggregation based on the 279 core and supportive classes. 281 + From the purview of a CSIRT, incident information can 282 originate from a number of sources. 284 The data model defines support classes that accommodate the 285 differences in the incident reporter. This support includes 286 various meta information to represent the reporterÆs 287 identity as well as prescribe a confidence level to the 288 submitted information. 290 + Incidents may contain sensitive information. Such 291 information should not be exposed to unauthorized parties 292 during collaboration. 294 The data model allows for a highly granular level of element 295 tagging to indication potential restrictions on the usage of 296 the data. However, it is the role of the IHS to honor these 297 labels. 299 2.1.2 Data Model Design Goals 301 The IODEF data model was designed to provide a standard 302 representation of a computer security incident. 304 + The design of the data model is content-driven. This design 305 dictates that new objects are introduced to accommodate 306 additional content, not semantic differences between 307 incidents. 309 + The data model must be unambiguous. Functionality similar 310 incident data (e.g. attacking hostname) must populate the 311 same elements of the schema. Likewise, the same incident 312 described by different CSIRTs (potentially using different 313 initial information) should be able to be identified as the 314 same incident. This correlation should be possible in spite 315 of descriptions having different levels of detail or the 316 source and target being described from a different 317 perspective. 319 + In order to investigate an incident across multiple sites, 320 aggregation of incident data from the responsible CSIRTS may 321 be required. This data model provides the facility for 322 logically groups related incidents. However, the methods and 323 algorithms for performing this correlation are left to the 324 IHS. 326 + The data model was designed with the intention to be both 327 human and machine-readable. This level of readability will 328 allow IODEF to be incorporated into incident handling system 329 used by CSIRTs. 331 + The ability to seamlessly integration IDMEF documents was 332 explicitly designed into the data model. 334 2.2 Using XML for IODEF Description 336 The current IODEF implementation is based on XML. As a 337 meta-language, XML allows the definition of customized markup 338 languages for different types of documents and different 339 applications. XML provides both the syntax for declaring document 340 markup and structure (i.e., defining elements and attributes, 341 specifying the order in which they appear, etc.) as well as, a 342 syntax for using that markup in documents. 344 XML-based applications define their own XML DTD or Schema and 345 register a specific XML namespace [6]. The IETF has a defined 346 procedure for registering an application specific XML namespace 347 [9]. 349 NOTE: For clarity in this document, we will use the terms "XML" 350 and "XML documents" when speaking in the general case about the 351 Extensible Markup Language (XML). The terms "IODEF 352 description", "IODEF markup" and "IODEF document" will be used 353 to refer to specific elements (tags) and attributes of the 354 IODEF DTD. Furthermore, the terms "class" and "subclass" are 355 synonymous to an ôelementö in the XML DTD. 357 The implementation of the IODEF in XML has many benefits: 359 + XML provides all the necessary features to define a specific 360 markup language for describing security incidents. It also 361 defines a standard way to extend this language, either for 362 later revisions ("standard" extensions), or for vendor-specific 363 use ("non- standard" extensions). 365 + Software tools for processing XML documents are widely available 366 in commercial and open source forms. Numerous tools and APIs 367 for parsing and/or validating XML are available in a variety of 368 languages, including Java, C, C++, Tcl, Perl, and Python. 369 Widespread access to tools will make the adoption of the IODEF 370 by product developers easier, and hopefully, faster. 372 + XML meets IODEF Requirement 4.1 that message formats support 373 full internationalization and localization. The XML standard 374 requires support for both the UTF-8 and UTF-16 encodings of 375 ISO/IEC 10646 (Universal Multiple-Octet Coded Character Set, 376 "UCS") and Unicode, making all XML applications (and therefore 377 all IODEF-compliant applications) compatible with these common 378 character encodings. 380 XML also provides support for specifying on a per-element 381 basis, the language in which the element's content is written, 382 making IODEF easy to adapt to local languages in which CSIRTs 383 and their constituency work. 385 + XML meets IODEF Requirement 4.2 that message formats must 386 support modularity, filtering and aggregation. XML's 387 integration with XSL, a style language, allows messages to be 388 combined, discarded, and rearranged. 390 + XML is free (no license, license fees or royalties). 392 2.3 Relation between IODEF and IDMEF 394 The IODEF is heavily based on the IDMEF reusing most of its data 395 model. The data model has upward compatibility (i.e. IDMEF 396 messages can be directly encapsulated in an IODEF document) with 397 the IDMEF whereby ensuring the inheritance of all IDMEF data 398 structures. IDMEF documents provide a description of an incident 399 from the perspective of a single intrusion detection system. 400 IODEF will be able to further annotate this information with 401 incident handling data. 403 Due to the close relationship between them, it is recommended that 404 IH systems understand both the IODEF and IDMEF formats. For the 405 most part, given a system that uses IODEF, adding IDMEF support 406 should be trivial since IODEF duplicated the IDMEF namespace. 408 3. Notational Conventions and Formatting Issues 410 This document uses three notations: Unified Modeling Language (UML) 411 to describe the data model, Extensible Markup Language (XML) to 412 define the markup of the IODEF, and IODEF markup to represent the 413 documents themselves. 415 This section describes these notations in sufficient detail that 416 readers unfamiliar with them can understand the document. Note, 418 however, that these descriptions are not comprehensive; they only 419 cover the components of the notations used by the data model and 420 document format. 422 This section also explains several issues that apply to XML and IODEF 423 documents such as the format of various data types, special 424 characters, whitespace processing, character sets and languages. 426 3.1 Unified Modeling Language conventions used for IODEF Data Model 427 description 429 The IODEF data model is described using the Unified Modeling 430 Language (UML) [10]. UML provides a simple framework to represent 431 entities and their relationships. UML defines entities as classes. 432 In this document, we have identified several classes and their 433 associated attributes. The symbols used in this document to 434 represent classes and attributes are shown in Figure 3.1. 436 +-------------+ 437 | Class Name | <----- Name of class 438 +-------------+ 439 | Attribute 1 | <----- Name of first attribute 440 | ... | 441 | Attribute N | <----- Name of nth attribute 442 +-------------+ 444 Figure 3.1 - Symbols representing classes and attributes 446 Note that the associated attributes for a class may not appear in 447 all diagrams in which the class is used. 449 3.1.1 Relationships 451 The IODEF model currently uses only two of the relationship 452 types defined by UML: inheritance and aggregation. 454 Inheritance denotes a superclass/subclass type of relationship 455 where the subclass inherits all the attributes, operations, and 456 relationships of the superclass. This type of relationship is 457 also called a "is-a" or "kind-of" relationship. Subclasses may 458 have additional attributes or operations that apply only to the 459 subclass, and not to the superclass. 461 In this document, inheritance is denoted by the /_\ symbol. In 462 Figure 3.2, we are showing that Book and Magazine are two types 463 of Publication. Book inherits all the attributes of 464 Publication, plus all of its own attributes (thus, it has four 465 attributes in total); as does Magazine (giving it three 466 attributes in total). 468 +-------------+ 469 | Publication | 470 +-------------+ 471 | publisher | 472 | pubDate | 473 +-------------+ 474 /_\ 475 | 476 +--------+--------+ 477 | | 478 +----------+ +----------+ 479 | Magazine | | Book | 480 +----------+ +----------+ 481 | name | | title | 482 | | | author | 483 +----------+ +----------+ 485 Figure 3.2 - Inheritance relationships 487 Aggregation is a form of association in which the whole is 488 related to its parts. This type of relationship is also 489 referred to as a "part-of" relationship. In this case, the 490 aggregate class contains all of its own attributes and as many 491 of the attributes associated with its parts as required and 492 specified by the occurrence indicators (see Section 4.1.2). 494 In this document, the symbol <> is used to indicate 495 aggregation. It is placed at the end of the association line 496 closest to the aggregate (whole) class. In Figure 4.3, we 497 are showing that a Book is made up of pieces called Preface, 498 Chapter, Appendix, Bibliography, and Index. 500 +----------+ 501 | Book | 502 +----------+ 0..1 +--------------+ 503 | title |<>----------| Preface | 504 | author | +--------------+ 505 | | 1..* +--------------+ 506 | |<>----------| Chapter | 507 | | +--------------+ 508 | | 0..* +--------------+ 509 | |<>----------| Appendix | 510 | | +--------------+ 511 | | 0..1 +--------------+ 512 | |<>----------| Bibliography | 513 | | +--------------+ 514 | | +--------------+ 515 | |<>----------| Index | 516 | | +--------------+ 517 +----------+ 519 Figure 3.3 - Aggregation relationships 521 3.1.2 Occurrence Indicators 523 Occurrence indicators show the number of objects within a class 524 that are linked to one another by an aggregation relationship. 525 They are placed at the end of the association line closest to 526 the part they refer to. Occurrence indicators, as used in this 527 document, are: 529 n exactly "n" (left blank if n=1) 530 0..* zero or more 531 1..* one or more 532 0..1 zero or one (i.e., "optional") 533 n..m between "n" and "m" (inclusive) 535 In Figure 3.3, the Book: 537 + may have no Preface or one Preface; 538 + must have at least one Chapter, but may have more; 539 + may have any number of Appendixes; and 540 + must have exactly one Index. 542 3.2 XML Document Type Definitions 544 XML Document Type Definitions (DTDs) are used to declare the 545 markup for a document. This includes the different pieces of 546 information the document will contain (the elements), 547 characteristics of that information (the attributes), and the 548 relationship between the pieces (the content model). 550 Section 9 of this document contains the complete IODEF DTD. 552 3.2.2 Element Declarations 554 Elements are the main part of a document's markup; they define 555 the names of the pieces of the document, and the content model 556 for those pieces. 558 562 In this example, the "Book" element is defined to consist of exactly 563 one Preface, one Chapter, one Appendix, one Bibliography, and one 564 Index. Furthermore, these parts must appear in this order (e.g., the 565 Index cannot come before the Bibliography). 567 The XML document associated with this DTD might look like this: 569 570 571 ... 572 573 574 ... 575 576 577 ... 578 579 580 ... 581 582 584 NOTE: XML is for the most part a free-format language; the line 585 breaks and indentation used in the examples are for the purpose 586 of improving readability only. 588 3.2.2.1 Occurrence Indicators 590 In the example above, Book must contain exactly one of each 591 part -- it cannot have more than one Chapter, the Preface is 592 not optional, and so on. This is not a very good 593 representation of real-life books. 595 XML provides occurrence indicators to make it possible to 596 represent more complex content models. The occurrence 597 indicators are: 599 ? the content may appear either once or not at all 600 * the content may appear one or more times or not at all 601 + the content must appear at least once, and may appear 602 more than once 603 [none] the content must appear exactly once 605 Occurrence indicators allow us to revise our Book content 606 model 608 612 Now a Book may contain an optional Preface, one or more 613 Chapters, any number of Appendixes, an optional 614 Bibliography, and an Index. The parts must still occur in 615 this order. 617 3.2.2.2 Alternative Content and Grouping 619 To allow the creation of arbitrarily complex content models, 620 XML also provides: 622 + alternatives, specified with the '|' character 623 + parentheses, to permit grouping of elements 624 + occurrence indicators may also be used on parenthesized 625 groups 627 For example: 629 631 would allow all of the following: 633 634 635 636 637 638 639 640 641 642 643 645 The example above also introduces the "" notation; 646 this is used in XML to denote empty content. It is more or 647 less equivalent to "" (the differences are 648 beyond the scope of this document). 650 3.2.2.3 Element Content 652 An XML document has a tree structure. One element at the 653 top is the parent of all other elements (e.g., Book); 654 there is some number of other elements all with parents and 655 children; and then at the bottom of the tree, there is some 656 number of elements that have no children. These are the 657 elements that contain the document content. 659 XML DTDs do not support data types such as integer, real, 660 string, and so on (more on this later). However, they do 661 require some indication of the type(s) of content that an 662 element will contain. There are several types available, 663 but only two are used in the IODEF: 665 PCDATA 666 An XML processor will find only text (parsed character data) 667 in this element, no tags or entity references (see Section 668 3.2.4). This is the content type for all but one of the 669 elements at the bottom of the IODEF document tree. 671 ANY 672 The element may contain anything -- text, other tags, entity 673 references, etc. This is the content type for the 674 AdditionalData element (see Section 4.2.4.5). 676 In the case where declaring the data is essential, future 677 implementations of the IODEF should use an XML Schema 678 definition instead of currently used XML DTD. 680 3.2.3 Attribute Declarations 682 Attributes allow data to be associated with an element. The 683 decision to put data in an attribute or a child element is 684 mostly one of style, although consideration should be given to 685 the type and quantity of data as well. Attributes are, 686 generally, used for small, atomic data and elements are used 687 for large or composite data. 689 Attributes are declared with their name, their content type, 690 and their attribute type, as shown below: 692 697 The declaration above defines two attributes of the Book 698 element, title and author. Both may contain character data, 699 and both are required. These might be given as follows in an 700 XML document: 702 704 3.2.3.1 Attribute Types 706 There are four attribute types: 708 #REQUIRED 709 The attribute is required, and has no default value. The 710 XML document must specify a value for it. 712 #IMPLIED 713 The attribute is optional, and has no default value. 715 #FIXED [value] 716 The attribute must always have the default value "[value]." 717 It is an error to specify the attribute with any other 718 value. When an XML processor encounters an omitted 719 attribute, it will behave as though it were present with 720 the declared default value. 722 [value] 723 The attribute is optional, and has a default value of 724 "[value]." When an XML processor encounters an omitted 725 attribute, it will behave as though it were present with the 726 default value. 728 3.2.3.2 Attribute Content 730 There are a variety of attribute content types defined, but 731 only two are used in the IODEF: 733 CDATA 735 An attribute of this type contains character data (text). 736 Tags and entity references (see Section 4.2.4) are not 737 processed. 739 [values] 740 An attribute may also be declared with a list of acceptable 741 values; this functions somewhat like an enumerated type. 742 For example: 744 748 The gender attribute may have one of three values; if a 749 Person tag appears without a gender attribute, the XML 750 processor will behave as though it did have one, with value 751 "unknown." 753 3.2.4 Entity Declarations 755 Entities allow symbols to be defined that will be replaced with 756 other text when processed. There are two types of entities, 757 "general" and "parameter." General entities are for use within 758 XML document content; for example: 760 761 Entities are referenced by bracketing them with the characters 762 '&' and ';' -- whenever "&IODEF;" appears in the XML document 763 from the example above, it will be replaced with the text 764 "Intrusion Detection Message Exchange Format". General 765 entities (and a special case of them called character 766 references) are used extensively in handling special characters 767 (see Sections 4.3.2.1 and 4.3.2.2). 769 Parameter entities are for use within DTDs (they are not 770 recognized in document content), and are declared and 771 referenced in a slightly different way. The declaration 772 includes a '%' symbol before the entity name, and they are 773 referenced by bracketing them with the characters '%' (instead 774 of '&') and ';'. For example, attributes that must appear on 775 every element are declared in a parameter entity: 777 784 and then referenced in each attribute list declaration: 786 789 793 3.3 XML Documents 795 This section describes a number of XML document formatting rules; 796 these rules apply to IODEF documents as well. 798 3.3.1 The Document Prolog 800 The "prolog" of an XML document, that part that precedes 801 anything else, consists of the XML declaration and the document 802 type declaration. 804 3.3.1.1 XML Declaration 806 Every XML document (and therefore every IODEF document) 807 starts with an XML declaration. The XML declaration 808 specifies the version of XML being used; it may also specify 809 the character encoding being used. 811 The XML declaration looks like: 813 815 If a character encoding is specified, the declaration looks 816 like: 818 820 where "charset" is the name of the character encoding in use 821 (see Section 3.3.2). If no encoding is specified, UTF-8 is 822 assumed. IODEF documents being exchanged between 823 IODEF-compliant applications MUST begin with an XML 824 declaration, and MUST specify the XML version in use. 825 Specification of the encoding in use is RECOMMENDED. 827 IODEF-compliant applications MAY choose to omit the XML 828 declaration internally to conserve space, adding it only 829 when the message is sent to another destination (e.g., a web 830 browser). This practice is NOT RECOMMENDED unless it can be 831 accomplished without loss of each message's version and 832 encoding information. 834 3.3.1.2 IODEF DTD Formal Public Identifier 836 The formal public identifier (FPI) for the IODEF Document 837 Type Definition described in this document is: 839 "-//IETF//DTD RFCxxxx IODEF v0.0//EN" 841 NOTE: The "RFCxxxx" text in the FPI value will be replaced 842 with the actual RFC number, if this document is published as 843 an RFC. 845 This FPI MUST be used in the document type declaration 846 within an XML document referencing the IODEF DTD defined by 847 this document, as shown in the following section. 849 3.3.1.3 IODEF DTD Document Type Declaration 851 The document type declaration for an XML document 852 referencing the IODEF DTD will usually be specified in the 853 following ways: 855 858 The last component of the document type declaration is the 859 FPI specified in the previous section. 861 864 The last component of the document type declaration is a URI 865 that points to a copy of the Document Type Definition. 867 In order to be valid (see Section 7.1), an XML document must 868 contain a document type declaration. However, this 869 requirement imposes a significant overhead on an 870 IODEF-compliant application in bandwidth consumption and 871 computation for the DTD may need to be downloaded and parsed 872 before use by the XML parser. 874 Implementers MAY decide to have analyzers and managers agree 875 out-of-band on the particular document type definition they 876 will be using to exchange messages (the standard one as 877 defined here, or one with extensions), and then omit the 878 document type declaration from IODEF descriptions. The 879 method for negotiating this agreement is outside the scope 880 of this document. Note that great care must be taken in 881 negotiating any such agreements, as the manager may have to 882 accept messages from many different analyzers, each using a 883 DTD with a different set of extensions. 885 3.3.2 Character Data Processing in XML and IODEF 887 A document's XML declaration (see Section 4.3.1.1) specifies 888 the character encoding to be used in the document, as follows: 890 892 where "charset" is the name of the character encoding, as 893 registered with the Internet Assigned Numbers Authority (IANA), 894 see [11]. 896 The XML standard requires that XML processors support the UTF-8 897 and UTF-16 encodings of ISO/IEC 10646 (UCS) and Unicode, making 898 all XML applications (and therefore, all IODEF-compliant 899 applications) compatible with these common character encodings. 900 The XML standard also permits other character encodings to be 901 used (e.g., UTF-7, UTF-8, UTF-32). However, support for these 902 encodings is not guaranteed to be present in all XML 903 applications. 905 For portability reasons, IODEF-compliant applications SHOULD 906 NOT use, and IODEF descriptions SHOULD NOT be encoded in, 907 character encodings other than UTF-8 and UTF-16. Consistent 908 with the XML standard, if no encoding is specified for an IODEF 909 description, UTF-8 is assumed. 911 NOTE: The ASCII character set is a subset of the UTF-8 912 encoding, and therefore may be used to encode IODEF 913 descriptions. 915 Per the XML standard, IODEF documents encoded in UTF-16 MUST 916 begin with the Byte Order Mark described by ISO/IEC 10646 917 Annex E and Unicode Appendix B (the "ZERO WIDTH NO-BREAK 918 SPACE" character, #xFEFF). 920 3.3.2.1 Character Entity References 922 Within XML documents, certain characters have special 923 meanings in some contexts. To include the actual character 924 itself in one of these contexts, a special escape sequence, 925 called an entity reference, must be used. 927 The characters that sometimes need to be escaped, and their entity 928 references, are: 930 Character Entity Reference 931 --------------------------------- 932 & & 933 < < 934 > > 935 " " 936 ' ' 938 It is RECOMMENDED that IODEF-compliant applications use the 939 entity reference form whenever writing these characters in 940 data, to avoid any possibility of misinterpretation. 942 3.3.2.2 Character Code References 944 Any character defined by the ISO/IEC 10646 and Unicode 945 standards may be included in an XML document by the use of a 946 character reference. A character reference is started with 947 the characters '&' and '#', and ended with the character 948 ';'. Between these characters, the character code for the 949 character inserted. 951 If the character code is preceded by an 'x' it is 952 interpreted in hexadecimal (base 16), otherwise, it is 953 interpreted in decimal (base 10). For instance, the 954 ampersand (&) is encoded as & or & and the 955 less-than sign (<) is encoded as < or <. 957 Any one-, two-, or four-byte character specified in the 958 ISO/IEC 10646 and Unicode standards can be included in a 959 document using this technique. 961 3.3.2.3 White Space Processing 963 XML preserves white space by default. The XML processor 964 passes all white space characters to the application 965 unchanged. This behavior is much different from HTML (and 966 SGML) in which the presence (or lack of) spaces is 967 meaningful, but one space is interpreted the same as 968 multiple spaces. 970 XML allows elements to identify the importance of white 971 space in their content by using the "xml:space" attribute: 973 975 where "action" is either "default" or "preserve." 977 If "action" is "preserve," the application MUST treat all 978 white space in the element's content as significant. If 979 "action" is "default," the application is free to do 980 whatever it normally would with white space in the element's 981 content. 983 The intent declared with the "xml:space" attribute is 984 considered to apply to all attributes and content of the 985 element where it is specified (including sub-elements), 986 unless overridden with an instance of "xml:space" on 987 another element within that content. 989 All IODEF elements support the "xml:space" attribute. 991 3.3.3 Languages in XML and IODEF 993 XML allows elements to identify the language their content is 994 written in by using the "xml:lang" attribute: 996 998 where "langcode" is a language tag as described in RFC 3066 999 [12]. 1001 The intent declared with the "xml:lang" attribute is considered 1002 to apply to all attributes and content of the element where it 1003 is specified (including sub-elements), unless overridden with 1004 an instance of "xml:lang" on another element within that 1005 content. 1007 IODEF-compliant applications SHOULD specify the language in 1008 which their contents are encoded. In general, the language can 1009 be specified with the "xml:lang" attribute in the top-level 1010 element and letting all other elements "inherit" that 1011 definition. 1013 If no language is specified for an IODEF description, English 1014 SHALL be assumed. 1016 All IODEF tags support the "xml:lang" attribute. 1018 3.3.4 Inheritance and Aggregation 1020 XML DTDs do not support inheritance as used by the IODEF data 1021 model (i.e., there is no support for "kind-of" relationships). 1022 This limitation does not present a major problem in practice 1023 because aggregation relationships can be used instead with 1024 little loss of functionality. 1026 As a note of interest, XML Schemas, recently approved by the 1027 W3C, will provide support for inheritance, stronger data typing 1028 and other useful features [7]. Future versions of the IODEF 1029 will probably use XML Schemas instead of DTDs. It was 1030 recognized that in the initial stage of the design of a new 1031 application, an XML DTD was useful since it provides a better 1032 human readable format for document and element descriptions. 1033 However, with further the development of applications and 1034 integration into IH systems a more detailed definition of data 1035 types and elements relations as provided by XML Schemas may be 1036 required. 1038 3.4 IODEF Data Types 1040 Within an XML IODEF description, all data will be expressed as 1041 "text" (as opposed to "binary"), since XML is a text formatting 1042 language. We provide typing information for the attributes of the 1043 classes in the data model however, to convey to the reader the 1044 type of data the model expects for each attribute. 1046 Each data type in the model has specific formatting requirements 1047 in an XML IODEF description. These requirements are set forth in 1048 this section. 1050 3.4.1 Integers 1052 Integer attributes are represented by the INTEGER data type. 1053 Integer data MUST be encoded in Base 10 or Base 16. 1055 Base 10 integer encoding uses the digits '0' through '9' and an 1056 optional sign ('+' or '-'). For example, "123", "-456". 1058 Base 16 integer encoding uses the digits '0' through '9' and 1059 'a' through 'f' (or their upper case equivalents), and is 1060 preceded by the characters "0x". For example, "0x1a2b". 1062 3.4.2 Real Numbers 1064 Real (floating-point) attributes are represented by the REAL 1065 data type. Real data MUST be encoded in Base 10. 1067 Real encoding is that of the POSIX "strtod" library function: 1068 an optional sign ('+' or '-') followed by a non-empty string 1069 of decimal digits, optionally containing a radix character, 1070 then an optional exponent part. An exponent part consists of 1071 an 'e' or 'E', followed by an optional sign, followed by one 1072 or more decimal digits. For example, "123.45e02", 1073 "-567,89e-03". 1075 IODEF-compliant applications MUST support both the '.' and ',' 1076 radix characters. 1078 3.4.3 Characters and Strings 1080 Single-character attributes are represented by the CHARACTER 1081 data type. Multi-character attributes of known length are 1082 represented by the STRING data type. 1084 Character and string data have no special formatting 1085 requirements, other than the need to occasionally use character 1086 references (see Sections 4.3.2.1 and 4.3.2.2) to represent 1087 special characters. 1089 3.4.4 Bytes 1091 Binary data is represented by the BYTE (and BYTE[]) data type. 1093 Binary data MUST be encoded in its entirety using character 1094 code references (see Section 4.3.2.2). 1096 3.4.5 Enumerated Types 1098 Enumerated types are represented by the ENUM data type, and 1099 consist of an ordered list of acceptable values. Each value 1100 has a rank (number) and a representing keyword. 1102 Within an IODEF message, the enumerated type keywords are used 1103 as attribute values, and the ranks are ignored. However, those 1104 IODEF-compliant applications that choose to represent these 1105 values internally in a numeric format MUST use the rank values 1106 identified in this memo. 1108 3.4.6 Date-Time Strings 1110 Date-time strings are represented by the DATETIME data type. 1111 Each date-time string identifies a particular instant in time; 1112 ranges are not supported. 1114 Date-time strings are formatted according to a subset of ISO 1115 8601:2000 [13], as show below. Section references in 1116 parentheses refer to sections of the ISO 8601:2000 standard. 1118 1. Dates MUST be formatted as follows: 1120 YYYY-MM-DD 1122 where YYYY is the four- digit year, MM is the two-digit month 1123 (01-12), and DD is the two- digit day (01-31). (Section 1124 5.2.1.1, "Complete representation -- Extended format.") 1126 2. Times MUST be formatted as follows: 1128 hh:mm:ss 1130 where hh is the two-digit hour (00-24), mm is the two-digit 1131 minute (00-59), and ss is the two-digit second (00-60). 1132 (Section 5.3.1.1, "Complete representation -- Extended 1133 format.") 1134 Note that midnight has two representations, 00:00:00 and 1135 24:00:00. Both representations MUST be supported by 1136 IODEF-compliant applications, however, the 00:00:00 1137 representation SHOULD be used whenever possible. 1139 Note also that this format accounts for leap seconds. Positive 1140 leap seconds are inserted between 23:59:59Z and 24:00:00Z and 1141 are represented as 23:59:60Z. Negative leap seconds are 1142 achieved by the omission of 23:59:59Z. IODEF-compliant 1143 applications MUST support leap seconds. 1145 3. Times MAY be formatted to include a decimal fraction of 1146 seconds, as follows: 1148 hh:mm:ss.ss or 1149 hh:mm:ss,ss 1151 As many digits as necessary may follow the decimal sign (at 1152 least one digit must follow the decimal sign). Decimal 1153 fractions of hours and minutes are not supported. (Section 1154 5.3.1.3, "Representation of decimal fractions.") 1156 IODEF-compliant applications MUST support the use of both 1157 decimal signs ('.' and ','). 1159 Note that the number of digits in the fraction part does not 1160 imply anything about accuracy -- i.e., "00.100000", "00,1000" 1161 and "00.1" are all equivalent. 1163 4. Times MUST be formatted to include (a) an indication that 1164 the time is in Coordinated Universal Time (UTC), or (b) an 1165 indication of the difference between the specified time and 1166 Coordinated Universal Time. 1168 a. Times in UTC MUST be formatted by appending the letter 'Z' 1169 to the time string as follows: 1171 hh:mm:ssZ 1172 hh:mm:ss.ssZ 1173 hh:mm:ss,ssZ 1175 (Section 5.3.3, "Coordinated Universal Time (UTC) -- Extended 1176 format.") 1178 b. If the time is ahead of or equal to UTC, a '+' sign is 1179 appended to the time string; if the time is behind UTC, a 1180 '-' sign is appended. Following the sign, the number of 1181 hours and minutes representing the different from UTC is 1182 appended, as follows: 1184 hh:mm:ss+hh:mm 1185 hh:mm:ss-hh:mm 1186 hh:mm:ss.ss+hh:mm 1187 hh:mm:ss.ss-hh:mm 1188 hh:mm:ss,ss+hh:mm 1189 hh:mm:ss,ss-hh:mm 1191 The difference from UTC MUST be specified in both hours and 1192 minutes, even if the minutes component is 0. A "difference" of 1193 "+00:00" is equivalent to UTC. (Section 5.3.4.2, "Local time 1194 and the difference with Coordinated Universal Time -- Extended 1195 Format.") 1197 5. Date-time strings are created by joing the date and time 1198 strings with the letter 'T', as shown below: 1200 YYYY-MM-DDThh:mm:ssZ 1201 YYYY-MM-DDThh:mm:ss.ssZ 1202 YYYY-MM-DDThh:mm:ss,ssZ 1203 YYYY-MM-DDThh:mm:ss+hh:mm 1204 YYYY-MM-DDThh:mm:ss-hh:mm 1205 YYYY-MM-DDThh:mm:ss.ss+hh:mm 1206 YYYY-MM-DDThh:mm:ss.ss-hh:mm 1207 YYYY-MM-DDThh:mm:ss,ss+hh:mm 1208 YYYY-MM-DDThh:mm:ss,ss-hh:mm 1210 (Section 5.4.1, "Complete representation -- Extended format.") 1212 In summary, IODEF date-time strings MUST adhere to one of the nine 1213 templates identified in Paragraph 5, above. 1215 3.4.7 NTP Timestamps 1217 NTP timestamps are represented by the NTPSTAMP data type, and 1218 are described in detail in [14] and [15]. An NTP timestamp is 1219 a 64-bit unsigned fixed-point number. The integer part is in 1220 the first 32 bits, and the fraction part is in the last 32 1221 bits. 1223 Within IODEF descriptions, NTP timestamps MUST be encoded as 1224 two 32-bit hexadecimal values, separated by a period ('.'). 1225 For example, "0x12345678.0x87654321". 1227 3.4.8 Port Lists 1229 Port lists are represented by the PORTLIST data type, and 1230 consist of a comma-separated list of numbers (individual 1231 integers) and ranges (N-M means ports N through M, inclusive). 1232 Any combination of numbers and ranges may be used in a single 1233 list. For example, "5-25,37,42,43,53,69-119,123-514". 1235 3.4.9 Unique Identifiers 1237 There are several types of unique identifiers used in this 1238 specification. All types are represented by STRING data types. 1240 These identifiers are implemented as attributes in the relevant 1241 XML elements, and must have unique values as follows: 1243 1. If specified, the attribute of the Authority class (Section 1244 5.2.6.8) OrganizationID MUST have a value that is globally 1245 unique. It may be a combination of the Registry name and unique 1246 CSIRT ID in this Registry. FIRST or industry associations 1247 normally maintain registries. 1249 The default value is "unknown", which indicates that the 1250 authority or CISRT doesnÆt have unique identifiers. 1252 2. The Incident, Attacker, Evidence, Victim, Source, Target, 1253 Node, User, Process, Service, Address, and UserID classes (see 1254 correspondent sections) are provided with "ident" attribute, 1255 which if specified, MUST have a value that is unique across all 1256 IODEF Descriptions created by the particular CSIRT or 1257 Authority. 1259 The "ident" attribute value MUST be unique for each particular 1260 combination of data identifying an object, not for each object. 1261 Objects may have more than one ident value associated with 1262 them. For example, an identification of a host by name would 1263 have one value, while an identification of that host by address 1264 would have another value, and an identification of that host by 1265 both name and address would have still another value. 1266 Furthermore, different analyzers may produce different values 1267 for the same information. 1269 The "ident" attribute by itself provides a unique identifier 1270 only among all the "ident" values created/stored by a 1271 particular CSIRT or IHS. But when combined with the unique 1272 "OrganizationID" value for the CSIRT, there is no requirement 1273 for global uniqueness. The default value is "0", which 1274 indicates that the CSIRT/IHS cannot generate unique 1275 identifiers. 1277 The specification of methods for creating the unique values 1278 contained in these attributes is outside the scope of this 1279 document. 1281 3.4.10 Personal names 1283 Format for the Personal name data is used the same as in LDAP. 1284 It is supposed that normally personal names are obtained from 1285 different Directories used by CSIRTs for their daily work. 1287 Current suggestion for the personal name formats are a follows: 1289 Name Surname 1291 Or 1293 Surname, Name 1295 It is possible to use personal handle from the official (IP or 1296 DNS) databases: RIPE NCC, InterNIC, etc. In this case element's 1297 attribute will indicate type of personal name presentation and 1298 indirectly point on used Registry or database. 1300 3.4.11 Organization names 1302 Organization name is presented in form of it full name, short 1303 name or identification code retrieved from official Registries. 1305 It is possible to use organization handle (or organization role 1306 from the official (IP or DNS) databases: RIPE NCC, InterNIC, 1307 etc. In this case elementÆs attribute will indicate type of 1308 personal name presentation and indirectly point on used 1309 Registry or database. 1311 3.4.12 Postal addresses 1313 Format for the Postal addresses data is used the same as in 1314 LDAP. It is supposed that postal addresses are obtained from 1315 the Incident reports or from different Directories used by 1316 CSIRTs for their daily work. 1318 Building, Street, Zip-code, City, Country 1320 Or 1322 Post Office Box, Zip-code, City, Country 1324 3.4.13 Telephone and Fax numbers 1326 Telephone and Fax numbers are expressed in format recommended 1327 by ITU documents. 1329 + (international code) (local code) (tel. Number) 1331 4. The IODEF Data Model and XML DTD 1333 In this section, the individual components of the IODEF data model 1334 are explained in details. UML diagrams of the model are provided to 1335 illustrate the relationship between components. Likewise, relevant 1336 sections of the XML DTD are presented to describe how the model is 1337 translated into XML. 1339 4.1 Data Model Overview 1341 The relationship between the principal components of the data 1342 model is shown in Figure 5.1 (cardinality and attributes are 1343 omitted). 1345 IODEF-Description is the top-level container class for all IODEF 1346 documents. Recognizing that incidents might require different 1347 types of data, sub-classes of this root class called incident 1348 descriptions are defined. There are presently two types of 1349 descriptions defined: the Incident class to describe an incident 1350 and the IncidentAlert class to allow seamless support for IODEF 1351 alerts. 1353 It is important to note that the data model does not define the 1354 events that constitute an incident. The notion of an incident is 1355 very site-specific. For example, a port scan may be identified by 1356 one CSIRT as a single incident with multiple victims. Another 1357 CSIRT might separate this activity as multiple incidents each from 1358 a single source to a single victim. Regardless, once the creator 1359 of the report has determined a logical grouping of events that 1360 constitute an incident, the data model dictates how that 1361 description should be formatted. 1363 +---------------------+ 1364 | IODEF-Description | 1365 +---------------------+ 1366 /_\ 1367 | 1368 +--------------------+---------------------+ 1369 | | 1370 | +-------+--------+ 1371 | | IncidentAlert | 1372 | +----------------+ 1373 | 1374 +----------+ +------------+ +----------------+ +----------+ 1375 | Incident |<>-| Attack |<>-| Source |<>-| Node | 1376 +----------+ +------------+ +----------------+ +----------+ 1377 | | | | | | +----------+ 1378 | | | | | |<>-| User | 1379 | | | | | | +----------+ 1380 | | | | | | +----------+ 1381 | | | | | |<>-| Process | 1382 | | | | | | +----------+ 1383 | | | | | | +----------+ 1384 | | | | | |<>-| Service | 1385 | | | | | | +----------+ 1386 | | | | | | +----------+ 1387 | | | | | |<>-| Program | 1388 | | | | | | +----------+ 1389 | | | | | | +----------+ 1390 | | | | | |<>-| OS | 1391 | | | | +----------------+ +----------+ 1392 | | | | +----------------+ +----------+ 1393 | | | |<>-| Target |<>-| Node | 1394 | | | | +----------------+ +----------+ 1395 | | | | | | +----------+ 1396 | | | | | |<>-| User | 1397 | | | | | | +----------+ 1398 | | | | | | +----------+ 1399 | | | | | |<>-| Process | 1400 | | | | | | +----------+ 1401 | | | | | | +----------+ 1402 | | | | | |<>-| Service | 1403 | | | | | | +----------+ 1404 | | | | | | +----------+ 1405 | | | | | |<>-| Program | 1406 | | | | | | +----------+ 1407 | | | | | | +----------+ 1408 | | | | | |<>-| OS | 1409 | | | | | | +----------+ 1410 | | | | | | +----------+ 1411 | | | | | |<>-| FileList | 1412 | | | | +----------------+ +----------+ 1413 | | | | +----------------+ 1414 | | | |<>-| Description | 1415 | | | | +----------------+ 1416 | | | | +----------------+ 1417 | | | |<>-| DetectTime | 1418 | | | | +----------------+ 1419 | | | | +----------------+ 1420 | | | |<>-| StartTime | 1421 | | | | +----------------+ 1422 | | | | +----------------+ 1423 | | | |<>-| EndTime | 1424 | | | | +----------------+ 1425 | | +------------+ +----------------+ 1426 | |<>-| Attacker |<>-| Contact | 1427 | | +------------+ +----------------+ 1428 | | | | +----------------+ 1429 | | | |<>-| Location | 1430 | | | | +----------------+ 1431 | | | | +----------------+ 1432 | | | |<>-| IRTcontact | 1433 | | +------------+ +----------------+ 1434 | | +------------+ +----------------+ 1435 | |<>-| Victim |<>-| Contact | 1436 | | +------------+ +----------------+ 1437 | | | | +----------------+ 1438 | | | |<>-| Location | 1439 | | | | +----------------+ 1440 | | | | +----------------+ 1441 | | | |<>-| IRTcontact | 1442 | | +------------+ +----------------+ 1443 | | +------------+ +----------------+ 1444 | |<>-| Method |<>-| Classification | 1445 | | +------------+ +----------------+ 1446 | | | | +----------------+ 1447 | | | |<>-| Description | 1448 | | +------------+ +----------------+ 1449 | | +------------+ +----------------+ 1450 | |<>-| Assessment |<>-| Reported | 1451 | | +------------+ +----------------+ 1452 | | | | +----------------+ 1453 | | | |<>-| Received | 1454 | | | | +----------------+ 1455 | | | | +----------------+ 1456 | | | |<>-| ActionList | 1457 | | +------------+ +----------------+ 1458 | | +------------+ +----------------+ 1459 | |<>-| Evidence |<>-| EvidenceData | 1460 | | +------------+ +----------------+ 1461 | | +------------+ +----------------+ 1462 | |<>-| Authority |<>-| Organization | 1463 | | +------------+ +----------------+ 1464 | | | | +----------------+ 1465 | | | |<>-| Contact | 1466 | | +------------+ +----------------+ 1467 | | +------------+ +----------------+ 1468 | |<>-| History |<>-| Reported | 1469 | | +------------+ +----------------+ 1470 | | | | +----------------+ 1471 | | | |<>-| Received | 1472 | | | | +----------------+ 1473 | | | | +----------------+ 1474 | | | |<>-| ActionList | 1475 | | +------------+ +----------------+ 1476 | | +----------------+ 1477 | |<>-| AdditionalData | 1478 +----------+ +----------------+ 1480 Figure 4.1 Data model overview 1482 Note: The IODEF data model in graphical form can be found at [18]. 1484 The individual classes are described in the following sections. 1486 4.2 The IODEF-Description Class 1488 IODEF-Description is the root container class of the IODEF data 1489 model. There are currently two main types (subclasses) of IODEF- 1490 Description: Incident and IncidentAlert. A third Experimental 1491 class is also included temporarily for testing. 1493 Since DTDs do not support subclassing (see Section 4.3.4), the 1494 inheritance relationship between the IODEF-Description and the 1495 Incident and IncidentAlert subclasses shown in Figure 5.1 has been 1496 replaced with an aggregate relationship. 1498 NOTE: The use of aggregation to implement an inheritance 1499 relationship is done throughout the data model. 1501 The IODEF-Description class is declared in the IODEF DTD as 1502 follows: 1504 1507 1510 1513 The IODEF-Description class has a single attribute: 1515 version 1517 The version of the IODEF-Description specification (this 1518 document) to which the document conforms. Applications 1519 specifying a value for this attribute MUST use the value "0.0". 1521 4.3 The Incident Class 1523 For a given incident, the CSIRT will create an instance of the 1524 Incident class. The information used to populate this class will 1525 come from the reporting infrastructure that the CSIRT already has 1526 in place. Thus, direct reports from their constituency, IDS alert 1527 messages, or collaboration with other CSIRTS could serve as 1528 potential input. 1530 An Incident description is composed of several aggregate classes, 1531 as shown in Figure 4.2. The aggregate classes themselves are 1532 described in Sections 4.2.4.1 - 4.2.4.10. 1534 +-------------------+ 1535 | Incident | 1536 +-------------------+ 1537 | STRING incidentID | 1..* +----------------+ +-------------+ 1538 | ENUM purpose |<>------| Attack |<>-| Source | 1539 | ENUM restriction | +----------------+ +-------------+ 1540 | | | | +-------------+ 1541 | | | |<>-| Target | 1542 | | | | +-------------+ 1543 | | | | +-------------+ 1544 | | | |<>-| Description | 1545 | | | | +-------------+ 1546 | | | | +-------------+ 1547 | | | |<>-| DetectTime | 1548 | | | | +-------------+ 1549 | | | | +-------------+ 1550 | | | |<>-| StartTime | 1551 | | | | +-------------+ 1552 | | | | +-------------+ 1553 | | | |<>-| EndTime | 1554 | | +----------------+ +-------------+ 1555 | | 0..* +----------------+ 1556 | |<>------| Attacker | 1557 | | +----------------+ 1558 | | 0..* +----------------+ 1559 | |<>------| Victim | 1560 | | +----------------+ 1561 | | 0..* +----------------+ 1562 | |<>------| Method | 1563 | | +----------------+ 1564 | | 0..1 +----------------+ 1565 | |<>------| Evidence | 1566 | | +----------------+ 1567 | | 0..1 +----------------+ 1568 | |<>------| Aassessment | 1569 | | +----------------+ 1570 | | +----------------+ 1571 | |<>------| Authority | 1572 | | +----------------+ 1573 | | 0..1 +----------------+ 1574 | |<>------| History | 1575 | | +----------------+ 1576 | | 0..* +----------------+ 1577 | |<>------| AdditionalData | 1578 +-------------------+ +----------------+ 1579 /_\ 1580 | 1581 | 1582 +----------+----------+ 1583 | CorrelationIncident | 1584 +---------------------+ 1586 Figure 4.2 The Incident Class 1588 The aggregate classes that constitute Incident are: 1590 Attack 1591 One or more. The security event(s) that compose the incident. 1593 Attacker 1594 Zero or more. The system(s) from which the Attack originated. 1596 Victim 1597 Zero or more. The system(s) at which the Attack was targeted. 1599 Method 1600 Zero or more. The actions taken by the Attacker in the 1601 incident. 1603 Evidence 1604 Zero or one. Container for the EvidenceData. 1606 Authority 1607 Exactly one. The CSIRT or authority that created the incident. 1609 History 1610 Zero or one. A log of the actions taken by the CSIRT(s) in the 1611 course of investigating the incident. 1613 AdditionalData 1614 Zero or more. Additional information about the incident 1615 included by CSIRT that cannot be readily expressed in the 1616 data model. 1618 The Incident class is represented in the XML DTD as follows: 1620 1624 1628 1631 1637 The Incident class has three attributes: 1639 IncidentID 1640 Required. A unique identifier for the Incident (see Section 1641 3.4.9). 1643 purpose 1644 Optional. The purpose of the incident being reported to the 1645 CSIRT. 1647 Rank Keyword Description 1648 ---- ------- ----------- 1649 0 unknown Purpose of the incident is unknown 1650 1 report Incident report 1651 2 handling Incident is being handled 1652 3 communication Incident is being sent to another team 1653 4 statistics Incident was reported for statistical 1654 purposes 1655 5 experimental Experimental 1657 restriction 1658 Optional. Sets a restriction on the usage of the data in 1659 element. 1661 Rank Keyword Description 1662 ---- ------- ----------- 1663 0 default Restriction level is defined by 1664 external policy applied to overall 1665 CSIRT process 1666 1 public No restriction is applied to element 1667 2 internal Data is for company's (or 1668 constituency) internal use 1669 3 restricted Use strictly for Incident managers at 1670 CSIRT 1672 4.4 The CorrelationIncident Class 1674 The CorrelationIncident class represents information related to 1675 the correlation of current incident. It is intended as a way by 1676 which to logically group previously reported incidents as related. 1678 The CorrelationIncident class is composed of three aggregate 1679 classes, as shown in Figure 4.3. 1681 +---------------------+ 1682 | CorrelationIncident | 1683 +---------------------+ 1684 | ENUM restriction | 0..1 +----------------+ 1685 | |<>------| IncidentID | 1686 | | +----------------+ 1687 | | 0..* +----------------+ 1688 | |<>------| EvidenceDataID | 1689 | | +----------------+ 1690 | | 0..* +----------------+ 1691 | |<>------| EventList | 1692 +---------------------+ +----------------+ 1694 Figure 4.3 - The CorrelationIncident Class 1696 The aggregate classes that constitute CorrelationIncident are: 1698 IncidentID 1699 Zero or one. STRING. Identifier of current Incident. If not 1700 included into CorrelationIncident class, this value may be 1701 derived from the top class Incident attribute. 1703 EvidenceDataID 1704 Zero or more. Evidence data that are linked to current 1705 Incident. 1707 EventList 1708 One or more. Lists all events which are investigated together, 1709 or have another common denominator. 1711 This is represented in the XML DTD as follows: 1713 1717 1721 The CorrelationIncident class has one attribute: 1723 restriction 1724 Optional. Sets a restriction on the usage of the data in 1725 element. 1727 4.5 IncidentAlert Class 1729 The IncidentAlert class is used as a container for IDMEF Alert 1730 messages. 1732 +-------------------+ 1733 | IncidentAlert | 1734 +-------------------+ 1735 | STRING incidentID | +----------------+ 1736 | ENUM purpose |<>------| Authority | 1737 | ENUM restriction | +----------------+ 1738 | | 0..1 +----------------+ 1739 | |<>------| History | 1740 | | +----------------+ 1741 | | 0..* +----------------+ 1742 | |<>------| AdditionalData | 1743 +-------------------+ +----------------+ 1745 Figure 4.4 The IncidentAlert Class 1747 The aggregate classes that constitute IncidentAlert are: 1749 Authority 1750 Exactly one. The CSIRT or authority that created the incident. 1752 History 1753 Zero or one. A log of the actions taken by the CSIRT(s) in 1754 course of investigating the incident. 1756 AdditionalData 1757 Zero or more. A container for the IDMEF Alert message. 1759 This is represented in the XML DTD as follows: 1761 1763 1769 The IncidentAlert class has three attributes: 1771 IncidentID 1772 Optional. A unique identifier for the alert, see Section 3.4.9. 1774 purpose 1775 Optional. The purpose of the incident being reported to the 1776 CSIRT. 1778 restriction 1779 Optional. Sets a restriction on the usage of the data in 1780 element. 1782 4.6 The Core Classes 1784 The core classes (Attack, Source, Target, Attacker, Victim, 1785 Method, Evidence, Authority, History, and AdditionalData) are the 1786 main parts of the Incident and IncidentAlert classes, as shown in 1787 Figure 5.5. 1789 NOTE: The IODEF data model reuses the Source and Target classes 1790 (as well as their subclasses) from the IDMEF [3]. 1792 +---------------+ +----------+ 0..* +-------------+ 1793 | Incident | | Attack | +------| Source | 1794 +---------------+ +----------+ | +-------------+ 1795 | | 1..* | | | 0..* +-------------+ 1796 | |<> --+------| |<>-+------| Target | 1797 | | | | | | +-------------+ 1798 | | | +----------+ | 0..* +-------------+ 1799 | | | +------| Description | 1800 | |<>+ | | +-------------+ 1801 | | | | 0..* +----------+ | 0..1 +-------------+ 1802 | | | +------| Attacker | +------| DetectTime | 1803 +---------------+ | | +----------+ | +-------------+ 1804 | | 0..* +----------+ | 0..1 +-------------+ 1805 | +------| Victim | +------| StartTime | 1806 | | +----------+ | +-------------+ 1807 | | 0..* +----------+ | 0..1 +-------------+ 1808 | +------| Method | +------| EndTime | 1809 | | +----------+ +-------------+ 1810 | | 0..* +----------+ 1811 | +------| Evidence | 1812 | | +----------+ 1813 | | 0..1 +------------+ 1814 | +------| Assessment | 1815 +---------------+ | +------------+ 1816 | IncidentAlert | | 1817 +---------------+ | +----------------+ 1818 | |<>+----------| Authority | 1819 | | | +----------------+ 1820 +---------------+ | 0..1 +----------------+ 1821 +----------| History | 1822 | +----------------+ 1823 | 0..* +----------------+ 1824 +----------| AdditionalData | 1825 +----------------+ 1827 Figure 4.5 The IODEF Core Classes 1829 4.6.1 The Attack Class 1831 The Attack class contains information about the security events 1832 that constitute the incident. 1834 +------------------+ 0..* +---------------+ +----------+ 1835 | Attack |<>------| Source |<>-| Node | 1836 +------------------+ +---------------+ +----------+ 1837 | STRING ident | | | +----------+ 1838 | | | |<>-| User | 1839 | ENUM restriction | | | +----------+ 1840 | | | | +----------+ 1841 | | | |<>-| process | 1842 | | | | +----------+ 1843 | | | | +----------+ 1844 | | | |<>-| service | 1845 | | | | +----------+ 1846 | | | | +----------+ 1847 | | | |<>-| program | 1848 | | | | +----------+ 1849 | | | | +----------+ 1850 | | | |<>-| OS | 1851 | | +---------------+ +----------+ 1852 | | 0..* +---------------+ +----------+ 1853 | |<>------| Target |<>-| Node | 1854 | | +---------------+ +----------+ 1855 | | | | +----------+ 1856 | | | |<>-| User | 1857 | | | | +----------+ 1858 | | | | +----------+ 1859 | | | |<>-| process | 1860 | | | | +----------+ 1861 | | | | +----------+ 1862 | | | |<>-| service | 1863 | | | | +----------+ 1864 | | | | +----------+ 1865 | | | |<>-| program | 1866 | | | | +----------+ 1867 | | | | +----------+ 1868 | | | |<>-| OS | 1869 | | | | +----------+ 1870 | | | | +----------+ 1871 | | | |<>-| FileList | 1872 | | +---------------+ +----------+ 1873 | | 0..* +---------------+ 1874 | |<>------| Description | 1875 | | +---------------+ 1876 | | 0..1 +---------------+ 1877 | |<>------| DetectTime | 1878 | | +---------------+ 1879 | | 0..1 +---------------+ 1880 | |<>------| StartTime | 1881 | | +---------------+ 1882 | | 0..1 +---------------+ 1883 | |<>------| EndTime | 1884 +------------------+ +---------------+ 1886 Figure 4.6 The Attack Class 1888 The aggregate classes that constitute Attack are: 1890 Source 1891 Zero or more. The source(s) of the event(s) causing the 1892 incident. 1894 Target 1895 Zero or more. The target(s) of the event(s) in the 1896 incident. 1898 Description 1899 Zero or more. A free-form textual description by the CSIRT 1900 or report of the incident events. 1902 DetectTime 1903 Zero or one. The time when the incident activity was first 1904 detected by the reporter. In the case of more than one 1905 event, the time the first event was detected. In some 1906 circumstances, this time may not be the same as the 1907 RegistrationTime used in the History class. 1909 StartTime 1910 Zero or one. The start time of the incident activity. 1912 EndTime 1913 Zero or one. The end time of the incident activity. 1915 This is represented in the XML DTD as follows: 1917 1921 1927 The Attack class has two attributes: 1929 ident 1930 Optional. A unique identifier for this Attack class (see 1931 Section 3.4.9). 1933 restriction 1934 Optional. Sets a restriction on the usage of the data in 1935 element. 1937 4.6.2 The Source Class 1939 The Source class contains information about the possible 1940 source(s) of the incident event(s). An event may have more than 1941 one source (e.g., in a distributed denial of service attack). 1942 For the purpose of compatibility, the Source class has been 1943 reused from the IDMEF. Hence, the Source class from an IDMEF 1944 message can be included unmodified into the IODEF-Description 1945 class with the same semantics. Likewise, the data in an 1946 IDMEF-originating Source class could be decomposed between the 1947 IODEF Source and Attack classes. 1949 The definition of the Source class in the IODEF data model is a 1950 superset of the IDMEF definition. Two new classes have been 1951 added: OS and program. 1953 The Source class is composed of four aggregate classes, as 1954 shown in Figure 4.7. 1956 +------------------+ 1957 | Source | 1958 +------------------+ 0..1 +---------+ 1959 | STRING ident |<>----------| Node | 1960 | ENUM spoofed | +---------+ 1961 | STRING interface | 0..1 +---------+ 1962 | |<>----------| User | 1963 | | +---------+ 1964 | | 0..1 +---------+ 1965 | |<>----------| Process | 1966 | | +---------+ 1967 | | 0..1 +---------+ 1968 | |<>----------| Service | 1969 | | +---------+ 1970 | | 0..1 +---------+ 1971 | |<>----------| os | 1972 | | +---------+ 1973 | | 0..1 +---------+ 1974 | |<>----------| Program | 1975 | | +---------+ 1976 +------------------+ 1978 Figure 4.7 The Source Class 1980 The aggregate classes that constitute Source are: 1982 Node 1983 Zero or one. Information about the host or device that 1984 appears to be causing the events (network address, network 1985 name, etc.). 1987 User 1988 Zero or one. Information about the user that appears to be 1989 causing the event(s). 1991 Process 1992 Zero or one. Information about the process that appears to 1993 be causing the event(s). 1995 Service 1996 Zero or one. Information about the network service involved 1997 in the event(s). 1999 os 2000 Zero or one. The operation system running on the Node from 2001 which the Attack originated. 2003 program 2005 Zero or one. The program that caused the Attack, that is 2006 running in the Process. 2008 This is represented in the XML DTD as follows: 2010 2013 2016 2022 The Source class has three attributes: 2024 ident 2025 Optional. A unique identifier for this Source class (see 2026 Section 3.4.9). 2028 spoofed 2029 Optional. An indication of confidence as to whether this is 2030 the true Attack source. The permitted values for this 2031 attribute are shown below. The default value is "unknown". 2033 Rank Keyword Description 2034 ---- ------- ----------- 2035 0 unknown Accuracy of source information unknown 2036 1 yes Source is believed to be a decoy 2037 2 no Source is believed to be "real" 2039 interface 2040 Optional. Specifies the interface on which the source of 2041 the event(s) was detected. 2043 4.6.3 The Target Class 2045 The Target class contains information about the possible 2046 target(s) of the incident event(s). An event may have more 2047 than one target (e.g., in the case of a port sweep). 2049 For the purpose of compatibility, the Target class has been 2050 reused from the IDMEF. Hence, the Target class from an IDMEF 2051 message can be included unmodified into the IODEF-Description 2052 class with the same semantics. Likewise, the data in an 2053 IDMEF-originating Source class could be decomposed between the 2054 IODEF Target and Attack classes. 2056 The definition of the Target class in the IODEF data model is a 2057 superset of the IDMEF definition. Two new classes have been 2058 added: OS and program. 2060 The Target class is composed of four aggregate classes, as 2061 shown in Figure 4.8. 2063 +------------------+ 2064 | Target | 2065 +------------------+ 0..1 +----------+ 2066 | STRING ident |<>----------| Node | 2067 | ENUM spoofed | +----------+ 2068 | STRING interface | 0..1 +----------+ 2069 | |<>----------| User | 2070 | | +----------+ 2071 | | 0..1 +----------+ 2072 | |<>----------| Process | 2073 | | +----------+ 2074 | | 0..1 +----------+ 2075 | |<>----------| Service | 2076 | | +----------+ 2077 | | 0..1 +----------+ 2078 | |<>----------| FileList | 2079 | | +----------+ 2080 | | 0..1 +----------+ 2081 | |<>----------| os | 2082 | | +----------+ 2083 | | 0..1 +----------+ 2084 | |<>----------| Program | 2085 | | +----------+ 2086 +------------------+ 2088 Figure 4.8 The Target Class 2090 The aggregate classes that constitute Target are: 2092 Node 2093 Zero or one. Information about the host or device at which 2094 the event(s) (network address, network name, etc.) is being 2095 directed. 2097 User 2098 Zero or one. Information about the user at which the 2099 event(s) is being directed. 2101 Process 2102 Zero or one. Information about the process at which the 2103 event(s) is being directed. 2105 Service 2106 Zero or one. Information about the network service involved 2107 in the event(s). 2109 FileList 2110 Zero or one. Information about file(s) involved in the 2111 event(s). 2113 os 2114 Zero or one. The operation system running on the targeted 2115 Node. 2117 program 2118 Zero or one. The program running as the Process, which was 2119 targeted in the Attack. 2121 This is represented in the XML DTD as follows: 2123 2126 2129 2135 The Target class has three attributes: 2137 ident 2138 Optional. A unique identifier for this Target class (see 2139 Section 3.4.9). 2141 spoofed 2142 Optional. An indication of confidence as to whether this is 2143 the true Attack target. The permitted values for this 2144 attribute are shown below. The default value is "unknown". 2146 Rank Keyword Description 2147 ---- ------- ----------- 2148 0 unknown Accuracy of target information unknown 2149 1 yes Target is believed to be a decoy 2150 2 no Target is believed to be "real" 2152 interface 2153 Optional. Specifies the interface on which the event(s) 2154 against the Target were detected. 2156 4.6.4 The Method Class 2158 The Method class provides information about the method used by 2159 the Attacker in the incident. This class can reference 2160 well-known vulnerability or exploit databases, as well as allow 2161 for a free-form description of the activity. 2163 The Method class is composed of two aggregate classes, as shown 2164 in Figure 4.9. 2166 +------------------+ 2167 | Method | 2168 +------------------+ 2169 | STRING ident | 0..* +----------------+ 2170 | ENUM restriction |<>------| Classification | 2171 | | +----------------+ 2172 | | 0..* +----------------+ 2173 | |<>------| Description | 2174 +------------------+ +----------------+ 2175 Figure 4.9 The Method Class 2177 The aggregate classes that constitute Method are: 2179 Classification 2180 Zero or more. A reference to a well-known vulnerability or 2181 exploit databases. 2183 Description 2184 Zero or more. A free-form text description of the attack. 2186 This is represented in the XML DTD as follows: 2188 2190 2195 The Method class has two attributes: 2197 ident 2198 Optional. A unique identifier for the element (see Section 2199 4.4.9). 2201 restriction 2202 Optional. Sets a restriction on the usage of the data in 2203 element. 2205 4.6.5 The Attacker Class 2207 The Attacker class augments information found in the Source 2208 class with further details related to the entity(ies)/person(s) 2209 identified as the source(s) of the incident activity. 2211 NOTE: Information found in the Attacker class might be derived 2212 based on address and network information found in the Source 2213 class. However, particular algorithm or procedure is defined 2214 by Incident Handling System 2216 +------------------+ 2217 | Attacker | 2218 +------------------+ 2219 | STRING ident | 0..1 +---------------+ 2220 | ENUM restriction |<>------| Contact | 2221 | | +---------------+ 2222 | | 0..1 +---------------+ 2223 | |<>------| Location | 2224 | | +---------------+ 2225 | | 0..1 +---------------+ 2226 | |<>------| IRTcontact | 2227 +------------------+ +---------------+ 2229 Figure 4.10 The Attacker Class 2231 The aggregate classes that constitute Attacker are: 2233 Contact 2234 Zero or one. Contact information for the entity/person 2235 identified as an Attacker. 2237 Location 2238 Zero or one. Location of Attacker's node or system. This is 2239 a general definition of location that may depend on network 2240 structure or company's geographical distribution. 2242 IRTcontact 2243 Zero or one. Contact information for the CSIRT or Network 2244 Security manager serving the NodeÆs network. 2246 Attacker is represented in the XML DTD as follows: 2248 2250 2255 The Attacker class has two attributes: 2257 ident 2258 Optional. A unique identifier for the Attacker, see Section 2259 4.4.9. 2261 restriction 2262 Optional. Sets a restriction on the usage of the data in 2263 element. 2265 4.6.6 The Victim Class 2266 The Victim class augments information found in the Target class 2267 with further details related to the entity(ies)/person(s) 2268 identified as the target(s) of the incident activity. 2270 NOTE: Information found in the Victim class might be derived 2271 based on address and network information found in the Target 2272 class. However, particular algorithm or procedure is defined by 2273 Incident Handling System. 2275 +------------------+ 2276 | Victim | 2277 +------------------+ 2278 | STRING ident | 0..1 +---------------+ 2279 | ENUM restriction |<>------| Contact | 2280 | | +---------------+ 2281 | | 0..1 +---------------+ 2282 | |<>------| Location | 2283 | | +---------------+ 2284 | | 0..1 +---------------+ 2285 | |<>------| IRTcontact | 2286 +------------------+ +---------------+ 2288 Figure 4.11 The Victim Class 2290 The aggregate classes that constitute Victim are: 2292 Contact 2293 Zero or one. Contact information for the entity/person 2294 identified as a Victim. 2296 Location 2297 Zero or one. Location of VictimÆs node or system. This is 2298 a general definition of location that may depend on network 2299 structure or companyÆs geographical distribution. 2301 IRTcontact 2302 Zero or one. Contact information for the CSIRT or Network 2303 Security manager serving the NodeÆs network. 2305 Victim is represented in the XML DTD as follows: 2307 2309 2313 The Victim class has two attributes: 2315 ident 2316 Optional. A unique identifier for the Victim element, see 2317 Section 4.4.9. 2319 restriction 2320 Optional. Sets a restriction on the usage of the data in 2321 element. 2323 4.6.7 The Evidence Class 2325 The Evidence class contains evidence related to the current 2326 incident. This evidence may consist of multiple pieces of 2327 data, each in a different format, including textual information 2328 (e.g., logfiles, malicious scripts, list of changes in file 2329 system) and binary (e.g., disk images) objects. 2331 +------------------+ 2332 | Evidence | 2333 +------------------+ 2334 | STRING ident | 0..* +---------------+ 2335 | ENUM restriction |<>------| EvidenceData | 2336 +------------------+ +---------------+ 2338 Figure 4.12 The Evidence Class 2340 The aggregate class that constitutes Evidence is: 2342 EvidenceData 2343 Zero or more. Container for evidence data related to the 2344 current incident. 2346 Evidence is represented in the XML DTD as follows: 2348 2351 2356 The Evidence class has two attributes: 2358 restriction 2359 Optional. Sets a restriction on the usage of the data in 2360 element. 2362 ident 2363 Optional. A unique identifier for the Evidence element, see 2364 Section 4.4.9. 2366 4.6.8 The Assessment Class 2368 The Assessment class is used to provide the CSIRT's assessment 2369 of an event - its impact, actions taken in response, and 2370 confidence. For the purpose of compatibility the Assessment 2371 Class is reused from the IDMEF. 2373 The Assessment class is composed of three aggregate classes, as 2374 shown in Figure 4.13. 2376 +------------------+ 2377 | Assessment | 2378 +------------------+ 0..1 +------------+ 2379 | ENUM restriction |<>----------| Impact | 2380 | | +------------+ 2381 | | 0..* +------------+ 2382 | |<>----------| Action | 2383 | | +------------+ 2384 | | 0..1 +------------+ 2385 | |<>----------| Confidence | 2386 | | +------------+ 2387 +------------------+ 2389 Figure 4.13 - The Assessment Class 2391 The aggregate classes that make up Assessment are: 2393 Impact 2394 Zero or one. The CSIRT's assessment of the impact of the 2395 event on the target(s). 2397 Action 2398 Zero or more. The action(s) taken by the CSIRT in response 2399 to the event. 2401 Confidence 2402 A measurement of the confidence the CSIRT has in its 2403 evaluation of the event. 2405 This is represented in the XML DTD as follows: 2407 2411 2416 4.6.8.1 The Impact Class 2418 The Impact class is used to provide the CSIRT's assessment 2419 of the impact of the event on the target(s). It is 2420 represented in the XML DTD as follows: 2422 2425 2428 2431 2432 2439 The Impact class has three attributes: 2441 severity 2442 An estimate of the relative severity of the event. The 2443 permitted values are shown below. There is no default 2444 value. 2446 Rank Keyword Description 2447 ---- ------- ----------- 2448 0 low Low severity 2449 1 medium Medium severity 2450 2 high High severity 2452 completion 2453 An indication of whether the CSIRT believes the attempt 2454 that the event describes was successful or not. The 2455 permitted values are shown below. There is no default 2456 value. 2458 Rank Keyword Description 2459 ---- ------- ----------- 2460 0 failed The attempt was not successful 2461 1 succeeded The attempt succeeded 2463 type 2464 The type of attempt represented by this event, in 2465 relatively broad categories. The permitted values are 2466 shown below. The default value is "other." 2468 Rank Keyword Description 2469 ---- ------- ----------- 2470 0 admin Administrative privileges were 2471 attempted or obtained 2472 1 dos A denial of service was attempted or 2473 completed 2474 2 file An action on a file was attempted or 2475 completed 2476 3 recon A reconnaissance probe was attempted 2477 or completed 2478 4 user User privileges were attempted or 2479 obtained 2480 5 other Anything not in one of the above 2481 categories 2483 All three attributes are optional. The element itself may 2484 be empty, or may contain a textual description of the 2485 impact, if the CSIRT is able to provide additional details. 2487 4.6.8.2 The Action Class 2489 The Action class is used to describe any actions taken by 2490 the CSIRT owning current Incident Object in course of its 2491 handling or investigating. It is represented in the XML DTD 2492 as follows: 2494 2498 2499 2504 Action has one attribute: 2506 category 2507 Optional. The type of action taken by CSIRT or automatic 2508 Intrusion detection tools. The permitted values are 2509 shown below. The default value is "other." 2511 Rank Keyword Description 2512 ---- ------- ----------- 2513 0 block-installed A block of some sort was 2514 installed to prevent an attack 2515 from reaching its destination. 2516 The block could be a port 2517 block, address block, etc., or 2518 disabling a user account. 2519 1 notification-sent A notification message of some 2520 sort was sent out-of-band (via 2521 pager, e-mail, etc.). Does not 2522 include the transmission of 2523 this alert. 2524 2 taken-offline A system, computer, or user was 2525 taken offline, as when the 2526 computer is shut down or a user 2527 is logged off. 2528 3 other Anything not in one of the 2529 above categories. 2531 The element itself may be empty, or may contain a textual 2532 description of the action, if the description of the taken 2533 actions needs to be expressed in free language. 2535 4.6.8.3 The Confidence Class 2537 The Confidence class is used to represent the CSIRT's best 2538 estimate of the validity of its Incident Assessment. It is 2539 represented in the XML DTD as follows: 2541 2544 2545 2550 The Confidence class has one attribute: 2552 rating 2553 The CSIRT's rating of its assessment validity. The 2554 permitted values are shown below. The default value is 2555 "numeric." 2557 Rank Keyword Description 2558 ---- ------- ----------- 2559 0 low The CSIRT/triage has little 2560 confidence in its validity 2561 1 medium The CSIRT/triage has average 2562 confidence in its validity 2563 2 high The CSIRT/triage has high 2564 confidence in its validity 2565 3 numeric The CSIRT/triage has provided 2566 a posterior probability value 2567 indicating its confidence in 2568 its validity 2570 This element should be used only when the CSIRT/triage can 2571 produce meaningful information. Systems that can output 2572 only a rough heuristic should use "low", "medium", or "high" 2573 as the rating value. In this case, the element content 2574 should be omitted. 2576 Systems capable of producing reasonable probability 2577 estimates should use "numeric" as the rating value and 2578 include a numeric confidence 2580 value in the element content. This numeric value should 2581 reflect a posterior probability (the probability that an 2582 attack has occurred given the data seen by the detection 2583 system and the model used by the system). It is a floating 2584 point number between 0.0 and 1.0, inclusive. The number of 2585 digits should be limited to those representable by a single 2586 precision floating point value, and may be represented as 2587 described in Section 3.4.2. 2589 NOTE: 2591 It should be noted that different types of Incident handling 2592 Systems may compute confidence values in different ways and 2593 that in many cases, confidence values from different CSIRTs 2594 should not be compared (for example, if the CSIRTs use 2595 different methods of computing or representing confidence, 2596 or are of different types or configurations). Care should 2597 be taken when implementing systems that process confidence 2598 values (such as event correlators) not to make comparisons 2599 or assumptions that cannot be supported by the system's 2600 knowledge of the environment in which it is working. 2602 4.6.9 The Authority Class 2604 The Authority class names and provides contact information for 2605 the CSIRT who created and is handling the incident. 2607 +------------------+ 2608 | Authority | 2609 +------------------+ 2610 | STRING ident | +---------------+ 2611 | ENUM restriction |<>------| Organization | 2612 | | +---------------+ 2613 | | 0..1 +---------------+ 2614 | |<>------| Contact | 2615 +------------------+ +---------------+ 2617 Figure 4.14 The Authority Class 2619 The aggregate classes that constitute Authority are: 2621 Organization 2622 Exactly one. Name or organization handling the current 2623 incident. 2625 Contact 2626 Zero or one. Contact information for the Organization 2627 handling the incident. 2629 Authority is represented in the XML DTD as follows: 2631 2633 2638 The Authority class has two attributes: 2640 ident 2641 Optional. A unique identifier for the Authority element (see 2642 Section 3.4.9). 2644 4.6.10 The History Class 2646 History class maintains a log of significant events that 2647 occurred in the course of handling the incident. This class 2648 tracks who initially reported the incident, documents the 2649 interaction between the reported and the investigating CSIRT, 2650 and lists any other actions taken by the CSIRT. When handling 2651 evidence, the History class can provide a chain of custody. 2653 The History class is composed of three aggregate classes, as 2654 shown in Figure 4.15. 2656 +------------------+ 2657 | History | 2658 +------------------+ 2659 | STRING ident | 0..1 +---------------+ 2660 | ENUM restriction |<>------| Reported | 2661 | | +---------------+ 2662 | | 0..* +---------------+ 2663 | |<>------| Received | 2664 | | +---------------+ 2665 | | 0..* +---------------+ 2666 | |<>------| ActionList | 2667 +------------------+ +---------------+ 2669 Figure 4.15 The History Class 2671 The aggregate classes that constitute History are: 2673 Reported 2674 Zero or one. Identifies who initially reported the 2675 incident. 2677 Received 2678 Zero or more. The communications of the CSIRT when handling 2679 the incident. 2681 ActionList 2682 Zero or more. The actions taken by the CSIRT in the course 2683 of handling the incident. 2685 This is represented in the XML DTD as follows: 2687 2689 2694 The History class has two attributes: 2696 ident 2697 Optional. A unique identifier for the History element 2698 (Section 3.4.9). 2700 restriction 2701 Optional. Sets a restriction on the usage of the data in element. 2703 4.6.11 The AdditionalData Class 2705 The AdditionalData class is used to provide information that 2706 cannot be represented by the data model. AdditionalData can be 2707 used to provide atomic data (integers, strings, etc.) in cases 2708 where only small amounts of additional information needed to be 2709 represented. However, the class can also be used to extend the 2710 data model and the DTD to support proprietary IODEF extensions 2711 or for encapsulating external XML document such as IDMEF 2712 messages. Detailed instructions for extending the data model 2713 and the DTD are provided in Section 5. 2715 The AdditionalData element is declared in the XML DTD as follows: 2717 2721 2722 2727 The AdditionalData class has two attributes: 2729 type 2731 Required. The type of data included in the element content. 2732 The permitted values for this attribute are shown below. 2733 The default value is "string". 2735 Rank Keyword Description 2736 ---- ------- ----------- 2737 0 boolean The element contains a boolean value, 2738 i.e., the strings "true" or "false" 2739 1 byte The element content is a single 8-bit 2740 byte (see Section 3.4.4) 2741 2 character The element content is a single 2742 character (see Section 3.4.3) 2743 3 date-time The element content is a date-time string 2744 (see Section 3.4.6) 2745 4 integer The element content is an integer (see 2746 Section 3.4.1) 2747 5 ntpstamp The element content is an NTP timestamp 2748 (see Section 3.4.7) 2749 6 portlist The element content is a list of ports 2750 (see Section 3.4.8) 2751 7 real The element content is a real number 2752 (see Section 3.4.2) 2753 8 string The element content is a string (see 2754 Section 3.4.3) 2755 9 xml The element content is XML-tagged data 2756 (see Section 5.2) 2758 local 2760 Optional. A string describing the meaning of the element 2761 content if used by CSIRT for a purpose not described in this 2762 document. These values will be vendor/implementation 2763 dependent. The method for ensuring that managers understand 2764 the string is outside the scope of this specification. 2766 4.7 The Time Classes 2768 The data model provides four classes for representing time. The 2769 three classes DetectTime, StartTime, EndTime are aggregates of the 2770 Attack classes. The support DateTime class is used for marking up 2771 date and time information in the aggregate classes EventList, 2772 ActionList, Reported and Received. 2774 The definition of the Time classes in this document are the same 2775 as in the IDMEF to ensure compatibility. 2777 4.7.1 The DetectTime Class 2779 The time when the incident activity was first detected by the 2780 reporter. 2782 It is represented in the XML DTD as follows: 2784 2785 2789 The DATETIME format of the element content is 2790 described in Section 3.4.6. 2792 The DetectTime class has one attribute: 2794 ntpstamp 2796 Required. The NTP timestamp representing the same date and 2797 time as the element content. The NTPSTAMP format of this 2798 attribute's value is described in Section 3.4.7. 2800 If the date and time represented by the element content and 2801 the NTP timestamp differ (should "never" happen), the value 2802 in the NTP timestamp MUST be used. 2804 4.7.2 The StartTime Class 2806 The start time of the incident activity. 2808 It is represented in the XML DTD as follows: 2810 2812 The DATETIME format of the element content is 2813 described in Section 3.4.6. 2815 4.7.3 The EndTime Class 2817 The end time of the incident activity. 2819 It is represented in the XML DTD as follows: 2821 2823 The DATETIME format of the element content is 2824 described in Section 3.4.6. 2826 4.7.4 The DateTime Class 2828 The supportive class to mark up date and time information. 2830 It is represented in the XML DTD as follows: 2832 2834 The DATETIME format of the element content is 2835 described in Section 3.4.6. 2837 4.8 The Support Classes 2839 The support classes constitute the major part of the core classes 2840 and are shared between them. 2842 The IODEF reuses a number of support classes from the IDMEF: 2844 + Node, Address, User, UserId, Process, Service - as compound 2845 classes for the Source and Target classes or for the Attacker and 2846 Victim classes; 2848 + WebService, SMTPService - as used in Service class; 2850 + Classification - as a component of the Method class. 2852 4.8.1 The Node Class 2854 The Node class is used to identify hosts and other network 2855 devices (routers, switches, etc.). 2857 The Node class is composed of five aggregate classes, as shown 2858 in Figure 4.16. 2860 +---------------+ 2861 | Node | 2862 +---------------+ 0..1 +----------+ 2863 | STRING ident |<>----------| Location | 2864 | ENUM category | +----------+ 2865 | | 0..1 +----------+ 2866 | |<>----------| name | 2867 | | +----------+ 2868 | | 0..* +----------+ 2869 | |<>----------| Address | 2870 | | +----------+ 2871 | | 0..1 +----------+ 2872 | |<>----------| DateTime | 2873 | | +----------+ 2874 | | 0..* +----------+ 2875 | |<>----------| NodeRole | 2876 | | +----------+ 2877 +---------------+ 2879 Figure 4.16 The Node Class 2881 The aggregate classes that constitute Node are: 2883 location 2884 Zero or one. STRING. The physical location of the 2885 equipment. 2887 name 2888 Zero or one. STRING. The name of the equipment. This 2889 information MUST be provided if no Address information is 2890 given. 2892 Address 2893 Zero or more. The network or hardware address of the 2894 equipment. Unless a name (above) is provided, at least one 2895 address must be specified. 2897 DateTime 2898 Zero or one. Date and time when the resolution between the 2899 name and address was performed. This information SHOULD be 2900 provided if both an Address and name are given. 2902 NodeRole 2903 Zero or more. The intended role of the node. 2905 This is represented in the XML DTD as follows: 2907 2911 2914 2919 The Node class has two attributes: 2921 ident 2922 Optional. A unique identifier for the node, see Section 2923 3.4.9. 2925 category 2926 Optional. The "domain" from which the name information 2927 obtained, if relevant. The permitted values for this 2928 attribute are shown below. The default value is "unknown". 2930 Rank Keyword Description 2931 ---- ------- ----------- 2932 0 unknown Domain unknown or not relevant 2933 1 ads Windows 2000 Advanced Directory Services 2934 2 afs Andrew File System (Transarc) 2935 3 coda Coda Distributed File System 2936 4 dfs Distributed File System (IBM) 2937 5 dns Domain Name System 2938 6 hosts Local hosts file 2939 7 kerberos Kerberos realm 2940 8 nds Novell Directory Services 2941 9 nis Network Information Services (Sun) 2942 10 nisplus Network Information Services Plus (Sun) 2943 11 nt Windows NT domain 2944 12 wfw Windows for Workgroups 2946 4.8.1.1 The Address Class 2948 The Address class represents a network, hardware, or 2949 application address. 2951 The Address class is composed of two aggregate classes, as 2952 shown in Figure 4.17. 2954 +------------------+ 2955 | Address | 2956 +------------------+ +---------+ 2957 | STRING ident |<>----------| address | 2958 | ENUM category | +---------+ 2959 | STRING vlan-name | 0..1 +---------+ 2960 | INTEGER vlan-num |<>----------| netmask | 2961 | | +---------+ 2962 +------------------+ 2964 Figure 4.17 The Address Class 2966 The aggregate classes that constitute Address are: 2968 address 2969 Exactly one. STRING. The address whose format is 2970 governed by the category attribute. 2972 netmask 2973 Zero or one. STRING. The network mask for the address, 2974 if appropriate. 2976 This is represented in the XML DTD as follows: 2978 2983 2986 2993 The Address class has four attributes: 2995 ident 2996 Optional. A unique identifier for the address (see 2997 Section 3.4.9). 2999 category 3000 Optional. The type of address represented. The 3001 permitted values for this attribute are shown below. The 3002 default value is "unknown". 3004 Rank Keyword Description 3005 ---- ------- ----------- 3006 0 unknown Address type unknown 3007 1 atm Asynchronous Transfer Mode network 3008 address 3009 2 e-mail Electronic mail address (RFC 822) 3010 3 lotus-notes Lotus Notes e-mail address 3011 4 mac Media Access Control (MAC) address 3012 5 sna IBM Shared Network Architecture 3013 (SNA) address 3014 6 vm IBM VM ("PROFS") e-mail address 3015 7 ipv4-addr IPv4 host address in 3016 dotted-decimal notation (a.b.c.d) 3017 8 ipv4-addr-hex IPv4 host address in hexadecimal 3018 notation 3019 9 ipv4-net IPv4 network address in 3020 dotted-decimal notation, slash, 3021 significant bits (a.b.c.d/nn) 3022 10 ipv4-net-mask IPv4 network address in 3023 dotted-decimal notation, slash, 3024 network mask in dotted-decimal 3025 notation (a.b.c.d/w.x.y.z) 3026 11 ipv6-addr IPv6 host address 3027 12 ipv6-addr-hex IPv6 host address in hexadecimal 3028 notation 3030 13 ipv6-net IPv6 network address, slash, 3031 significant bits 3032 14 ipv6-net-mask IPv6 network address, slash, 3033 network mask 3035 vlan-name 3036 Optional. The name of the Virtual LAN to which the 3037 address belongs. 3039 vlan-num 3040 Optional. The number of the Virtual LAN to which the 3041 address belongs. 3043 4.8.1.2 The NodeRole Class 3045 The NodeRole class is used to represent the intended role 3046 of a particular node. 3048 The NodeRole class is composed of a single attribute 3049 represented in the XML DTD as follows: 3051 3057 3058 3062 The NodeRole class has one attribute: 3064 category 3066 Optional. The intended role this Node is to fulfill. 3067 The permitted values for this attribute are shown 3068 below. The default value is "unknown". 3070 Rank Keyword Description 3071 ---- ------- ----------- 3072 0 unknown Unknown role 3073 1 client Client computer 3074 2 server-internal Server with internal services 3075 3 server-public Server with public services 3076 4 www WWW server 3077 5 mail Mail server 3078 6 messaging Messaging server (e.g. NNTP, IRC, 3079 instant) 3080 7 streaming Streaming-media server 3081 8 voice Voice server (e.g. SIP, H.323) 3082 9 file File server (e.g. SMB, CVS, AFS) 3083 10 ftp FTP server 3084 11 p2p Peer-to-peer server (e.g. 3085 Napster) 3086 12 name Name server (e.g. DNS, WINS) 3087 13 directory Directory server (e.g. LDAP, 3088 finger, whois) 3089 14 credential Credential server (e.g. domain 3090 controller, Kerberos) 3091 16 print Print server 3092 17 application Application server 3093 18 database Database server 3094 19 infra Infrastructure server (e.g. 3095 router, firewall, DHCP) 3096 20 log Log server (e.g. syslog) 3098 4.8.2 The User Class 3100 The User class describes a user account on a system. It is 3101 primarily used as a "container" class for the UserId aggregate 3102 class, as shown in Figure 4.18. 3104 More than one UserId can be used within the User class to 3105 indicate attempts to transition from one user to another, or to 3106 provide complete information about a user's (or process') 3107 privileges. 3109 +---------------+ 3110 | User | 3111 +---------------+ 1..* +--------+ 3112 | STRING ident |<>----------| UserId | 3113 | ENUM category | +--------+ 3114 +---------------+ 3116 Figure 4.18 The User Class 3118 The aggregate class contained in User is: 3120 UserId 3121 One or more. The user. 3123 This is represented in the XML DTD as follows: 3125 3128 3131 3136 The User class has two attributes: 3138 ident 3139 Optional. A unique identifier for the user (see Section 3140 3.4.9). 3142 category 3143 Optional. The type of user represented. The permitted 3144 values for this attribute are shown below. The default 3145 value is "unknown". 3147 Rank Keyword Description 3148 ---- ------- ----------- 3149 0 unknown User type unknown 3150 1 application An application user 3151 2 os-device An operating system or device user 3153 4.8.2.1 The UserId Class 3155 The UserId class describes a specific user account on a 3156 system. 3158 The UserId class is composed of two aggregate classes, as 3159 shown in Figure 4.19. 3161 +--------------+ 3162 | UserId | 3163 +--------------+ 0..1 +--------+ 3164 | STRING ident |<>----------| name | 3165 | ENUM type | +--------+ 3166 | | 0..1 +--------+ 3167 | |<>----------| number | 3168 | | +--------+ 3169 +--------------+ 3171 Figure 4.19 The UserId Class 3172 The aggregate classes that constitute UserId are: 3174 name 3175 Zero or one. STRING. A user or group name. 3177 number 3178 Zero or one. INTEGER. A user or group number. 3180 This is represented in the XML DTD as follows: 3182 3186 3189 3194 The UserId class has two attributes: 3196 ident 3197 Optional. A unique identifier for the user id (see 3198 Section 3.4.9). 3200 type 3201 Optional. The type of user information represented. The 3202 permitted values for this attribute are shown below. The 3203 default value is "original-user". 3205 Rank Keyword Description 3206 ---- ------- ----------- 3207 0 current-user The current user id being used by the 3208 user or process. On Unix systems, 3209 this would be the "real" user id. 3210 1 original-user The actual identity of the user or 3211 process being reported on. On those 3212 systems that (a) do some type of 3213 auditing and (b) support extracting a 3214 user id from the "audit id" token, 3215 that value should be used. On those 3216 systems that do not support this, and 3217 where the user has logged into the 3218 system, the "login id" should be used. 3219 2 target-user The user id the user or process is 3220 attempting to become. For example, 3221 on Unix systems when the 3222 user attempts to use "su," "rlogin," 3223 "telnet," etc. 3224 3 user-privs Another user id the user or process 3225 has the ability to use. On Unix 3226 systems, this would be the "effective" 3227 user id. Multiple UserId elements of 3228 this type may be used to specify a 3229 list of privileges. 3230 4 current-group The current group id (if applicable) 3231 being used by the user or process. On 3232 Unix systems, this would be the "real" 3233 group id. 3234 5 group-privs Another group id the group or process 3235 has the ability to use. On Unix 3236 systems, this would be the "effective" 3237 group id. On BSD-derived Unix 3238 systems, multiple UserId elements of 3239 this type would be used to include all 3240 the group ids on the "group list." 3241 6 other-privs Not used in a user, group, or process 3242 context, only used in the file 3243 context. The file permissions 3244 assigned to users who do not match 3245 either the user or group permissions 3246 on the file. On Unix systems, this 3247 would be the "world" permissions. 3249 4.8.3 The Process Class 3251 The Process class describes a process being executed on a system. 3253 The Process class is composed of five aggregate classes, as 3254 shown in Figure 4.20. 3256 +--------------+ 3257 | Process | 3258 +--------------+ +------+ 3259 | STRING ident |<>----------| name | 3260 | | +------+ 3261 | | 0..1 +------+ 3262 | |<>----------| pid | 3263 | | +------+ 3264 | | 0..1 +------+ 3265 | |<>----------| path | 3266 | | +------+ 3267 | | 0..* +------+ 3268 | |<>----------| arg | 3269 | | +------+ 3270 | | 0..* +------+ 3271 | |<>----------| env | 3272 | | +------+ 3273 +--------------+ 3275 Figure 4.20 The Process Class 3277 The aggregate classes that constitute Process are: 3279 name 3280 Exactly one. STRING. The filename of the program being 3281 executed. This is a short name; path and argument 3282 information are provided elsewhere. 3284 pid 3285 Zero or one. INTEGER. The process identifier of the 3286 process. 3288 path 3289 Zero or one. STRING. The full path of the program being 3290 executed. 3292 arg 3293 Zero or more. STRING. A command-line argument to the 3294 program. Multiple arguments may be specified (they are 3295 assumed to have occurred in the same order they are 3296 provided) with multiple uses of arg. 3298 env 3299 Zero or more. STRING. An environment string associated 3300 with the process; generally of the format "VARIABLE=value". 3301 Multiple environment strings may be specified with multiple 3302 uses of env. 3304 This is represented in the XML DTD as follows: 3306 3309 3313 The Process class has one attribute: 3315 ident 3316 Optional. A unique identifier for the process (see Section 3317 3.4.9). 3319 4.8.4 The Service Class 3321 The Service class describes a network service. It can identify 3322 services by name, port, and protocol. 3324 When Service occurs as an aggregate class of Source, it is 3325 understood that the service is one from which activity of 3326 interest is originating; and that the service is "attached" to 3327 the Node, Process, and User information also contained in 3328 Source. Likewise, when Service occurs as an aggregate class of 3329 Target, it is understood that the service is one to which 3330 activity of interest is being directed; and that the service is 3331 "attached" to the Node, Process, and User information also 3332 contained in Target. 3334 The Service class is composed of four aggregate classes, as 3335 shown in Figure 4.21. 3337 +--------------+ 3338 | Service | 3339 +--------------+ 0..1 +----------+ 3340 | STRING ident |<>----------| name | 3341 | | +----------+ 3342 | | 0..1 +----------+ 3343 | |<>----------| port | 3344 | | +----------+ 3345 | | 0..1 +----------+ 3346 | |<>----------| portlist | 3347 | | +----------+ 3348 | | 0..1 +----------+ 3349 | |<>----------| protocol | 3350 | | +----------+ 3351 +--------------+ 3352 /_\ 3353 | 3354 +------------+ 3355 | 3356 +-------------+ | +-------------+ 3357 | SNMPService |--+--| WebService | 3358 +-------------+ +-------------+ 3360 Figure 4.21 - The Service Class 3362 The aggregate classes that constitute Service are: 3364 name 3365 Zero or one. STRING. The name of the service. Whenever 3366 possible, the name from the IANA list of well-known ports 3367 SHOULD be used. 3369 port 3370 Zero or one. INTEGER. The port number being used. 3372 portlist 3374 Zero or one. PORTLIST. A list of port numbers being used; 3375 see Section 3.4.8 for formatting rules. 3377 protocol 3378 Zero or one. STRING. The protocol being used. 3380 A Service MUST be specified as either (a) a name, (b) a port, 3381 (c) a name and a port, or (d) a portlist. The protocol is 3382 optional in all cases, but no other combinations are permitted. 3384 Because DTDs do not support subclassing (see Section 4.3.4), 3385 the inheritance relationship between Service and the 3386 SNMPService and WebService subclasses shown in Figure 5.17 has 3387 been replaced with an aggregate relationship. Service is 3388 represented in the XML DTD as follows: 3390 3394 3398 The Service class has one attribute: 3400 ident 3401 Optional. A unique identifier for the service, see Section 3402 3.4.9. 3404 4.8.4.1 The WebService Class 3406 The WebService class augments the Service class with 3407 additional information related to web traffic. 3409 The WebService class is composed of four aggregate classes, 3410 as shown in Figure 4.22. 3412 +-------------+ 3413 | Service | 3414 +-------------+ 3415 /_\ 3416 | 3417 +-------------+ 3418 | WebService | 3419 +-------------+ +-------------+ 3420 | |<>----------| url | 3421 | | +-------------+ 3422 | | 0..1 +-------------+ 3423 | |<>----------| cgi | 3424 | | +-------------+ 3425 | | 0..1 +-------------+ 3426 | |<>----------| http-method | 3427 | | +-------------+ 3428 | | 0..* +-------------+ 3429 | |<>----------| arg | 3430 | | +-------------+ 3431 +-------------+ 3433 Figure 4.22 The WebService Class 3435 The aggregate classes that constitute WebService are: 3437 url 3438 Exactly one. STRING. The URL in the request. 3440 cgi 3441 Zero or one. STRING. The CGI script in the request, 3442 without arguments. 3444 http-method 3445 Zero or one. STRING. The HTTP method (PUT, GET) used in 3446 the request. 3448 arg 3449 Zero or more. STRING. The arguments to the CGI script. 3451 This is represented in the XML DTD as follows: 3453 3457 4.8.4.2 The SNMPService Class 3459 The SNMPService class augments the Service class with 3460 additional information related to SNMP traffic. 3462 The SNMPService class is composed of three aggregate 3463 classes, as shown in Figure 4.23. 3465 +-------------+ 3466 | Service | 3467 +-------------+ 3468 /_\ 3469 | 3470 +-------------+ 3471 | SNMPService | 3472 +-------------+ 0..1 +-----------+ 3473 | |<>----------| oid | 3474 | | +-----------+ 3475 | | 0..1 +-----------+ 3476 | |<>----------| community | 3477 | | +-----------+ 3478 | | 0..1 +-----------+ 3479 | |<>----------| command | 3480 | | +-----------+ 3481 +-------------+ 3483 Figure 4.23 The SNMPService Class 3485 The aggregate classes that constitute SNMPService are: 3487 oid 3488 Zero or one. STRING. The object identifier in the 3489 request. 3491 community 3492 Zero or one. STRING. The object's community string. 3494 command 3495 Zero or one. STRING. The command sent to the SNMP 3496 server (GET, SET. etc.). 3498 This is represented in the XML DTD as follows: 3500 3504 4.8.5 The Classification Class 3506 The Classification class provides a way to reference an 3507 external vulnerability, exposure, or virus database. 3509 The Classification class is composed of two aggregate classes, 3510 as shown in Figure 4.24. 3512 +----------------+ 3513 | Classification | 3514 +----------------+ +---------+ 3515 | STRING origin |<>------| name | 3516 | | +---------+ 3517 | | +---------+ 3518 | |<>------| url | 3519 | | +---------+ 3520 +----------------+ 3522 Figure 4.24 The Classification Class 3524 The aggregate classes that constitute Classification are: 3526 name 3527 Exactly one. STRING. The name of the Vulnerability, 3528 Exposure or Virus (from one of the origins listed below) 3529 used by Attacker to cause Incident. 3531 url 3532 Exactly one. STRING. A URL at which the manager can find 3533 additional information about classified method. The document 3534 pointed to by the URL may include an in-depth description of 3535 the attack, appropriate countermeasures, or other 3536 information deemed relevant by the vendor. 3538 This is represented in the XML DTD as follows: 3540 3543 3546 3550 The Classification class has one attribute: 3552 origin 3554 Required. The source from which the name of the alert 3555 originates. The permitted values for this attribute are 3556 shown below. The default value is "unknown". 3558 Rank Keyword Description 3559 ---- ------- ----------- 3560 0 unknown Origin of the name is not known 3561 1 bugtraqid The SecurityFocus.com ("Bugtraq") 3562 vulnerability database identifier 3563 (http://www.securityfocus.com/vdb) 3564 2 cve The Common Vulnerabilities and 3565 Exposures (CVE) name 3566 (http://www.cve.mitre.org/) 3567 3 vendor-specific A vendor-specific name (and hence, 3568 URL); this can be used to provide 3569 product-specific information 3571 4.8.6 The EvidenceData Class 3573 The EvidenceData class contains textual (e.g., logfiles, 3574 malicious scripts, list of changes if file system, etc.) and 3575 binary (e.g., disc images) evidence data related to current 3576 Incident. 3578 +------------------+ 3579 | Evidence | 3580 +------------------+ 3581 /_\ 3582 | 3583 +------------------+ 3584 | EvidenceData | 3585 +------------------+ 0..* +----------------+ 3586 | STRING ident |<>----------| CorrEvidence | 3587 | ENUM restriction | +----------------+ 3588 | | 0..1 +----------------+ 3589 | |<>----------| EvidenceDesc | 3590 | | +----------------+ 3591 | | 0..1 +----------------+ 3592 | |<>----------| EvidenceItem | 3593 | | +----------------+ 3594 +------------------+ 3596 Figure 4.25 The EvidenceData Class 3598 The aggregate classes that constitute EvidenceData are: 3600 CorrEvidence 3601 Zero or more. EvidenceData of the Evidence class that 3602 contains Evidence data correlated with current Evidence 3603 data. 3605 EvidenceDesc 3606 Zero or one. Description of the evidence found in the 3607 EvidenceItem class. 3609 EvidenceItem 3610 Zero or one. Container for a particular piece of evidence 3611 data. 3613 This is represented in the XML DTD as follows: 3615 3619 3622 3627 The EvidenceData class has two attributes: 3629 ident 3630 Optional. A unique identifier for this EvidenceData (see 3631 Section 3.4.9). 3633 restriction 3634 Optional. Sets a restriction on the usage of the data in 3635 element. 3637 4.8.6.1 The EvidenceDesc Class 3639 The EvidenceDesc class contains meta-information about 3640 evidence in the EvidenceItem class. 3642 +------------------+ 3643 | EvidenceDesc | 3644 +------------------+ 0..1 +----------------+ 3645 | |------------| DetectTime | 3646 | | +----------------+ 3647 | | 0..1 +----------------+ 3648 | |<>----------| Analyzer | 3649 | | +----------------+ 3650 | | 0..1 +----------------+ 3651 | |<>----------| description | 3652 | | +----------------+ 3653 +------------------+ 3654 Figure 4.26 The EvidenceDesc Class 3656 The aggregate classes that constitute EvidenceDesc are: 3658 DetectTime 3659 Zero or one. Timestamp of the evidence. This data MUST 3660 be present if it is not already represented in the 3661 EvidenceItem class. 3663 Analyzer 3664 Zero or one. The facility used to gather the evidence. 3665 The analyzer SHOULD define the name of the format, 3666 facility, tool, or device used to generate the evidence 3667 if it is not self-describing (e.g. xml). Likewise, the 3668 analyzer SHOULD define the Node which detected the 3669 evidence or from which it was extracted if this 3670 information is not represented elsewhere. 3672 description 3673 Zero or one. Free-form text to make comments on or 3674 annotate the evidence. 3676 This is represented in the XML DTD as follows: 3678 3682 4.8.6.2 The EventList Class 3684 The EventList class contains information about events which 3685 are treated as correlated with respect to current incident. 3687 +---------------------+ 3688 | CorrelationIncident | 3689 +---------------------+ 3690 /_\ 3691 | 3692 +--------------+ 3693 | EventList | 3694 +--------------+ 0..1 +----------------+ 3695 | |<>----------| IncidentID | 3696 | | +----------------+ 3697 | | 0..* +----------------+ 3698 | |<>----------| EvidenceDataID | 3699 | | +----------------+ 3700 | | 0..1 +----------------+ 3701 | |<>----------| DateTime | 3702 | | +----------------+ 3703 +--------------+ 3705 Figure 4.27 The EventList Class 3707 The aggregate classes that constitute EventList are: 3709 IncidentID 3710 Zero or one. Identification number of the Incident. 3712 EvidenceDataID 3713 Zero or more. Identification number of the EvidenceData 3714 element related to referenced event or IncidentID. 3716 DateTime 3717 Zero or one. Date and time when the event occured. 3719 EventList is represented in the XML DTD as follows: 3721 3723 3727 The EventList class has one attributes: 3729 ident 3730 Optional. A unique identifier for the EventList element 3731 (see Section 3.4.9). 3733 4.8.7 The Organization Class 3735 The Organization class describes a CSIRT involved in incident 3736 handling. This class is a mandatory subordinate element of the 3737 mandatory Authority class. 3739 +--------------+ 3740 | Authority | 3741 +--------------+ 3742 /_\ 3743 | 3744 +--------------+ 3745 | Organization | 3746 +--------------+ 0..1 +----------------+ 3747 | STRING ident |<>----------| OrganizationID | 3748 | | +----------------+ 3749 | | 0..1 +----------------+ 3750 | |<>----------| OrgName | 3751 | | +----------------+ 3752 | | 0..1 +----------------+ 3753 | |<>----------| OrgAddress | 3754 | | +----------------+ 3755 | | 0..1 +----------------+ 3756 | |<>----------| Email | 3757 | | +----------------+ 3758 | | 0..1 +----------------+ 3759 | |<>----------| Telephone | 3760 | | +----------------+ 3761 | | 0..1 +----------------+ 3762 | |<>----------| Fax | 3763 | | +----------------+ 3764 +--------------+ 3766 Figure 4.28 Organization Class 3768 The aggregate classes that constitute the Organization class 3769 are: 3771 OrganizationID 3772 Zero or one. The identification number of the Organization. 3773 The ID can be derived from known registries such as RIPE 3774 NCC, TI, etc. 3776 OrgName 3777 Zero or one. Name of the organization as it used in 3778 official post address. 3780 OrgAddress 3781 Zero or one. Address of the organization. 3783 Email 3784 Zero or one. Email address of the organization. 3786 Telephone 3787 Zero or one. Telephone number of the organization. 3789 Fax 3790 Zero or one. Fax number of the organization. 3792 At a minimum, the Organization class MUST have either a an 3793 OrgName or OrganizationID. 3795 Organization is represented in the XML DTD as follows: 3797 3800 3804 The Organization class has one attributes: 3806 ident 3807 Optional. A unique identifier for the Organization element 3808 (see Section 3.4.9). 3810 4.8.8 The Contact Class 3812 The Contact Class contains contact information for a person or 3813 role in a CSIRT handling an incident. 3815 +--------------+ 3816 | Authority | 3817 +--------------+ 3818 /_\ 3819 | 3820 +--------------+ 3821 | Contact | 3822 +--------------+ 0..1 +----------------+ 3823 | STRING ident |<>----------| PersonName | 3824 | | +----------------+ 3825 | | 0..1 +----------------+ 3826 | |<>----------| PersonAddress | 3827 | | +----------------+ 3828 | | 0..1 +----------------+ 3829 | |<>----------| ContactHandle | 3830 | | +----------------+ 3831 +--------------+ 3833 Figure 4.29 Contact Class 3835 The aggregate classes that constitute Contact class are: 3837 PersonName 3838 Zero or one. Name of the person responsible for handling 3839 the current incident. 3841 ContactHandle 3842 Zero or one. Identification number (or handle) used to 3843 refer to personal (or role) information in different 3844 Registries. 3846 PersonAddress 3847 Zero or one. Contact or physical Address of the person 3848 identified by PersonName. 3850 Contact is represented in the XML DTD as follows: 3852 3854 3858 The Contact class has one attribute: 3860 ident 3861 Optional. A unique identifier for the Contact element (see 3862 Section 3.4.9). 3864 4.8.9 The Reported Class 3866 The Reported class is subordinate class of the History class. 3867 It provided information about who and when reported current 3868 Incident, particularly identification number of the CSIRT that 3869 reported the Incident and time when it was reported. This 3870 element contains only AuthorityID from maintained by CSIRT 3871 database or from definite public register like RIPE NCC 3872 database or Trusted Introducer CSIRT database, assuming that 3873 CSIRT normally can accept information only from trusted source. 3875 +--------------+ 3876 | History | 3877 +--------------+ 3878 /_\ 3879 | 3880 +--------------+ 3881 | Reported | 3882 +--------------+ 0..1 +----------------+ 3883 | STRING ident |<>----------| AuthorityID | 3884 | | +----------------+ 3885 | | 0..1 +----------------+ 3886 | |<>----------| IncidentID | 3887 | | +----------------+ 3888 | | 0..1 +----------------+ 3889 | |<>----------| DateTime | 3890 | | +----------------+ 3891 +--------------+ 3893 Figure 4.30 Reported Class 3895 The aggregate classes that constitute Reported class are: 3897 IncidentID 3898 Zero or one. Identification number of the Incident as it 3899 reported by the Authority defined by AuthorityID. 3901 AuthorityID 3902 Zero or one. Identification number of the authority that 3903 reported current incident. 3905 DateTime 3906 Zero or one. Date and time when message was received. 3908 Reported is represented in the XML DTD as follows: 3910 3912 3916 The Reported class has one attributes: 3918 ident 3919 Optional. A unique identifier for the Reported element, see 3920 Section 3.4.9. 3922 4.8.10 The Received Class 3924 The Received class contains information about when and from 3925 whom the information about current incident was received. In 3926 particular case it may contain reference to message received 3927 from another CSIRT about current incident. This element 3928 contains only AuthorityID from maintained by CSIRT database or 3929 from definite public register like RIPE NCC database or Trusted 3930 Introducer CSIRT database, assuming that CSIRT normally can 3931 accept information only from trusted source. 3933 +--------------+ 3934 | History | 3935 +--------------+ 3936 /_\ 3937 | 3938 +--------------+ 3939 | Received | 3940 +--------------+ 0..1 +--------------+ 3941 | STRING ident |<>----------| AuthorityID | 3942 | | +--------------+ 3943 | | 0..1 +--------------+ 3944 | |<>----------| IncidentID | 3945 | | +--------------+ 3946 | | 0..1 +--------------+ 3947 | |<>----------| MessageID | 3948 | | +--------------+ 3949 | | 0..1 +--------------+ 3950 | |<>----------| DateTime | 3951 | | +--------------+ 3952 +--------------+ 3954 Figure 4.31 Received Class 3956 The aggregate classes that constitute Received class are: 3958 IncidentID 3959 Zero or one. Identification number of the Incident as it 3960 reported by the Authority defined by AuthorityID. 3962 MessageID 3963 Zero or one. Identification number of the message. 3965 AuthorityID 3966 Zero or one. Identification number of the authority that 3967 sent referenced message. 3969 DateTime 3970 Zero or one. Date and time when message was received. 3972 Received is represented in the XML DTD as follows: 3974 3976 3980 The Received class has one attributes: 3982 ident 3984 Optional. A unique identifier for the Received element, see 3985 Section 3.4.9. 3987 4.8.11 The ActionList Class 3989 The ActionList class represents a list of actions undertaken by 3990 the CSIRTs in the course of handling an incident. 3992 +------------------+ 3993 | History | 3994 +------------------+ 3995 /_\ 3996 | 3997 +------------------+ 3998 | ActionList | 3999 +------------------+ 0..*+--------------+ 4000 | ENUM restriction |<>----------| Action | 4001 | | +--------------+ 4002 | | 0..*+--------------+ 4003 | |<>----------| Description | 4004 | | +--------------+ 4005 | | 0..1+--------------+ 4006 | |<>----------| DateTime | 4007 | | +--------------+ 4008 +------------------+ 4010 Figure 4.32 ActionList Class 4012 The aggregate classes that constitute ActionList are: 4014 Action 4015 Zero or more. The action taken by the CSIRT in course of 4016 incident handling. 4018 Description 4019 Zero or more. A free-form text description of the action(s) 4020 taken by the CSIRT in course of handling the incident. 4022 DateTime 4023 Zero or one. Date and time when the action was performed. 4025 ActionList is represented in the XML DTD as follows: 4027 4029 4033 The ActionList class has two attributes: 4035 ident 4036 Optional. A unique identifier for the ActionList element 4037 (see Section 3.4.9). 4039 restriction 4040 Optional. Sets a restriction on the usage of the data in 4041 element. 4043 4.8.12. The FileList Class 4045 The FileList class describes files and other file-like objects 4046 on targets. It is primarily used as a "container" class for 4047 the File aggregate class, as shown in Figure 5.33. For the 4048 purpose of compatibility the FileList Class is reused from the 4049 IDMEF. 4051 +--------------+ 4052 | FileList | 4053 +--------------+ 1..* +------+ 4054 | |<>----------| File | 4055 | | +------+ 4056 +--------------+ 4058 Figure 4.33 The FileList Class 4060 The aggregate class contained in FileList is: 4062 File 4063 One or more. Information about an individual file, as 4064 indicated by its "category" and "fstype" attributes (see 4065 Section 4.8.13.1). 4067 This is represented in the XML DTD as follows: 4069 4073 4.8.12.1 The File Class 4075 The File class provides specific information about a file or 4076 other file-like object that has been created, deleted, or 4077 modified on the target. More than one File can be used 4078 within the FileList class to provide information about more 4079 than one file. The description can provide either the file 4080 settings prior to the event or the file settings at the time 4081 of the event, as specified using the "category" attribute. 4083 The File class is composed of ten aggregate classes, as 4084 shown in Figure 4.34. 4086 +--------------+ 4087 | File | 4088 +--------------+ +-------------+ 4089 | |<>----------| name | 4090 | | +-------------+ 4091 | | +-------------+ 4092 | |<>----------| path | 4093 | | +-------------+ 4094 | | 0..1 +-------------+ 4095 | |<>----------| create-time | 4096 | | +-------------+ 4097 | | 0..1 +-------------+ 4098 | |<>----------| modify-time | 4099 | | +-------------+ 4100 | | 0..1 +-------------+ 4101 | |<>----------| access-time | 4102 | | +-------------+ 4103 | | 0..1 +-------------+ 4104 | |<>----------| data-size | 4105 | | +-------------+ 4106 | | 0..1 +-------------+ 4107 | |<>----------| disk-size | 4108 | | +-------------+ 4109 | | 0..* +-------------+ 4110 | |<>----------| FileAccess | 4111 | | +-------------+ 4112 | | 0..* +-------------+ 4113 | |<>----------| Linkage | 4114 | | +-------------+ 4115 | | 0..1 +-------------+ 4116 | |<>----------| Inode | 4117 | | +-------------+ 4118 +--------------+ 4120 Figure 4.34 The File Class 4122 The aggregate classes that make up File are: 4124 name 4125 Exactly one. STRING. The name of the file to which the 4126 alert applies, not including the path to the file. 4128 path 4130 Exactly one. STRING. The full path to the file, 4131 including the name. The path name should be represented 4132 in as "universal" a manner as possible, to facilitate 4133 processing of the alert. 4135 For Windows systems, the path should be specified using 4136 the Universal Naming Convention (UNC) for remote files, 4137 and using a drive letter for local files (e.g., 4138 "C:\boot.ini"). For Unix systems, paths on network file 4139 systems should use the name of the mounted resource 4140 instead of the local mount point (e.g., 4141 "fileserver:/usr/local/bin/foo"). The mount point can be 4142 provided using the element. 4144 create-time 4145 Zero or one. DATETIME. Time the file was created. Note 4146 that this is *not* the Unix "st_ctime" file attribute 4147 (which is not file creation time). The Unix "st_ctime" 4148 attribute is contained in the "Inode" class. 4150 modify-time 4151 Zero or one. DATETIME. Time the file was last modified. 4153 access-time 4154 Zero or one. DATETIME. Time the file was last accessed. 4156 data-size 4157 Zero or one. INTEGER. The size of the data, in bytes. 4158 Typically what is meant when referring to file size. On 4159 Unix UFS file systems, this value corresponds to 4160 stat.st_size. On Windows NTFS, this value corres- ponds 4161 to VDL. 4163 disk-size 4164 Zero or one. INTEGER. The physical space on disk 4165 consumed by the file, in bytes. On Unix UFS file 4166 systems, this value corresponds to 512 * stat.st_blocks. 4167 On Windows NTFS, this value corresponds to EOF. 4169 FileAccess 4170 Zero or more. Access permissions on the file. 4172 Linkage 4173 Zero or more. File system objects to which this file is 4174 linked (other references for the file). 4176 Inode 4177 Zero or one. Inode information for this file (relevant 4178 to Unix). 4180 This is represented in the XML DTD as follows: 4182 4185 4189 4196 The File class has three attributes: 4198 ident 4199 Optional. A unique identifier for this file, see Section 4200 3.4.9. 4202 category 4203 Required. The context for the information being 4204 provided. The permitted values are shown below. There 4205 is no default value. 4207 Rank Keyword Description 4208 ---- ------- ----------- 4209 0 current The file information is from after the 4210 reported change 4211 1 original The file information is from before 4212 the reported change 4214 fstype Required. The type of file system the file resides 4215 on. The name should be specified using a standard 4216 abbreviation, e.g., "ufs", "nfs", "afs", "ntfs", "fat16", 4217 "fat32", "pcfs", "joliet", "cdfs", etc. This attribute 4218 governs how path names and other attributes are interpreted. 4220 4.8.12.2 The FileAccess Class 4222 The FileAccess class represents the access permissions on a 4223 file. The representation is intended to be usefule across 4224 operating systems. 4226 The FileAccess class is composed of two aggregate classes, 4227 as shown in Figure 4.35. 4229 +--------------+ 4230 | FileAccess | 4231 +--------------+ +------------+ 4232 | |<>----------| UserId | 4233 | | +------------+ 4234 | | 1..* +------------+ 4235 | |<>----------| permission | 4236 | | +------------+ 4237 +--------------+ 4239 Figure 4.35 The FileAccess Class 4241 The aggregate classes that make up FileAccess are: 4243 UserId 4244 Exactly one. The user (or group) to which these 4245 permissions apply. The value of the "type" attribute 4246 must be "user-privs", "group-privs", or "other-privs" as 4247 appropriate. Other values for "type" MUST NOT be used in 4248 this context. 4250 permission 4251 One or more. STRING. Level of access allowed. 4252 Recommended values are "noAccess", "read", "write", 4253 "execute", "delete", "executeAs", "changePermissions", 4254 and "takeOwnership". The "changePermissions" and 4255 "takeOwnership" strings represent those concepts in 4256 Windows. On Unix, the owner of the file always has 4257 "changePermissions" access, even if no other access is 4258 allowed for that user. "Full Control" in Windows is 4259 represented by enumerating the permissions it contains. 4260 The "executeAs" string represents the set-user-id and 4261 set-group-id features in Unix. 4263 This is represented in the XML DTD as follows: 4265 4269 4.8.12.3 The Linkage Class 4270 The Linkage class represents file system connections between 4271 the file described in the element and other objects 4272 in the file system. For example, if the element is a 4273 symbolic link or shortcut, then the element should 4274 contain the name of the object the link points to. Further 4275 information can be provided about the object in the 4276 element with another element, if 4277 appropriate. 4279 The Linkage class is composed of three aggregate classes, as 4280 shown in Figure 4.36. 4282 +--------------+ 4283 | Linkage | 4284 +--------------+ +------+ 4285 | |<>----------| name | 4286 | | +------+ 4287 | | +------+ 4288 | |<>----------| path | 4289 | | +------+ 4290 | | +------+ 4291 | |<>----------| File | 4292 | | +------+ 4293 +--------------+ 4295 Figure 4.36 The Linkage Class 4297 The aggregate classes that make up Linkage are: 4299 name 4300 Exactly one. STRING. The name of the file system object 4301 not including the path. 4303 path 4304 Exactly one. STRING. The full path to the file system 4305 object, including the name. The path name should be 4306 represented in as "universal" a manner as possible, to 4307 facilitate processing of the alert. 4309 File 4310 Exactly one. A element may be used in place of 4311 the and elements if additional information 4312 about the file is to be included. 4314 The is represented in the XML DTD as follows: 4316 4321 4324 4328 The Linkage class has one attribute: 4330 category 4331 The type of object that the link describes. The 4332 permitted values are shown below. There is no default 4333 value. 4335 Rank Keyword Description 4336 ---- ------- ----------- 4337 0 hard-link The element represents another 4338 name for this file. This information 4339 may be more easily obtainable on NTFS 4340 file systems than others. 4341 1 mount-point An alias for the directory specified 4342 by the parent's and 4343 elements. 4344 2 reparse-point Applies only to Windows; excludes 4345 symbolic links and mount points, 4346 which are specific types of reparse 4347 points. 4348 3 shortcut The file represented by a Windows 4349 "shortcut." A shortcut is 4350 distinguished from a symbolic link 4351 because of the difference in their 4352 contents, which may be of importance 4353 to the manager. 4354 4 stream An Alternate Data Stream (ADS) in 4355 Windows; a fork on MacOS. Separate 4356 file system entity that is considered 4357 an extension of the main . 4358 5 symbolic-link The element represents the 4359 file to which the link points. 4361 4.8.12.4 The Inode Class 4363 The Inode class is used to represent the additional 4364 information contained in a Unix file system i-node. 4366 The Inode class is composed of six aggregate classes, as 4367 shown in Figure 4.37. 4369 +--------------+ 4370 | Inode | 4371 +--------------+ +----------------+ 4372 | |<>----------| change-time | 4373 | | +----------------+ 4374 | | +----------------+ 4375 | |<>----------| number | 4376 | | +----------------+ 4377 | | +----------------+ 4378 | |<>----------| major-device | 4379 | | +----------------+ 4380 | | +----------------+ 4381 | |<>----------| minor-device | 4382 | | +----------------+ 4383 | | +----------------+ 4384 | |<>----------| c-major-device | 4385 | | +----------------+ 4386 | | +----------------+ 4387 | |<>----------| c-minor-device | 4388 | | +----------------+ 4389 +--------------+ 4391 Figure 4.37 The Inode Class 4393 The aggregate classes that make up Inode are: 4395 change-time 4396 Zero or one. DATETIME. The time of the last inode 4397 change, given by the st_ctime element of "struct stat". 4399 number 4400 Zero or one. INTEGER. The inode number. 4402 major-device 4403 Zero or one. INTEGER. The major device number of the 4404 device the file resides on. 4406 minor-device 4407 Zero or one. INTEGER. The minor device number of the 4408 device the file resides on. 4410 c-major-device 4411 Zero or one. INTEGER. The major device of the file 4412 itself, if it is a character special device. 4414 c-minor-device 4415 Zero or one. INTEGER. The minor device of the file 4416 itself, if it is a character special device. 4418 Note that , , and must 4419 be given together, and the and 4420 must be given together. 4422 This is represented in the XML DTD as follows: 4424 4429 4.8.13 The Analyzer Class 4431 The Analyzer class identifies the facility used to gather the 4432 evidence or tool generated Incident Alert. In case when Initial 4433 Incident registration is produced from the IDMEF message the 4434 Analyzer description may be taken from the IDMEF message where 4435 the Analyzer Class is mandatory and only one. 4437 The analyzer SHOULD define the name of the format, facility, 4438 tool, or device used to generate the evidence if it is not 4439 self-describing (e.g. xml). Likewise, the analyzer SHOULD 4440 define the Node which detected the evidence or from which it 4441 was extracted if this information is not represented elsewhere. 4443 For the purpose of compatibility the Analyzer Class is reused 4444 from the IDMEF. 4446 The Analyzer class is composed of two aggregate classes, as 4447 shown in Figure 4.38. 4449 +---------------------+ 4450 | Analyzer | 4451 +---------------------+ 0..1 +---------+ 4452 | STRING analyzerid |<>----------| Node | 4453 | STRING manufacturer | +---------+ 4454 | STRING model | 0..1 +---------+ 4455 | STRING version |<>----------| Process | 4456 | STRING class | +---------+ 4457 | STRING ostype | 4458 | STRING osversion | 4459 +---------------------+ 4461 Figure 4.38 The Analyzer Class 4463 The aggregate classes that make up Analyzer are: 4465 Node 4466 Zero or one. Information about the host or device on which 4467 the analyzer resides (network address, network name, etc.). 4469 Process 4470 Zero or one. Information about the process in which the 4471 analyzer is executing. 4473 This is represented in the XML DTD as follows: 4475 4478 4488 The Analyzer class has seven attributes: 4490 analyzerid 4491 Optional. The attribute may be taken from the IDMEF message 4492 generated by Analyzer/IDS. For details see [IDMEF]. 4494 manufacturer 4495 Optional. The manufacturer of the analyzer software and/or 4496 hardware. 4498 model 4499 Optional. The model name/number of the analyzer software 4500 and/or hardware. 4502 version 4503 Optional. The version number of the analyzer software 4504 and/or hardware. 4506 class 4507 Optional. The class of analyzer software and/or hardware. 4509 ostype 4510 Optional. Operating system name. On POSIX systems, this is 4511 the value returned in utsname.sysname by the uname() system 4512 call, or the output of the "uname -s" command. 4514 osversion 4515 Optional. Operating system version. On POSIX systems, this 4516 is the value returned in utsname.release by the uname() 4517 system call, or the output of the "uname -r" command. 4519 The "manufacturer", "model", "version", and "class" attributes' 4520 contents are vendor-specific, but may be used together to 4521 identify different types of analyzers. 4523 4.9 Simple Classes 4525 The simple classes do not have subclasses. The purpose of 4526 describing some of the simple classes in this section is to 4527 provide information about attributes used to describe the data of 4528 these classes. 4530 4.9.1 The Description Class 4532 The Description class is a general-purpose class for any 4533 natural language free-form text. 4535 Using the XML language attribute, it is reasonable to include 4536 text in a number of different languages in different instances 4537 of the Description class. For details on declaring language 4538 attribute see section 3.3.3. 4540 4542 4.9.2 The IRTcontact Class 4544 The IRTcontact class contains an IRTcontact handle to a public 4545 registry (e.g., RIPE NCC database [18], Trusted Introducer 4546 database [19]) that references contact information for the 4547 CSIRT or network security manager serving the networks 4548 referenced in the Attacker or Victim class. 4550 This is represented in the XML DTD as follows: 4552 4555 4556 4559 IRTcontact class has one attribute: 4561 originIRT 4562 Required. The registry which the IRTcontact handle 4563 references. The permitted values for this attribute are 4564 shown below. The default value is "unknown". 4566 Rank Keyword Description 4567 ---- ------- ----------- 4568 0 unknown Origin of the name is not known 4569 1 ripencc RIPE NCC database 4570 2 ti Trusted Introducer database of CSIRTs 4571 3 arin ARIN database 4572 4 apnic APNIC database 4573 5 afnic AFNIC database 4574 6 local Name of IRT as it used by Incident object 4575 creator 4577 4.9.3 The EvidenceItem Class 4579 The EvidenceItem class is a container for the arbitrary 4580 evidence data. 4582 This is represented in the XML DTD as follows: 4584 4588 4589 4593 The EvidenceItem class has one attribute: 4595 dtype 4596 Required. The type of data included in the element content. 4597 The permitted values for this attribute are shown below. 4598 The default value is "string". 4600 Rank Keyword Description 4601 ---- ------- ----------- 4602 0 boolean The element contains a boolean value, i.e., 4603 the strings "true" or "false" 4604 1 byte The element content is a single 8-bit byte 4605 (see Section 3.4.4) 4607 2 character The element content is a single character 4608 (see Section 3.4.3) 4609 3 integer The element content is an integer (see 4610 Section 3.4.1) 4611 4 string The element content is a string (see Section 4612 3.4.3) 4613 5 binary The element content is base-64 encoded 4614 binary data. 4615 6 xml The element content is XML-tagged data 4616 (see Section 5.2) 4617 7 file The element contains a name of file that 4618 may be stored on any media, this 4619 information should be necessary for CSIRT 4620 8 path The element content is a path to a file 4621 location on IHS system 4622 9 url The element content is a URL to the data 4624 4.9.4 The CorrEvidence Class 4626 The CorrEvidence class references the ID of other related 4627 EvidenceData for correlation. 4629 This is represented in the XML DTD as follows: 4631 4634 4638 The CorrEvidence class has one attribute: 4640 IncidentID 4641 Optional. The type of data included in the element content. 4642 The permitted values for this attribute are shown below. 4643 The default value is "string". 4645 4.9.5 The Name Class 4647 The Name class contains the name of a contact person at a 4648 CSIRT. 4650 This is represented in the XML DTD as follows: 4652 4655 4656 4660 The Name class has one attribute: 4662 nametype 4663 Required. Type of name or source of name/role handle. 4665 Rank Keyword Description 4666 ---- ------- ----------- 4667 0 dn Distinguished name (personal name). 4668 Format as described in section 3.4.10 4669 1 internic Name/role handle from InterNIC database 4670 2 ripencc Name/role handle from RIPE NCC database 4672 5. Extending the IODEF 4674 In order to support the changing activity of CSIRTS, the IODEF data 4675 model and DTD will need to evolve along with them. To allow new 4676 features to be added, both the data model and the DTD can be extended 4677 as described in this section. As these extensions mature, they can 4678 then be incorporated into future versions of the specification. 4680 5.1 Extending the Data Model 4682 There are two mechanisms for extending the IODEF data model: 4683 inheritance and aggregation (see Section 3.1.1). 4685 + By using inheritance, new subclasses may be derived and given 4686 additional attributes or operations not found in the 4687 superclass. 4689 + Aggregation allows for entirely new, self-contained classes to 4690 be created and associated with a parent class. 4692 Of the two extension mechanisms, inheritance is preferred, because 4693 it preserves the existing data model and the operations (methods) 4694 executed on the classes of the model. There are explicit 4695 guidelines for extending the XML DTD (see Section 5.2) which set 4696 limits on where extensions to the data model may be made. 4698 5.2 Extending the XML DTD 4699 There are two ways to extend the IODEF XML DTD: 4701 1. The AdditionalData class (see Section 4.2.4.5) allows 4702 implementers to include arbitrary "atomic" data items 4703 (integers, strings, etc.) in an Incident or IncidentAlert 4704 class. This approach SHOULD be used whenever possible. 4706 2. The AdditionalData class allows implementers to extend the 4707 IODEF XML DTD with additional DTD "modules" that describe 4708 arbitrarily complex data types and relationships. 4710 To extend the IODEF DTD with a new DTD "module," these guidelines 4711 MUST be followed: 4713 1. The IODEF description MUST include a document type declaration 4714 (see Section 3.3.1.3). 4716 2. The document type declaration MUST define a parameter entity 4717 (see Section 3.2.4) that contains the location of the extension 4718 DTD, and then reference that entity: 4720 4724 %x-extension; 4725 ]> 4727 In this example, the "x-extension" parameter entity is defined 4728 and then referenced, causing the DTD for the extension to be 4729 read by the XML parser. 4731 The name of the parameter entity defined for this purpose MUST 4732 be a string beginning with "x-"; there are no other 4733 restrictions on the name (other than those imposed on all 4734 entity names by XML). 4736 Multiple extensions may be included by defining multiple 4737 entities and referencing them. For example: 4739 4743 4744 %x-extension; 4745 %x-another; 4746 ]> 4748 3. Extension DTDs MUST declare all of their elements and 4749 attributes in a separate XML namespace. Extension DTDs MUST 4750 NOT declare any elements or attributes in the "IODEF" or 4751 default namespaces. 4753 For example, the "test" extension might be declared as follows: 4755 4758 4762 4763 4767 4768 4770 4. Extensions MUST only be included in the AdditionalData class of 4771 the Incident class whose "type" attribute is "xml". For 4772 example: 4774 4775 4776 ... 4777 4778 4781 ... 4782 ... 4783 ... 4784 4785 4786 4787 4789 6. Special Considerations 4791 This section discusses some of the special considerations that must 4792 be taken into account by implementers of the IODEF. 4794 6.1 XML Validity and Well-Formedness 4796 It is expected that IODEF-compliant applications will normally not 4797 include the IODEF DTD in their communications. Instead, the DTD 4798 will be referenced in the document type declaration of the IODEF 4799 document rsee Section 3.3.1). Such IODEF documents will be 4800 well-formed and valid as defined in [5]. 4802 Other IODEF documents will be specified that do not include the 4803 document prolog (e.g., entries in an IODEF-format database). Such 4804 IODEF documents will be well-formed but not valid. 4806 Generally, well-formedness implies that a document has a single 4807 element that contains everything else (e.g., ""), and that 4808 all the other elements nest nicely within each other without any 4809 overlapping (e.g., a "chapter" does not start in the middle of 4810 another "chapter"). 4812 Validity further implies that not only is the document 4813 well-formed, but it also follows specific rules (contained in the 4814 Document Type Definition) about which elements are "legal" in the 4815 document, how those elements nest within other elements, and so on 4816 (e.g., a "chapter" does not begin in the middle of a "title"). A 4817 document cannot be valid unless it references a DTD. 4819 XML processors are required to parse any well-formed document, 4820 valid or not. The purpose of validation is to make the processing 4821 of the document (what's done with the data after it's parsed) 4822 easier. Without validation, a document may contain elements in 4823 nonsense order, elements "invented" by the author that the 4824 processing application doesn't understand, and so on. 4826 IODEF documents MUST be well-formed. IODEF documents SHOULD be 4827 valid whenever both possible and practical. 4829 6.2 Unrecognized XML Tags 4831 On occasion, an IODEF-compliant application may receive a well- 4832 formed, or even well-formed and valid, IODEF document containing 4833 tags that it does not understand. The tags may be either: 4835 + Recognized as "legitimate" (a valid document), but the 4836 application does not know the semantic meaning of the element's 4837 content; or 4839 + Not recognized at all. 4841 IODEF-compliant applications MUST continue to process IODEF 4842 documents that contain unknown tags, provided that these documents 4843 are well- formed (see Section 6.1). It is up to the individual 4844 application to decide how to process (or ignore) any content from 4845 the unknown tag(s). 4847 Special issue is related to inheritance relation between 4848 Incident/Attacker related classes IDMEF and IODEF, e.g. IODEF 4849 message may be simply wrap up into IDMEF container for the 4850 IncidentAlert class. 4852 In particular case of relations between IODEF and IDMEF, the IODEF 4853 may be treated as IDMEF extension applying inheritance to 4854 incorporate Alert/IDMEF data structure into Attack Class of IODEF. 4856 When Incident description is produced of IDMEF message, IODEF may 4857 use directly related data classes from IDMEF. In this context it 4858 is recommended that IHS understands both format - IODEF and IDMEF. 4859 This may be achieved by mapping part of IDMEF classes (XML tags) 4860 related to Attack description into IODEF classes. This is to be 4861 not difficult task because of initial approach to match IODEF and 4862 IDMEF XML namespaces. Otherwise IODEF parser will still be able to 4863 parser well- formed IDMEF document and recognize important XML 4864 tags, which meaning in IODEF is inherited from IDMEF. 4866 6.3 Digital Signatures 4868 The joint IETF/W3C XML Signature Working Group is currently 4869 working to specify XML digital signature processing rules and 4870 syntax [16]. XML Signatures provide integrity, message 4871 authentication, and/or signer authentication services for data of 4872 any type, whether located within the XML that includes the 4873 signature or elsewhere. 4875 The IODEF requirements [2] recommend that the IODEF should support 4876 content confidentiality, integrity, authentication and non- 4877 repudiation. These requirements can be achieved by the inclusion 4878 of digital signatures within an IODEF document. Additional 4879 security considerations may be applied to the communications 4880 methods and protocols used for IODEF documents exchange. 4882 Specifications for the use of digital signatures within IODEF 4883 documents are outside the scope of this document. If such 4884 functionality is needed, the use of the XML Signature standard is 4885 RECOMMENDED. 4887 7. Experimental implementation and examples 4888 There is an ongoing effort among a few European CSIRTs to implement 4889 IODEF in their daily incident handling work [17]. The results this 4890 project should be available in late 2001. 4892 This section provides examples of IODEF encoded Incident data. The 4893 examples are provided for illustrative purposes only and do not 4894 necessarily represent the only (or even the "best") way to encode 4895 these particular incidents. 4897 8. The IODEF Document Type Definition 4899 4901 4914 4919 4922 4923 4926 4927 4930 4931 4935 4936 4939 4940 4943 4944 4947 4948 4953 4958 4961 4966 4974 4980 4983 4988 4991 4995 4998 5002 5005 5009 5012 5015 5018 5021 5024 5027 5030 5035 5038 5041 5044 5047 5050 5053 5056 5060 5063 5069 5072 5075 5078 5081 5084 5087 5089 5092 5095 5098 5102 5105 5112 5113 5117 5119 5125 5126 5131 5138 5140 5145 5146 5152 5153 5157 5158 5163 5164 5168 5169 5173 5175 5179 5180 5184 5185 5189 5196 5197 5202 5209 5210 5212 5218 5219 5225 5226 5227 5232 5233 5238 5239 5242 5243 5244 5254 5256 5259 5260 5263 5271 5273 5278 5279 5286 5287 5290 5291 5295 5297 5301 5302 5305 5306 5311 5312 5317 5318 5321 5323 5324 5327 5330 5336 5337 5340 5342 5345 5346 5350 5351 5354 5355 5358 5360 5363 5364 5367 5368 5371 5372 5375 5380 5381 5382 5388 5389 5393 5394 5398 5399 5402 5403 5406 5407 5411 5412 5416 5417 5421 5422 5426 5427 5430 5431 5434 5435 5438 5439 5442 5443 5446 5447 5450 5456 5457 5460 5461 5464 5470 5471 5474 5475 5479 5480 5483 5484 5487 5488 5491 5492 5495 5496 5499 5500 5503 5504 5507 5508 5511 5512 5515 5516 5519 5520 5523 5524 5527 5528 5531 5532 5535 5536 5539 5540 5543 5544 5547 5548 5551 5552 5555 5556 5559 5560 5563 5564 5567 5568 5571 5572 5575 5576 5579 5580 5583 5584 5587 5588 5591 5592 5595 5596 5599 5600 5603 5604 5607 5608 5611 5612 5615 5616 5619 5620 5623 5624 5627 5628 5632 9. References 5634 [1] Bradner, S., "Key words for use in RFCs to Indicate 5635 Requirement Levels", BCP 14, RFC 2119, March 1997 5637 [2] Arvidsson, J., Cormack, A., Demchenko, Y., Meijer J. "TERENA's 5638 Incident Object Description and Exchange Format Requirements", 5639 RFC 3067, February 2001 5641 [3] Intrusion Detection Message Exchange Format Extensible Markup 5642 Language (XML) Document Type Definition by D. Curry - September 5643 2001 - http://www.ietf.org/internet-drafts/draft-ietf-idwg- 5644 idmef-xml-06.txt - work in progress. 5646 [4] Taxonomy of the Computer Security Incident related terminology 5647 - http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/docs/ 5648 i-taxonomy_terms.html 5650 [5] World Wide Web Consortium (W3C), "Extensible Markup Language 5651 (XML) 1.0 (Second Edition)," W3C Recommendation, October 6, 5652 2000. http://www.w3.org/TR/2000/REC-xml-20001006. 5654 [6] World Wide Web Consortium (W3C), "Namespaces in XML," W3C 5655 Recommendation, January 14, 1999. http://www.w3.org/TR/1999/ 5656 REC-xml-names-19990114. 5658 [7] XML Schema Part 0: Primer, W3C Recommendation, 2 May 2001. 5659 http://www.w3.org/TR/xmlschema-0/ 5661 [8] Berners-Lee, T., Fielding, R.T., and L. Masinter, "Uniform 5662 Resource Identifiers (URI): Generic Syntax," RFC 2396, August 5663 1998. 5665 [9] Mealling, M., "The IANA XML Registry," draft-mealling-iana- 5666 xmlns-registry-00.txt, November 17, 2000, work in progress. 5667 [10] Rumbaugh, J., Jacobson, I., and G. Booch, "The Unified 5668 Modeling Language Reference Model," ISBN 020130998X, 5669 Addison-Wesley, 1998. 5671 [11] Freed, N., "IANA Charset Registration Procedures," BCP 19, RFC 5672 2278, January 1998. 5674 [12] Alvestrand, H., "Tags for the Identification of Languages," 5675 RFC 3066, BCP 47, January 2001. 5677 [13] International Organization for Standardization (ISO), 5678 "International Standard: Data elements and interchange 5679 formats - Information interchange - Representation of dates 5680 and times," ISO 8601, Second Edition, December 15, 2000. 5682 [14] Mills, D., "Network Time Protocol (Version 3) Specification, 5683 Implementation, and Analysis," RFC 1305, March 1992. 5685 [15] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for 5686 IPv4, IPv6 and OSI," RFC 2030, October 1996. 5688 [16] Eastlake, D., Reagle, J., and D. Solo, "XML-Signature Syntax 5689 and Processing," draft-ietf-xmldsig-core-11.txt, November 1, 5690 2000, work in progress. 5692 [17] Incident Object Description and Exchange Format Working Group - 5693 http://www.terena.nl/task-forces/tf-csirt/iodef/ 5695 [18] Incident Object Data model - 5696 http://www.terena.nl/task-forces/tf-csirt/iodef/docs/ 5698 [19] RIPE NCC Database - http://www.ripe.net/ripe/wg/db/ 5700 [20] Trusted Introducer Service - http://www.ti.terena.nl/ 5702 10. Security Considerations 5704 11. IANA Considerations 5706 12. Acknowledgements 5708 This document was built on the work done by the Incident Object 5709 Description and Exchange Format Working-Group of the TERENA 5710 task-force TF-CSIRT. 5712 13. Authors' Addresses: 5714 Jan Meijer 5715 SURFnet 5716 Radboudburcht 273 5717 Utrecht 5718 The Netherlands 5719 Phone: +31 302 305 305 5720 Email: jan.meijer@surfnet.nl 5722 Roman Danyliw 5723 CERT Coordination Center 5724 4500 Fifth Ave. 5725 Pittsburgh PA 15213 5726 USA 5727 Phone: +1 412 268 7090 5728 Email: rdd@cert.org 5730 Yuri Demchenko 5731 TERENA 5732 Singel 468 D 5733 1017 AW Amsterdam 5734 The Netherlands 5735 Phone: +31 205 304 488 5736 Email: demch@terena.nl 5738 14. Full Copyright Statement 5740 Copyright (C) The Internet Society (2002). All Rights Reserved. 5742 This document and translations of it may be copied and furnished to 5743 others, and derivative works that comment on or otherwise explain it 5744 or assist in its implementation may be prepared, copied, published 5745 and distributed, in whole or in part, without restriction of any 5746 kind, provided that the above copyright notice and this paragraph are 5747 included on all such copies and derivative works. However, this 5748 document itself may not be modified in any way, such as by removing 5749 the copyright notice or references to the Internet Society or other 5750 Internet organizations, except as needed for the purpose of 5751 developing Internet standards in which case the procedures for 5752 copyrights defined in the Internet Standards process must be 5753 followed, or as required to translate it into languages other than 5754 English. 5756 The limited permissions granted above are perpetual and will not be 5757 revoked by the Internet Society or its successors or assigns. 5759 This document and the information contained herein is provided on an 5760 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 5761 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 5762 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 5763 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 5764 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."