idnits 2.17.1 draft-ietf-idwg-idmef-xml-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 7278. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 7255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 7262. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 7268. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance 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 (March 16, 2006) is 6587 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: 'BF' on line 6091 -- Looks like a reference, but probably isn't: 'HD' on line 6166 == Unused Reference: '10' is defined on line 5875, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 5884, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-idwg-requirements (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2396 (ref. '5') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 1305 (ref. '7') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2030 (ref. '8') (Obsoleted by RFC 4330) ** Obsolete normative reference: RFC 2434 (ref. '9') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3066 (ref. '10') (Obsoleted by RFC 4646, RFC 4647) -- Obsolete informational reference (is this intentional?): RFC 2278 (ref. '13') (Obsoleted by RFC 2978) Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Intrusion Detection Exchange H. Debar 3 Format France Telecom 4 Internet-Draft D. Curry 5 Expires: September 17, 2006 Guardian 6 B. Feinstein 7 TNT 8 March 16, 2006 10 The Intrusion Detection Message Exchange Format 11 draft-ietf-idwg-idmef-xml-16 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 17, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 The purpose of the Intrusion Detection Message Exchange Format 45 (IDMEF) is to define data formats and exchange procedures for sharing 46 information of interest to intrusion detection and response systems, 47 and to the management systems which may need to interact with them. 49 This Internet-Draft describes a data model to represent information 50 exported by intrusion detection systems, and explains the rationale 51 for using this model. An implementation of the data model in the 52 Extensible Markup Language (XML) is presented, an XML Document Type 53 Definition is developed, and examples are provided. 55 Table of Contents 57 1. Notices and conventions Used in This Document . . . . . . . . 4 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. About the IDMEF Data Model . . . . . . . . . . . . . . . 5 60 2.1.1. Problems Addressed by the Data Model . . . . . . . . 5 61 2.1.2. Data Model Design Goals . . . . . . . . . . . . . . . 7 62 2.2. About the IDMEF XML Implementation . . . . . . . . . . . 8 63 2.2.1. The Extensible Markup Language . . . . . . . . . . . 8 64 2.2.2. Rationale for Implementing IDMEF in XML . . . . . . . 9 65 3. Notational Conventions and Formatting Issues . . . . . . . . 11 66 3.1. IDMEF XML Documents . . . . . . . . . . . . . . . . . . . 11 67 3.1.1. The Document Prolog . . . . . . . . . . . . . . . . . 11 68 3.1.2. Character Data Processing in IDMEF . . . . . . . . . 12 69 3.1.3. Languages in IDMEF . . . . . . . . . . . . . . . . . 12 70 3.2. IDMEF Data Types . . . . . . . . . . . . . . . . . . . . 13 71 3.2.1. Integers . . . . . . . . . . . . . . . . . . . . . . 13 72 3.2.2. Real Numbers . . . . . . . . . . . . . . . . . . . . 13 73 3.2.3. Characters and Strings . . . . . . . . . . . . . . . 13 74 3.2.4. Bytes . . . . . . . . . . . . . . . . . . . . . . . . 14 75 3.2.5. Enumerated Types . . . . . . . . . . . . . . . . . . 15 76 3.2.6. Date-Time Strings . . . . . . . . . . . . . . . . . . 15 77 3.2.7. NTP Timestamps . . . . . . . . . . . . . . . . . . . 17 78 3.2.8. Port Lists . . . . . . . . . . . . . . . . . . . . . 17 79 3.2.9. Unique Identifiers . . . . . . . . . . . . . . . . . 17 80 4. The IDMEF Data Model and DTD . . . . . . . . . . . . . . . . 19 81 4.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 19 82 4.2. The Message Classes . . . . . . . . . . . . . . . . . . . 20 83 4.2.1. The IDMEF-Message Class . . . . . . . . . . . . . . . 20 84 4.2.2. The Alert Class . . . . . . . . . . . . . . . . . . . 21 85 4.2.3. The Heartbeat Class . . . . . . . . . . . . . . . . . 28 86 4.2.4. The Core Classes . . . . . . . . . . . . . . . . . . 30 87 4.2.5. The Time Classes . . . . . . . . . . . . . . . . . . 41 88 4.2.6. The Assessment Classes . . . . . . . . . . . . . . . 43 89 4.2.7. The Support Classes . . . . . . . . . . . . . . . . . 47 90 5. Extending the IDMEF . . . . . . . . . . . . . . . . . . . . . 79 91 5.1. Extending the Data Model . . . . . . . . . . . . . . . . 79 92 5.2. Extending the IDMEF DTD . . . . . . . . . . . . . . . . . 79 93 6. Special Considerations . . . . . . . . . . . . . . . . . . . 81 94 6.1. XML Validity and Well-Formedness . . . . . . . . . . . . 81 95 6.2. Unrecognized XML Tags . . . . . . . . . . . . . . . . . . 81 96 6.3. Analyzer-Manager Time Synchronization . . . . . . . . . . 82 97 6.4. NTP Timestamp Wrap-Around . . . . . . . . . . . . . . . . 83 98 6.5. Digital Signatures . . . . . . . . . . . . . . . . . . . 84 99 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 86 100 7.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 86 101 7.1.1. The "teardrop" Attack . . . . . . . . . . . . . . . . 86 102 7.1.2. The "ping of death" Attack . . . . . . . . . . . . . 87 103 7.2. Port Scanning Attacks . . . . . . . . . . . . . . . . . . 89 104 7.2.1. Connection To a Disallowed Service . . . . . . . . . 89 105 7.2.2. Simple Port Scanning . . . . . . . . . . . . . . . . 90 106 7.3. Local Attacks . . . . . . . . . . . . . . . . . . . . . . 91 107 7.3.1. The "loadmodule" Attack . . . . . . . . . . . . . . . 92 108 7.3.2. The "phf" Attack . . . . . . . . . . . . . . . . . . 94 109 7.3.3. File Modification . . . . . . . . . . . . . . . . . . 95 110 7.4. System Policy Violation . . . . . . . . . . . . . . . . . 97 111 7.5. Correlated Alerts . . . . . . . . . . . . . . . . . . . . 99 112 7.6. Analyzer Assessments . . . . . . . . . . . . . . . . . . 100 113 7.7. Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . 101 114 7.8. XML Extension . . . . . . . . . . . . . . . . . . . . . . 103 115 8. The IDMEF Document Type Definition (Normative) . . . . . . . 106 116 9. Security Considerations . . . . . . . . . . . . . . . . . . . 120 117 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 121 118 10.1. Adding Values to Existing Attributes . . . . . . . . . . 121 119 10.1.1. Attribute Registrations . . . . . . . . . . . . . . . 121 120 10.1.2. Registration Template . . . . . . . . . . . . . . . . 134 121 10.2. Adding New Attributes and Classes . . . . . . . . . . . . 135 122 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 136 123 11.1. Normative References . . . . . . . . . . . . . . . . . . 136 124 11.2. Informational References . . . . . . . . . . . . . . . . 136 125 Appendix A. History of Significant Changes . . . . . . . . . . . 138 126 A.1. Things to do before publication . . . . . . . . . . . . . 138 127 A.2. Response to IESG comments . . . . . . . . . . . . . . . . 138 128 A.2.1. Comment on Section 3.1.3 . . . . . . . . . . . . . . 138 129 A.2.2. Comment on Section A.3.4 . . . . . . . . . . . . . . 138 130 A.2.3. Comment on Section 3.2 . . . . . . . . . . . . . . . 138 131 A.2.4. Comment on section 3.2.4 . . . . . . . . . . . . . . 139 132 A.2.5. Comment on 3.2.5 Enumerated Types . . . . . . . . . . 139 133 A.2.6. Comment on Section 4.* . . . . . . . . . . . . . . . 140 134 A.2.7. Comment on Section 5 . . . . . . . . . . . . . . . . 140 135 A.2.8. Comment on Section 7.8 . . . . . . . . . . . . . . . 141 136 A.3. Significant Changes Since idmef-10 . . . . . . . . . . . 142 137 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 144 138 Appendix C. The IDMEF Schema Definition (Non-normative) . . . . 145 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 166 140 Intellectual Property and Copyright Statements . . . . . . . . . 167 142 1. Notices and conventions Used in This Document 144 The keywords "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," 145 "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [1]. 148 An "IDMEF-compliant application" is a program or program component, 149 such as an analyzer or manager, that reads and/or writes messages in 150 the format specified by this memo. 152 An "IDMEF document" is a message that adheres to the requirements 153 specified by this memo, and that is exchanged by two or more IDMEF 154 applications. "IDMEF message" is another term for an "IDMEF 155 document." 157 2. Introduction 159 The Intrusion Detection Message Exchange Format (IDMEF) [2] is 160 intended to be a standard data format that automated intrusion 161 detection systems can use to report alerts about events that they 162 deem suspicious. The development of this standard format will enable 163 interoperability among commercial, open source, and research systems, 164 allowing users to mix-and-match the deployment of these systems 165 according to their strong and weak points to obtain an optimal 166 implementation. 168 The most obvious place to implement the IDMEF is in the data channel 169 between an intrusion detection analyzer (or "sensor") and the manager 170 (or "console") to which it sends alarms. But there are other places 171 where the IDMEF can be useful: 173 o a single database system that could store the results from a 174 variety of intrusion detection products would make it possible for 175 data analysis and reporting activities to be performed on "the 176 whole picture" instead of just a part of it; 178 o an event correlation system that could accept alerts from a 179 variety of intrusion detection products would be capable of 180 performing more sophisticated cross-correlation and cross- 181 confirmation calculations than one that is limited to a single 182 product; 184 o a graphical user interface that could display alerts from a 185 variety of intrusion detection products would enable the user to 186 monitor all of the products from a single screen, and require him 187 or her to learn only one interface, instead of several; and 189 o a common data exchange format would make it easier for different 190 organizations (users, vendors, response teams, law enforcement) to 191 not only exchange data, but also communicate about it. 193 The diversity of uses for the IDMEF needs to be considered when 194 selecting its method of implementation. 196 2.1. About the IDMEF Data Model 198 The IDMEF data model is an object-oriented representation of the 199 alert data sent to intrusion detection managers by intrusion 200 detection analyzers. 202 2.1.1. Problems Addressed by the Data Model 204 The data model addresses several problems associated with 205 representing intrusion detection alert data: 207 o Alert information is inherently heterogeneous. Some alerts are 208 defined with very little information, such as origin, destination, 209 name, and time of the event. Other alerts provide much more 210 information, such as ports or services, processes, user 211 information, and so on. The data model that represents this 212 information must be flexible to accommodate different needs. 214 An object-oriented model is naturally extensible via aggregation 215 and subclassing. If an implementation of the data model extends 216 it with new classes, either by aggregation or subclassing, an 217 implementation that does not understand these extensions will 218 still be able to understand the subset of information that is 219 defined by the data model. Subclassing and aggregation provide 220 extensibility while preserving the consistency of the model. 222 o Inrusion detection environments are different. Some analyzers 223 detect attacks by analyzing network traffic; others use operating 224 system logs or application audit trail information. Alerts for 225 the same attack, sent by analyzers with different information 226 sources, will not contain the same information. 228 The data model defines support classes that accommodate the 229 differences in data sources among analyzers. In particular, the 230 notion of source and target for the alert are represented by the 231 combination of Node, Process, Service, and User classes. 233 o Analyzer capabilities are different. Depending on the 234 environment, one may install a lightweight analyzer that provides 235 little information in its alerts, or a more complex analyzer that 236 will have a greater impact on the running system but provide more 237 detailed alert information. The data model must allow for 238 conversion to formats used by tools other than intrusion detection 239 analyzers, for the purpose of further processing the alert 240 information. 242 The data model defines extensions to the basic DTD that allow 243 carrying both simple and complex alerts. Extensions are 244 accomplished through subclassing or association of new classes. 246 o Operating environments are different. Depending on the kind of 247 network or operating system used, attacks will be observed and 248 reported with different characteristics. The data model should 249 accommodate these differences. 251 Significant flexibility in reporting is provided by the Node and 252 Service support classes. If additional information must be 253 reported, subclasses may be defined that extend the data model 254 with additional attributes. 256 o Commercial vendor objectives are different. For various reasons, 257 vendors may wish to deliver more or less information about certain 258 types of attacks. 260 The object-oriented approach allows this flexibility while the 261 subclassing rules preserve the integrity of the model. 263 2.1.2. Data Model Design Goals 265 The data model was designed to provide a standard representation of 266 alerts in an unambiguous fashion, and to permit the relationship 267 between simple and complex alerts to be described. 269 2.1.2.1. Representing Events 271 The goal of the data model is to provide a standard representation of 272 the information that an intrusion detection analyzer reports when it 273 detects an occurrence of some unusual event(s). These alerts may be 274 simple or complex, depending on the capabilities of the analyzer that 275 creates them. 277 2.1.2.2. Content-Driven 279 The design of the data model is content-driven. This means that new 280 objects are introduced to accommodate additional content, not 281 semantic differences between alerts. This is an important goal, as 282 the task of classifying and naming computer vulnerabilities is both 283 extremely difficult and very subjective. 285 The data model must be unambiguous. This means that while we allow 286 analyzers to be more or less precise than one another (i.e., one 287 analyzer may report more information about an event than another), we 288 do not allow them to produce contradictory information in two alerts 289 describing the same event (i.e., the common subset of information 290 reported by both analyzers must be identical and inserted in the same 291 placeholders within the alert data structure). Of course, it is 292 always possible to insert all "interesting" information about an 293 event in extension fields of the alert instead of in the fields where 294 it belongs; however, such practice reduces interoperability and 295 should be avoided whenever possible. 297 2.1.2.3. Relationship Between Alerts 299 Intrusion detection alerts can be transmitted at several levels. 300 This Internet-Draft applies to the entire range, from very simple 301 alerts (e.g., those alerts that are the result of a single action or 302 operation in the system, such as a failed login report) to very 303 complex ones (e.g., the aggregation of several events causing an 304 alert to be generated). 306 As such, the data model must provide a way for complex alerts that 307 aggregate several simple alerts to identify those simple alerts in 308 the complex alert's content. 310 2.2. About the IDMEF XML Implementation 312 Two implementations of the IDMEF were originally proposed to the 313 IDWG: one using the Structure of Management Information (SMI) to 314 describe an SNMP MIB, and the other using a Document Type Definition 315 (DTD) to describe XML documents. 317 These proposed implementations were reviewed by the IDWG at its 318 September 1999 and February 2000 meetings; it was decided at the 319 February meeting that the XML solution was best at fulfilling the 320 IDWG requirements. 322 2.2.1. The Extensible Markup Language 324 The Extensible Markup Language (XML) [3] is a simplified version of 325 the Standard Generalized Markup Language (SGML), a syntax for 326 specifying text markup defined by the ISO 8879 standard. XML is 327 gaining widespread attention as a language for representing and 328 exchanging documents and data on the Internet, and as the solution to 329 most of the problems inherent in HyperText Markup Language (HTML). 330 XML was published as a recommendation by the World Wide Web 331 Consortium (W3C) on February 10, 1998. 333 XML is a metalanguage -- a language for describing other languages -- 334 that enables an application to define its own markup. XML allows the 335 definition of customized markup languages for different types of 336 documents and different applications. This differs from HTML, in 337 which there is a fixed set of identifiers with preset meanings that 338 must be "adapted" for specialized uses. Both XML and HTML use 339 elements (tags) (identifiers delimited by '<' and >') and attributes 340 (of the form "name='value'"). But where "

" always means 341 "paragraph" in HTML, it may mean "paragraph," "person," "price," or 342 "platypus" in XML, or it might have no meaning at all, depending on 343 the particular application. 345 NOTE: XML provides both a syntax for declaring document markup and 346 structure (i.e., defining elements and attributes, specifying the 347 order in which they appear, and so on) and a syntax for using that 348 markup in documents. Because markup declarations look radically 349 different from markup, many people are confused as to which syntax 350 is called XML. The answer is that they both are, because they are 351 actually both part of the same language. 353 For clarity in this document, we will use the terms "XML" and "XML 354 documents" when speaking in the general case, and the term "IDMEF 355 markup" when speaking specifically of the elements (tags) and 356 attributes that describe IDMEF messages. 358 The publication of XML was followed by the publication of a second 359 recommendation [4] by the World Wide Web Consortium, defining the use 360 of namespaces in XML documents. An XML namespace is a collection of 361 names, identified by a Universal Resource Identifier (URI) [5]. When 362 using namespaces, each tag is identified with the namespace it comes 363 from, allowing tags from different namespaces with the same names to 364 occur in the same document. For example, a single document could 365 contain both "usa:football" and "europe:football" tags, each with 366 different meanings. 368 In anticipation of the widespread use of XML namespaces, this memo 369 includes the definition of the URI to be used to identify the IDMEF 370 namespace. 372 2.2.2. Rationale for Implementing IDMEF in XML 374 XML-based applications are being used or developed for a wide variety 375 of purposes, including electronic data interchange in a variety of 376 fields, financial data interchange, electronic business cards, 377 calendar and scheduling, enterprise software distribution, web "push" 378 technology, and markup languages for chemistry, mathematics, music, 379 molecular dynamics, astronomy, book and periodical publishing, web 380 publishing, weather observations, real estate transactions, and many 381 others. 383 XML's flexibility makes it a good choice for these applications; that 384 same flexibility makes it a good choice for implementing the IDMEF as 385 well. Other, more specific reasons for choosing XML to implement the 386 IDMEF are: 388 o XML allows a custom language to be developed specifically for the 389 purpose of describing intrusion detection alerts. It also defines 390 a standard way to extend this language, either for later revisions 391 of this document ("standard" extensions), or for vendor-specific 392 use ("non-standard" extensions). 394 o Software tools for processing XML documents are widely available, 395 in both commercial and open source forms. Numerous tools and APIs 396 for parsing and/or validating XML are available in a variety of 397 languages, including Java, C, C++, Tcl, Perl, Python, and GNU 398 Emacs Lisp. Widespread access to tools will make adoption of the 399 IDMEF by product developers easier, and hopefully, faster. 401 o XML meets IDMEF Requirement 5.1 [2], that message formats support 402 full internationalization and localization. The XML standard 403 requires support for both the UTF-8 and UTF-16 encodings of ISO/ 404 IEC 10646 (Universal Multiple-Octet Coded Character Set, "UCS") 405 and Unicode, making all XML applications (and therefore all IDMEF- 406 compliant applications) compatible with these common character 407 encodings. 409 XML also provides support for specifying, on a per-element basis, 410 the language in which the element's content is written, making 411 IDMEF easy to adapt to "Natural Language Support" versions of a 412 product. 414 o XML meets IDMEF Requirement 5.2 [2], that message formats must 415 support filtering and aggregation. XML's integration with XSL, a 416 style language, allows messages to be combined, discarded, and 417 rearranged. 419 o Ongoing XML development projects, in the W3C and elsewhere, will 420 provide object-oriented extensions, database support, and other 421 useful features. If implemented in XML, the IDMEF immediately 422 gains these features as well. 424 o XML is free, with no license, no license fees, and no royalties. 426 3. Notational Conventions and Formatting Issues 428 This document uses three notations: Unified Modeling Language to 429 describe the data model, XML to describe the markup used in IDMEF 430 documents, and IDMEF markup to represent the documents themselves. 432 Appendix A describes these notations in sufficient detail that 433 readers unfamiliar with them can understand the document. Note, 434 however, that these descriptions are not comprehensive; they only 435 cover the components of the notations used by the data model and 436 document format. 438 Appendix A also explains several document formatting issues that 439 apply to XML documents, including formats for particular data types, 440 special character and whitespace processing, character sets, and 441 languages. 443 3.1. IDMEF XML Documents 445 This section describes IDMEF XML document formatting rules. Most of 446 these rules are "inherited" from the rules for formatting XML 447 documents; see Appendix A for more detail. 449 3.1.1. The Document Prolog 451 The format of an IDMEF XML document prolog is described in the 452 following sections. 454 3.1.1.1. XML Declaration 456 IDMEF documents being exchanged between IDMEF-compliant applications 457 MUST begin with an XML declaration, and MUST specify the XML version 458 in use. Specification of the encoding in use is RECOMMENDED. 460 An IDMEF message SHOULD therefore start with: 462 464 467 IDMEF-compliant applications MAY choose to omit the XML declaration 468 internally to conserve space, adding it only when the message is sent 469 to another destination (e.g., a web browser). This practice is NOT 470 RECOMMENDED unless it can be accomplished without loss of each 471 message's version and encoding information. 473 In order to be valid (see Section 6.1), an XML document must contain 474 a document type declaration. However, this represents significant 475 overhead to an IDMEF-compliant application, both in the bandwidth it 476 consumes as well as the requirements it places on the XML processor 477 (not only to parse the declaration itself, but also to parse the DTD 478 it references). 480 Implementors MAY decide, therefore, to have analyzers and managers 481 agree out-of-band on the particular document type definition they 482 will be using to exchange messages (the standard one as defined here, 483 or one with extensions), and then omit the document type declaration 484 from IDMEF messages. The method for negotiating this agreement is 485 outside the scope of this document. Note that great care must be 486 taken in negotiating any such agreements, as the manager may have to 487 accept messages from many different analyzers, each using a DTD with 488 a different set of extensions. 490 3.1.2. Character Data Processing in IDMEF 492 For portability reasons, IDMEF-compliant applications SHOULD NOT use, 493 and IDMEF messages SHOULD NOT be encoded in, character encodings 494 other than UTF-8 and UTF-16. Consistent with the XML standard, if no 495 encoding is specified for an IDMEF message, UTF-8 is assumed. 497 NOTE: The ASCII character set is a subset of the UTF-8 encoding, and 498 therefore may be used to encode IDMEF messages. 500 Per the XML standard, IDMEF documents encoded in UTF-16 MUST begin 501 with the Byte Order Mark described by ISO/IEC 10646 Annex E and 502 Unicode Appendix B (the "ZERO WIDTH NO-BREAK SPACE" character, 503 #xFEFF). 505 3.1.2.1. Character Entity References 507 It is RECOMMENDED that IDMEF-compliant applications use the entity 508 reference form (see A.3.2.1) of the characters '&', ,'<', '>', '"', 509 and ''' (single-quote) whenever writing these characters in data, to 510 avoid any possibility of misinterpretation. 512 3.1.2.2. White Space Processing 514 All IDMEF elements MUST support the "xml:space" attribute. 516 3.1.3. Languages in IDMEF 518 IDMEF-compliant applications MUST specify the language in which their 519 contents are encoded; in general this can be done by specifying the 520 "xml:lang" attribute for the top-level element and letting all other 521 elements "inherit" that definition. 523 3.2. IDMEF Data Types 525 Within an XML IDMEF message, all data will be expressed as "text" (as 526 opposed to "binary"), since XML is a text formatting language. We 527 provide typing information for the attributes of the classes in the 528 data model however, to convey to the reader the type of data the 529 model expects for each attribute. 531 Each data type in the model has specific formatting requirements in 532 an XML IDMEF message; these requirements are set forth in this 533 section. 535 3.2.1. Integers 537 Integer attributes are represented by the INTEGER data type. Integer 538 data MUST be encoded in Base 10 or Base 16. 540 Base 10 integer encoding uses the digits '0' through '9' and an 541 optional sign ('+' or '-'). For example, "123", "-456". 543 Base 16 integer encoding uses the digits '0' through '9' and 'a' 544 through 'f' (or their upper case equivalents), and is preceded by the 545 characters "0x". For example, "0x1a2b". 547 3.2.2. Real Numbers 549 Real (floating-point) attributes are represented by the REAL data 550 type. Real data MUST be encoded in Base 10. 552 Real encoding is that of the POSIX 1003.1 "strtod" library function: 553 an optional sign ('+' or '-') followed by a non-empty string of 554 decimal digits, optionally containing a radix character, then an 555 optional exponent part. An exponent part consists of an 'e' or 'E', 556 followed by an optional sign, followed by one or more decimal digits. 557 For example, "123.45e02", "-567,89e-03". 559 IDMEF-compliant applications MUST support both the '.' and ',' radix 560 characters. 562 3.2.3. Characters and Strings 564 Single-character attributes are represented by the CHARACTER data 565 type. Multi-character attributes of known length are represented by 566 the STRING data type. 568 Character and string data have no special formatting requirements, 569 other than the need to occasionally use character references (see 570 Section 3.2.3.1 and Section 3.2.3.2) to represent special characters. 572 3.2.3.1. Character Entity References 574 Within XML documents, certain characters have special meanings in 575 some contexts. To include the actual character itself in one of 576 these contexts, a special escape sequence, called an entity 577 reference, must be used. 579 The characters that sometimes need to be escaped, and their entity 580 references, are: 582 +-----------+------------------+ 583 | Character | Entity Reference | 584 +-----------+------------------+ 585 | & | & | 586 | | | 587 | < | < | 588 | | | 589 | > | > | 590 | | | 591 | " | " | 592 | | | 593 | ' | ' | 594 +-----------+------------------+ 596 3.2.3.2. Character Code References 598 Any character defined by the ISO/IEC 10646 and Unicode standards may 599 be included in an XML document by the use of a character reference. 600 A character reference is started with the characters '&' and '#', and 601 ended with the character ';'. Between these characters, the 602 character code for the character inserted. 604 If the character code is preceded by an 'x' it is interpreted in 605 hexadecimal (base 16), otherwise, it is interpreted in decimal (base 606 10). For instance, the ampersand (&) is encoded as & or & 607 and the less-than sign (<) is encoded as < or <. 609 Any one-, two-, or four-byte character specified in the ISO/IEC 10646 610 and Unicode standards can be included in a document using this 611 technique. 613 3.2.4. Bytes 615 Binary data is represented by the BYTE (and BYTE[]) data type. 617 Binary data MUST be encoded in its entirety using base64. 619 3.2.5. Enumerated Types 621 Enumerated types are represented by the ENUM data type, and consist 622 of an ordered list of acceptable values. 624 3.2.6. Date-Time Strings 626 Date-time strings are represented by the DATETIME data type. Each 627 date-time string identifies a particular instant in time; ranges are 628 not supported. 630 Date-time strings are formatted according to a subset of ISO 8601: 631 2000 [6], as show below. Section references in parentheses refer to 632 sections of the ISO 8601:2000 standard. 634 1. Dates MUST be formatted as follows: 636 YYYY-MM-DD 638 where YYYY is the four- digit year, MM is the two-digit month 639 (01-12), and DD is the two- digit day (01-31). (Section 5.2.1.1, 640 "Complete representation -- Extended format.") 642 2. Times MUST be formatted as follows: 644 hh:mm:ss 646 where hh is the two-digit hour (00-24), mm is the two-digit 647 minute (00-59), and ss is the two-digit second (00-60). (Section 648 5.3.1.1, "Complete representation -- Extended format.") 650 Note that midnight has two representations, 00:00:00 and 651 24:00:00. Both representations MUST be supported by IDMEF- 652 compliant applications, however, the 00:00:00 representation 653 SHOULD be used whenever possible. 655 Note also that this format accounts for leap seconds. Positive 656 leap seconds are inserted between 23:59:59Z and 24:00:00Z and are 657 represented as 23:59:60Z. Negative leap seconds are achieved by 658 the omission of 23:59:59Z. IDMEF-compliant applications MUST 659 support leap seconds. 661 3. Times MAY be formatted to include a decimal fraction of seconds, 662 as follows: 664 hh:mm:ss.ss or 665 hh:mm:ss,ss 667 As many digits as necessary may follow the decimal sign (at least 668 one digit must follow the decimal sign). Decimal fractions of 669 hours and minutes are not supported. (Section 5.3.1.3, 670 "Representation of decimal fractions.") 672 IDMEF-compliant applications MUST support the use of both decimal 673 signs ('.' and ','). 675 Note that the number of digits in the fraction part does not 676 imply anything about accuracy -- i.e., "00.100000", "00,1000" and 677 "00.1" are all equivalent. 679 4. Times MUST be formatted to include (a) an indication that the 680 time is in Coordinated Universal Time (UTC), or (b) an indication 681 of the difference between the specified time and Coordinated 682 Universal Time. 684 * Times in UTC MUST be formatted by appending the letter 'Z' to 685 the time string as follows: 687 hh:mm:ssZ 688 hh:mm:ss.ssZ 689 hh:mm:ss,ssZ 691 (Section 5.3.3, "Coordinated Universal Time (UTC) -- Extended 692 format.") 694 * If the time is ahead of or equal to UTC, a '+' sign is 695 appended to the time string; if the time is behind UTC, a '-' 696 sign is appended. Following the sign, the number of hours and 697 minutes representing the different from UTC is appended, as 698 follows: 700 hh:mm:ss+hh:mm 701 hh:mm:ss-hh:mm 702 hh:mm:ss.ss+hh:mm 703 hh:mm:ss.ss-hh:mm 704 hh:mm:ss,ss+hh:mm 705 hh:mm:ss,ss-hh:mm 707 The difference from UTC MUST be specified in both hours and 708 minutes, even if the minutes component is 0. A "difference" 709 of "+00:00" is equivalent to UTC. (Section 5.3.4.2, "Local 710 time and the difference with Coordinated Universal Time -- 711 Extended Format.") 713 5. Date-time strings are created by joining the date and time 714 strings with the letter 'T', as shown below: 716 YYYY-MM-DDThh:mm:ssZ 717 YYYY-MM-DDThh:mm:ss.ssZ 718 YYYY-MM-DDThh:mm:ss,ssZ 719 YYYY-MM-DDThh:mm:ss+hh:mm 720 YYYY-MM-DDThh:mm:ss-hh:mm 721 YYYY-MM-DDThh:mm:ss.ss+hh:mm 722 YYYY-MM-DDThh:mm:ss.ss-hh:mm 723 YYYY-MM-DDThh:mm:ss,ss+hh:mm 724 YYYY-MM-DDThh:mm:ss,ss-hh:mm 726 (Section 5.4.1, "Complete representation -- Extended format.") 728 In summary, IDMEF date-time strings MUST adhere to one of the nine 729 templates identified in Paragraph 5, above. 731 3.2.7. NTP Timestamps 733 NTP timestamps are represented by the NTPSTAMP data type, and are 734 described in detail in [7] and [8]. An NTP timestamp is a 64-bit 735 unsigned fixed-point number. The integer part is in the first 32 736 bits, and the fraction part is in the last 32 bits. 738 Within IDMEF messages, NTP timestamps MUST be encoded as two 32-bit 739 hexadecimal values, separated by a period ('.'). For example, 740 "0x12345678.0x87654321". 742 See also Section 6.4 for more information on NTP timestamps. 744 3.2.8. Port Lists 746 Port lists are represented by the PORTLIST data type, and consist of 747 a comma-separated list of numbers (individual integers) and ranges 748 (N-M means ports N through M, inclusive). Any combination of numbers 749 and ranges may be used in a single list. For example, 750 "5-25,37,42,43,53,69-119,123-514". 752 3.2.9. Unique Identifiers 754 There are two types of unique identifiers used in this specification. 755 Both types are represented by STRING data types. 757 These identifiers are implemented as attributes on the relevant XML 758 elements, and must have unique values as follows: 760 1. The Analyzer class' (Section 4.2.4.1) "analyzerid" attribute, if 761 specified, MUST have a value that is unique across all analyzers 762 in the intrusion detection environment. 764 The "analyzerid" attribute is not required to be globally unique, 765 only unique within the intrusion detection environment of which 766 the analyzer is a member. It is permissible for two analyzers, 767 in different intrusion detection environments, to have the same 768 value for "analyzerid". 770 The default value is "0", which indicates that the analyzer 771 cannot generate unique identifiers. 773 2. The Alert and Heartbeat messages (Section 4.2.2, Section 4.2.3) 774 must be uniquely identified by the couple (analyzerid,messageid), 775 if the analyzer supports the generation of message identifiers. 777 3. The Classification, Source, Target, Node, User, Process, Service, 778 File, Address, and UserId classes' (Section 4.2.4.2 779 Section 4.2.4.3, Section 4.2.4.4, Section 4.2.7.2, 780 Section 4.2.7.3, Section 4.2.7.4, Section 4.2.7.5, 781 Section 4.2.7.6, Section 4.2.7.2.1, and Section 4.2.7.3.1) 782 "ident" attribute, if specified, MUST have a value that is unique 783 across all messages sent by the individual analyzer. 785 The "ident" attribute value MUST be unique for each particular 786 combination of data identifying an object, not for each object. 787 Objects may have more than one "ident" value associated with 788 them. For example, an identification of a host by name would 789 have one value, while an identification of that host by address 790 would have another value, and an identification of that host by 791 both name and address would have still another value. 792 Furthermore, different analyzers may produce different values for 793 the same information. 795 The "ident" attribute by itself provides a unique identifier only 796 among all the "ident" values sent by a particular analyzer. But 797 when combined with the "analyzerid" value for the analyzer, a 798 value that is unique across the intrusion detection environment 799 is created. Again, there is no requirement for global 800 uniqueness. 802 The default value is "0", which indicates that the analyzer 803 cannot generate unique identifiers. 805 The specification of methods for creating the unique values contained 806 in these attributes is outside the scope of this document. 808 4. The IDMEF Data Model and DTD 810 In this section, the individual components of the IDMEF data model 811 are explained in detail. UML diagrams of the model are provided to 812 show how the components are related to each other, and relevant 813 sections of the IDMEF DTD are presented to show how the model is 814 translated into XML. 816 4.1. Data Model Overview 818 The relationship between the principal components of the data model 819 is shown in Figure 2 (occurrence indicators and attributes are 820 omitted). 822 The top-level class for all IDMEF messages is IDMEF-Message; each 823 type of message is a subclass of this top-level class. There are 824 presently two types of messages defined; Alerts and Heartbeats. 825 Within each message, subclasses of the message class are used to 826 provide the detailed information carried in the message. 828 It is important to note that the data model does not specify how an 829 alert should be classified or identified. For example, a port scan 830 may be identified by one analyzer as a single attack against multiple 831 targets, while another analyzer might identify it as multiple attacks 832 from a single source. However, once an analyzer has determined the 833 type of alert it plans to send, the data model dictates how that 834 alert should be formatted. 836 +---------------+ 837 | IDMEF-Message | 838 +---------------+ 839 /_\ 840 | 841 +--------------------+-------------+ 842 | | 843 +-------+ +--------------+ +-----------+ +----------------+ 844 | Alert |<>-| Analyzer | | Heartbeat |<>-| Analyzer | 845 +-------+ +--------------+ +-----------+ +----------------+ 846 | | +--------------+ | | +----------------+ 847 | |<>-| CreateTime | | |<>-| CreateTime | 848 | | +--------------+ | | +----------------+ 849 | | +--------------+ | | +----------------+ 850 | |<>-| DetectTime | | |<>-| AdditionalData | 851 | | +--------------+ +-----------+ +----------------+ 852 | | +--------------+ 853 | |<>-| AnalyzerTime | 854 | | +--------------+ 855 | | +--------+ +----------+ 856 | |<>-| Source |<>-| Node | 857 | | +--------+ +----------+ 858 | | | | +----------+ 859 | | | |<>-| User | 860 | | | | +----------+ 861 | | | | +----------+ 862 | | | |<>-| Process | 863 | | | | +----------+ 864 | | | | +----------+ 865 | | | |<>-| Service | 866 | | +--------+ +----------+ 867 | | +--------+ +----------+ 868 | |<>-| Target |<>-| Node | 869 | | +--------+ +----------+ 870 | | | | +----------+ 871 | | | |<>-| User | 872 | | | | +----------+ 873 | | | | +----------+ 874 | | | |<>-| Process | 875 | | | | +----------+ 876 | | | | +----------+ 877 | | | |<>-| Service | +----------------+ 878 | | | | +----------+ +----| Classification | 879 | | | | +----------+ | +----------------+ 880 | | | |<>-| File | | +----------------+ 881 | | +--------+ +----------+ | +--| Assessment | 882 | |<>----------------------------+ | +----------------+ 883 | |<>------------------------------+ +----------------+ 884 | |<>---------------------------------| AdditionalData | 885 +-------+ +----------------+ 887 Figure 2: Data model overview 889 4.2. The Message Classes 891 The individual classes are described in the following sections. 893 4.2.1. The IDMEF-Message Class 895 All IDMEF messages are instances of the IDMEF-Message class; it is 896 the top-level class of the IDMEF data model, as well as the IDMEF 897 DTD. There are currently two types (subclasses) of IDMEF-Message: 898 Alert and Heartbeat. 900 The IDMEF-Message class has a single attribute: 902 version 904 The version of the IDMEF-Message specification (this document) 905 this message conforms to. Applications specifying a value for 906 this attribute MUST specify the value "1.0". 908 4.2.2. The Alert Class 910 Generally, every time an analyzer detects an event that it has been 911 configured to look for, it sends an Alert message to its manager(s). 912 Depending on the analyzer, an Alert message may correspond to a 913 single detected event, or multiple detected events. Alerts occur 914 asynchronously in response to outside events. 916 An Alert message is composed of several aggregate classes, as shown 917 in Figure 3. The aggregate classes themselves are described in 918 Section 4.2.4, Section 4.2.5, and Section 4.2.6. 920 +-------------------+ 921 | Alert | 922 +-------------------+ +------------------+ 923 | STRING messageid |<>----------| Analyzer | 924 | | +------------------+ 925 | | +------------------+ 926 | |<>----------| CreateTime | 927 | | +------------------+ 928 | | +------------------+ 929 | |<>----------| Classification | 930 | | +------------------+ 931 | | 0..1 +------------------+ 932 | |<>----------| DetectTime | 933 | | +------------------+ 934 | | 0..1 +------------------+ 935 | |<>----------| AnalyzerTime | 936 | | +------------------+ 937 | | 0..* +------------------+ 938 | |<>----------| Source | 939 | | +------------------+ 940 | | 0..* +------------------+ 941 | |<>----------| Target | 942 | | +------------------+ 943 | | 0..1 +------------------+ 944 | |<>----------| Assessment | 945 | | +------------------+ 946 | | 0..* +------------------+ 947 | |<>----------| AdditionalData | 948 | | +------------------+ 949 +-------------------+ 950 /_\ 951 | 952 +----+------------+-------------+ 953 | | | 954 +-------------------+ | +-------------------+ 955 | ToolAlert | | | CorrelationAlert | 956 +-------------------+ | +-------------------+ 957 | 958 +-------------------+ 959 | OverflowAlert | 960 +-------------------+ 962 Figure 3: The Alert Class 964 The aggregate classes that make up Alert are: 966 Analyzer 968 Exactly one. Identification information for the analyzer that 969 originated the alert. 971 CreateTime 973 Exactly one. The time the alert was created. Of the three times 974 that may be provided with an Alert, this is the only one that is 975 required. 977 Classification 979 Exactly one. The "name" of the alert, or other information 980 allowing the manager to determine what it is. 982 DetectTime 984 Zero or one. The time the event(s) leading up to the alert was 985 detected. In the case of more than one event, the time the first 986 event was detected. In some circumstances, this may not be the 987 same value as CreateTime. 989 AnalyzerTime 991 Zero or one. The current time on the analyzer (see Section 6.3). 993 Source 995 Zero or more. The source(s) of the event(s) leading up to the 996 alert. 998 Target 1000 Zero or more. The target(s) of the event(s) leading up to the 1001 alert. 1003 Assessment 1005 Zero or one. Information about the impact of the event, actions 1006 taken by the analyzer in response to it, and the analyzer's 1007 confidence in its evaluation. 1009 AdditionalData 1010 Zero or more. Information included by the analyzer that does not 1011 fit into the data model. This may be an atomic piece of data, or 1012 a large amount of data provided through an extension to the IDMEF 1013 (see Section 5). 1015 Alert is represented in the IDMEF DTD as follows: 1017 1022 1027 The Alert class has one attribute: 1029 messageid 1031 Optional. A unique identifier for the alert, see Section 3.2.9. 1033 4.2.2.1. The ToolAlert Class 1035 The ToolAlert class carries additional information related to the use 1036 of attack tools or malevolent programs such as Trojan horses, and can 1037 be used by the analyzer when it is able to identify these tools. It 1038 is intended to group one or more previously-sent alerts together, to 1039 say "these alerts were all the result of someone using this tool." 1041 The ToolAlert class is composed of three aggregate classes, as shown 1042 in Figure 5. 1044 +------------------+ 1045 | Alert | 1046 +------------------+ 1047 /_\ 1048 | 1049 +------------------+ 1050 | ToolAlert | 1051 +------------------+ +-------------------+ 1052 | |<>----------| name | 1053 | | +-------------------+ 1054 | | 0..1 +-------------------+ 1055 | |<>----------| command | 1056 | | +-------------------+ 1057 | | 1..* +-------------------+ 1058 | |<>----------| alertident | 1059 | | +-------------------+ 1060 | | | STRING analyzerid | 1061 | | +-------------------+ 1062 +------------------+ 1064 Figure 5: The ToolAlert Class 1066 The aggregate classes that make up ToolAlert are: 1068 name 1070 Exactly one. STRING. The reason for grouping the alerts 1071 together, for example, the name of a particular tool. 1073 command 1075 Zero or one. STRING. The command or operation that the tool was 1076 asked to perform, for example, a BackOrifice ping. 1078 alertident 1080 One or more. STRING. The list of alert identifiers that are 1081 related to this alert. Because alert identifiers are only unique 1082 across the alerts sent by a single analyzer, the optional 1083 "analyzerid" attribute of "alertident" should be used to identify 1084 the analyzer that a particular alert came from. If the 1085 "analyzerid" is not provided, the alert is assumed to have come 1086 from the same analyzer that is sending the ToolAlert. 1088 This is represented in the IDMEF DTD as follows: 1090 1093 1097 4.2.2.2. The CorrelationAlert Class 1099 The CorrelationAlert class carries additional information related to 1100 the correlation of alert information. It is intended to group one or 1101 more previously-sent alerts together, to say "these alerts are all 1102 related." 1104 The CorrelationAlert class is composed of two aggregate classes, as 1105 shown in Figure 7. 1107 +------------------+ 1108 | Alert | 1109 +------------------+ 1110 /_\ 1111 | 1112 +------------------+ 1113 | CorrelationAlert | 1114 +------------------+ +-------------------+ 1115 | |<>----------| name | 1116 | | +-------------------+ 1117 | | 1..* +-------------------+ 1118 | |<>----------| alertident | 1119 | | +-------------------+ 1120 | | | STRING analyzerid | 1121 | | +-------------------+ 1122 +------------------+ 1124 Figure 7: The CorrelationAlert Class 1126 The aggregate classes that make up CorrelationAlert are: 1128 name 1130 Exactly one. STRING. The reason for grouping the alerts 1131 together, for example, a particular correlation method. 1133 alertident 1135 One or more. STRING. The list of alert identifiers that are 1136 related to this alert. Because alert identifiers are only unique 1137 across the alerts sent by a single analyzer, the optional 1138 "analyzerid" attribute of "alertident" should be used to identify 1139 the analyzer that a particular alert came from. If the 1140 "analyzerid" is not provided, the alert is assumed to have come 1141 from the same analyzer that is sending the CorrelationAlert. 1143 This is represented in the IDMEF DTD as follows. 1145 1148 1152 4.2.2.3. The OverflowAlert Class 1154 The OverflowAlert carries additional information related to buffer 1155 overflow attacks. It is intended to enable an analyzer to provide 1156 the details of the overflow attack itself. 1158 The OverflowAlert class is composed of three aggregate classes, as 1159 shown in Figure 9. 1161 +------------------+ 1162 | Alert | 1163 +------------------+ 1164 /_\ 1165 | 1166 +------------------+ 1167 | OverflowAlert | 1168 +------------------+ +---------+ 1169 | |<>----------| program | 1170 | | +---------+ 1171 | | 0..1 +---------+ 1172 | |<>----------| size | 1173 | | +---------+ 1174 | | 0..1 +---------+ 1175 | |<>----------| buffer | 1176 | | +---------+ 1177 +------------------+ 1179 Figure 9: The OverflowAlert Class 1180 The aggregate classes that make up OverflowAlert are: 1182 program 1184 Exactly one. STRING. The program that the overflow attack 1185 attempted to run (note: this is not the program that was 1186 attacked). 1188 size 1190 Zero or one. INTEGER. The size, in bytes, of the overflow (i.e., 1191 the number of bytes the attacker sent). 1193 buffer 1195 Zero or one. BYTE[]. Some or all of the overflow data itself 1196 (dependent on how much the analyzer can capture). 1198 This is represented in the IDMEF DTD as follows: 1200 1203 1207 4.2.3. The Heartbeat Class 1209 Analyzers use Heartbeat messages to indicate their current status to 1210 managers. Heartbeats are intended to be sent in a regular period, 1211 say every ten minutes or every hour. The receipt of a Heartbeat 1212 message from an analyzer indicates to the manager that the analyzer 1213 is up and running; lack of a Heartbeat message (or more likely, lack 1214 of some number of consecutive Heartbeat messages) indicates that the 1215 analyzer or its network connection has failed. 1217 All managers MUST support the receipt of Heartbeat messages; however, 1218 the use of these messages by analyzers is OPTIONAL. Developers of 1219 manager software SHOULD permit the software to be configured on a 1220 per-analyzer basis to use/not use Heartbeat messages. 1222 A Heartbeat message is composed of several aggregate classes, as 1223 shown in Figure 11. The aggregate classes themselves are described 1224 in Section 4.2.4 and Section 4.2.5. 1226 +------------------+ 1227 | Heartbeat | 1228 +------------------+ +------------------+ 1229 | STRING messageid |<>----------| Analyzer | 1230 | | +------------------+ 1231 | | +------------------+ 1232 | |<>----------| CreateTime | 1233 | | +------------------+ 1234 | | 0..1 +------------------+ 1235 | |<>----------| HeartbeatInterval| 1236 | | +------------------+ 1237 | | 0..1 +------------------+ 1238 | |<>----------| AnalyzerTime | 1239 | | +------------------+ 1240 | | 0..* +------------------+ 1241 | |<>----------| AdditionalData | 1242 | | +------------------+ 1243 +------------------+ 1245 Figure 11: The Heartbeat Class 1247 The aggregate classes that make up Heartbeat are: 1249 Analyzer 1251 Exactly one. Identification information for the analyzer that 1252 originated the heartbeat. 1254 CreateTime 1256 Exactly one. The time the heartbeat was created. 1258 AnalyzerTime 1260 Zero or one. The current time on the analyzer (see Section 6.3). 1262 HeartbeatInterval 1264 Zero or one. The interval in seconds at which heartbeats are 1265 generated. 1267 AdditionalData 1269 Zero or more. Information included by the analyzer that does not 1270 fit into the data model. This may be an atomic piece of data, or 1271 a large amount of data provided through an extension to the IDMEF 1272 (see Section 5). 1274 This is represented in the IDMEF DTD as follows: 1276 1280 1285 The Heartbeat class has one attribute: 1287 messageid 1289 Optional. A unique identifier for the heartbeat, see 1290 Section 3.2.9. 1292 4.2.4. The Core Classes 1294 The core classes -- Analyzer, Source, Target, Classification, and 1295 AdditionalData -- are the main parts of Alerts and Heartbeats, as 1296 shown in Figure 13. 1298 +-----------+ +----------------+ 1299 | Heartbeat | +-------| Analyzer | 1300 +-----------+ | +----------------+ 1301 | |<>---+--+ 1302 +-----------+ | | 0..* +----------------+ 1303 | +-------| AdditionalData | 1304 | +----------------+ 1305 +-----------+ | 1306 | Alert | | 0..* +----------------+ 1307 +-----------+ | +-------| Source | 1308 | |<>---+ | +----------------+ 1309 | | | 0..* +----------------+ 1310 | | +-------| Target | 1311 | | | +----------------+ 1312 | |<>------+ 1313 +-----------+ | +----------------+ 1314 +-------| Classification | 1315 +----------------+ 1317 Figure 13: The Core Classes 1319 4.2.4.1. The Analyzer Class 1321 The Analyzer class identifies the analyzer from which the alert or 1322 heartbeat message originates. Only one analyzer may be encoded for 1323 each alert or heartbeat, and that MUST be the analyzer at which the 1324 alert or heartbeat originated. Although the IDMEF data model does 1325 not prevent the use of hierarchical intrusion detection systems 1326 (where alerts get relayed up the tree), it does not provide any way 1327 to record the identity of the "relay" analyzers along the path from 1328 the originating analyzer to the manager that ultimately receives the 1329 alert. 1331 The Analyzer class is composed of three aggregate classes, as shown 1332 in Figure 14. 1334 +---------------------+ 1335 | Analyzer | 1336 +---------------------+ 0..1 +----------+ 1337 | STRING analyzerid |<>----------| Node | 1338 | STRING name | +----------+ 1339 | STRING manufacturer | 1340 | STRING model | 0..1 +----------+ 1341 | STRING version |<>----------| Process | 1342 | STRING class | +----------+ 1343 | STRING ostype | 0..1 +----------+ 1344 | STRING osversion |<>----------| Analyzer | 1345 +---------------------+ +----------+ 1347 Figure 14: The Analyzer Class 1349 The aggregate classes that make up Analyzer are: 1351 Node 1353 Zero or one. Information about the host or device on which the 1354 analyzer resides (network address, network name, etc.). 1356 Process 1358 Zero or one. Information about the process in which the analyzer 1359 is executing. 1361 Analyzer 1363 Zero or one. Information about the analyzer from which the 1364 message may have gone through. The idea behind this mechanism is 1365 that when a manager receives an alert and want to forward it to 1366 another manalyzer, it needs to substitute the original analyzer 1367 information with its own. To preserve the original analyzer 1368 information, it may be included in the new analyzer definition. 1369 This will allow analyzer path tracking. 1371 This is represented in the IDMEF DTD as follows: 1373 1376 1388 The Analyzer class has eight attributes: 1390 analyzerid 1392 Optional (but see below). A unique identifier for the analyzer, 1393 see Section 3.2.9. 1395 This attribute is only "partially" optional. If the analyzer 1396 makes use of the "ident" attributes on other classes to provide 1397 unique identifiers for those objects, then it MUST also provide a 1398 valid "analyzerid" attribute. This requirement is dictated by the 1399 uniqueness requirements of the "ident" attribute (they are unique 1400 only within the context of a particular "analyzerid"). If the 1401 analyzer does not make use of the "ident" attributes however, it 1402 may also omit the "analyzerid" attribute. 1404 name 1406 Optional. An explicit name for the analyzer, that may be easier 1407 to understand that the analyzerid. 1409 manufacturer 1411 Optional. The manufacturer of the analyzer software and/or 1412 hardware. 1414 model 1416 Optional. The model name/number of the analyzer software and/or 1417 hardware. 1419 version 1421 Optional. The version number of the analyzer software and/or 1422 hardware. 1424 class 1426 Optional. The class of analyzer software and/or hardware. 1428 ostype 1430 Optional. Operating system name. On POSIX 1003.1 compliant 1431 systems, this is the value returned in utsname.sysname by the 1432 uname() system call, or the output of the "uname -s" command. 1434 osversion 1436 Optional. Operating system version. On POSIX 1003.1 compliant 1437 systems, this is the value returned in utsname.release by the 1438 uname() system call, or the output of the "uname -r" command. 1440 The "manufacturer", "model", "version", and "class" attributes' 1441 contents are vendor-specific, but may be used together to identify 1442 different types of analyzers (and perhaps make determinations about 1443 the contents to expect in other vendor-specific fields of IDMEF 1444 messages). 1446 4.2.4.2. The Classification Class 1448 The Classification class provides the "name" of an alert, or other 1449 information allowing the manager to determine what it is. This name 1450 is chosen by the alert provider. 1452 The Classification class is composed of one aggregate class, as shown 1453 in Figure 16. 1455 +----------------+ 1456 | Classification | 1457 +----------------+ 0..* +-----------+ 1458 | STRING ident |<>----------| Reference | 1459 | STRING text | +-----------+ 1460 +----------------+ 1462 Figure 16: The Classification Class 1464 The aggregate class that make up Classification is: 1466 Reference 1468 Zero or more. Information about the message, pointing to external 1469 documentation sites, that will provide background information 1470 about the alert. 1472 This is represented in the IDMEF DTD as follows: 1474 1477 1482 The Classification class has two attributes: 1484 ident 1486 Optional. A unique identifier for this classification, see 1487 Section 3.2.9. 1489 text 1491 Required. A vendor-provided string identifying the alert message. 1493 4.2.4.3. The Source Class 1495 The Source class contains information about the possible source(s) of 1496 the event(s) that generated an alert. An event may have more than 1497 one source (e.g., in a distributed denial of service attack). 1499 The Source class is composed of four aggregate classes, as shown in 1500 Figure 18. 1502 +------------------+ 1503 | Source | 1504 +------------------+ 0..1 +---------+ 1505 | STRING ident |<>----------| Node | 1506 | ENUM spoofed | +---------+ 1507 | STRING interface | 0..1 +---------+ 1508 | |<>----------| User | 1509 | | +---------+ 1510 | | 0..1 +---------+ 1511 | |<>----------| Process | 1512 | | +---------+ 1513 | | 0..1 +---------+ 1514 | |<>----------| Service | 1515 | | +---------+ 1516 +------------------+ 1518 Figure 18: The Source Class 1520 The aggregate classes that make up Source are: 1522 Node 1524 Zero or one. Information about the host or device that appears to 1525 be causing the events (network address, network name, etc.). 1527 User 1529 Zero or one. Information about the user that appears to be 1530 causing the event(s). 1532 Process 1534 Zero or one. Information about the process that appears to be 1535 causing the event(s). 1537 Service 1539 Zero or one. Information about the network service involved in 1540 the event(s). 1542 This is represented in the IDMEF DTD as follows: 1544 1547 1554 The Source class has three attributes: 1556 ident 1558 Optional. A unique identifier for this source, see Section 3.2.9. 1560 spoofed 1562 Optional. An indication of whether the source is, as far as the 1563 analyzer can determine, a spoofed address used for hiding the real 1564 origin of the attack. The permitted values for this attribute are 1565 shown below. The default value is "unknown". (See also 1566 Section 10.) 1568 +------+---------+----------------------------------------+ 1569 | Rank | Keyword | Description | 1570 +------+---------+----------------------------------------+ 1571 | 0 | unknown | Accuracy of source information unknown | 1572 | | | | 1573 | 1 | yes | Source is believed to be a decoy | 1574 | | | | 1575 | 2 | no | Source is believed to be "real" | 1576 +------+---------+----------------------------------------+ 1578 interface 1580 Optional. May be used by a network-based analyzer with multiple 1581 interfaces to indicate which interface this source was seen on. 1583 4.2.4.4. The Target Class 1585 The Target class contains information about the possible target(s) of 1586 the event(s) that generated an alert. An event may have more than 1587 one target (e.g., in the case of a port sweep). 1589 The Target class is composed of four aggregate classes, as shown in 1590 Figure 20. 1592 +------------------+ 1593 | Target | 1594 +------------------+ 0..1 +----------+ 1595 | STRING ident |<>----------| Node | 1596 | ENUM decoy | +----------+ 1597 | STRING interface | 0..1 +----------+ 1598 | |<>----------| User | 1599 | | +----------+ 1600 | | 0..1 +----------+ 1601 | |<>----------| Process | 1602 | | +----------+ 1603 | | 0..1 +----------+ 1604 | |<>----------| Service | 1605 | | +----------+ 1606 | | 0..n +----------+ 1607 | |<>----------| File | 1608 | | +----------+ 1609 +------------------+ 1611 Figure 20: The Target Class 1613 The aggregate classes that make up Target are: 1615 Node 1617 Zero or one. Information about the host or device at which the 1618 event(s) (network address, network name, etc.) is being directed. 1620 User 1622 Zero or one. Information about the user at which the event(s) is 1623 being directed. 1625 Process 1627 Zero or one. Information about the process at which the event(s) 1628 is being directed. 1630 Service 1632 Zero or one. Information about the network service involved in 1633 the event(s). 1635 File 1637 Optional. Information about file(s) involved in the event(s). 1639 This is represented in the IDMEF DTD as follows: 1641 1644 1651 The Target class has three attributes: 1653 ident 1655 Optional. A unique identifier for this target, see Section 3.2.9. 1657 decoy 1659 Optional. An indication of whether the target is, as far as the 1660 analyzer can determine, a decoy. The permitted values for this 1661 attribute are shown below. The default value is "unknown". (See 1662 also Section 10.) 1664 +------+---------+----------------------------------------+ 1665 | Rank | Keyword | Description | 1666 +------+---------+----------------------------------------+ 1667 | 0 | unknown | Accuracy of target information unknown | 1668 | | | | 1669 | 1 | yes | Target is believed to be a decoy | 1670 | | | | 1671 | 2 | no | Target is believed to be "real" | 1672 +------+---------+----------------------------------------+ 1674 interface 1676 Optional. May be used by a network-based analyzer with multiple 1677 interfaces to indicate which interface this target was seen on. 1679 4.2.4.5. The Assessment Class 1681 The Assessment class is used to provide the analyzer's assessment of 1682 an event -- its impact, actions taken in response, and confidence. 1684 The Assessment class is composed of three aggregate classes, as shown 1685 in Figure 22. 1687 +------------------+ 1688 | Assessment | 1689 +------------------+ 0..1 +------------+ 1690 | |<>----------| Impact | 1691 | | +------------+ 1692 | | 0..* +------------+ 1693 | |<>----------| Action | 1694 | | +------------+ 1695 | | 0..1 +------------+ 1696 | |<>----------| Confidence | 1697 | | +------------+ 1698 +------------------+ 1700 Figure 22: The Assessment Class 1702 The aggregate classes that make up Assessment are: 1704 Impact 1706 Zero or one. The analyzer's assessment of the impact of the event 1707 on the target(s). 1709 Action 1711 Zero or more. The action(s) taken by the analyzer in response to 1712 the event. 1714 Confidence 1716 A measurement of the confidence the analyzer has in its evaluation 1717 of the event. 1719 This is represented in the IDMEF DTD as follows: 1721 1724 1728 4.2.4.6. The AdditionalData Class 1730 The AdditionalData class is used to provide information that cannot 1731 be represented by the data model. AdditionalData can be used to 1732 provide atomic data (integers, strings, etc.) in cases where only 1733 small amounts of additional information need to be sent; it can also 1734 be used to extend the data model and the DTD to support the 1735 transmission of complex data (such as packet headers). Detailed 1736 instructions for extending the data model and the DTD are provided in 1737 Section 5. 1739 +------+-------------+----------------------------------------------+ 1740 | Rank | Keyword | Description | 1741 +------+-------------+----------------------------------------------+ 1742 | 0 | boolean | The element contains a boolean value, i.e., | 1743 | | | the strings "true" or "false" | 1744 | | | | 1745 | 1 | byte | The element content is a single 8-bit byte | 1746 | | | (see Section 3.2.4) | 1747 | | | | 1748 | 2 | character | The element content is a single character | 1749 | | | (see Section 3.2.3) | 1750 | | | | 1751 | 3 | date-time | The element content is a date-time string | 1752 | | | (see Section 3.2.6) | 1753 | | | | 1754 | 4 | integer | The element content is an integer (see | 1755 | | | Section 3.2.1) | 1756 | | | | 1757 | 5 | ntpstamp | The element content is an NTP timestamp (see | 1758 | | | Section 3.2.7) | 1759 | | | | 1760 | 6 | portlist | The element content is a list of ports (see | 1761 | | | Section 3.2.8) | 1762 | | | | 1763 | 7 | real | The element content is a real number (see | 1764 | | | Section 3.2.2) | 1765 | | | | 1766 | 8 | string | The element content is a string (see | 1767 | | | Section 3.2.3) | 1768 | | | | 1769 | 9 | byte-string | The element is a byte[] (see Section 3.2.4) | 1770 | | | | 1771 | 10 | xmltext | The element content is XML-tagged data (see | 1772 | | | Section 5.2) | 1773 +------+-------------+----------------------------------------------+ 1774 The AdditionalData element is declared in the IDMEF DTD as follows: 1776 1781 1787 1793 The AdditionalData class has one attribute: 1795 meaning 1797 Optional. A string describing the meaning of the element content. 1798 These values will be vendor/implementation dependent; the method 1799 for ensuring that managers understand the strings sent by analyzer 1800 is outside the scope of this specification. A list of acceptable 1801 meaning keywords is not within the scope of the document, although 1802 later versions may undertake to establish such a list. 1804 4.2.5. The Time Classes 1806 The data model provides three classes for representing time. These 1807 classes are elements of the Alert and Heartbeat classes. 1809 The time classes are represented in the IDMEF DTD as follows: 1811 1812 1814 1815 1820 1821 1827 1828 1833 The DATETIME format of the element content is described 1834 in Section 3.2.6. 1836 If the date and time represented by the element content and the NTP 1837 timestamp differ (should "never" happen), the value in the NTP 1838 timestamp MUST be used. 1840 4.2.5.1. The CreateTime Class 1842 The CreateTime class is used to indicate the date and time the alert 1843 or heartbeat was created by the analyzer. 1845 4.2.5.2. The DetectTime Class 1847 The DetectTime class is used to indicate the date and time the 1848 event(s) producing an alert was detected by the analyzer. In the 1849 case of more than one event, the time the first event was detected. 1850 (This may or may not be the same time as CreateTime; analyzers are 1851 not required to send alerts immediately upon detection). 1853 4.2.5.3. The AnalyzerTime Class 1855 The AnalyzerTime class is used to indicate the current date and time 1856 on the analyzer. Its values should be filled in as late as possible 1857 in the message transmission process, ideally immediately before 1858 placing the message "on the wire." 1860 The use of to perform rudimentary time synchronization 1861 between analyzers and managers is discussed in Section 6.3. 1863 4.2.6. The Assessment Classes 1865 The data model provides three types of "assessments" that an analyzer 1866 can make about an event. These classes are aggregates of the 1867 Assessment class. 1869 4.2.6.1. The Impact Class 1871 The Impact class is used to provide the analyzer's assessment of the 1872 impact of the event on the target(s). It is represented in the IDMEF 1873 DTD as follows: 1875 1878 1881 1885 1886 1893 The Impact class has three attributes: 1895 severity 1897 An estimate of the relative severity of the event. The permitted 1898 values are shown below. There is no default value. (See also 1899 Section 10.) 1900 +------+---------+-----------------------------------------+ 1901 | Rank | Keyword | Description | 1902 +------+---------+-----------------------------------------+ 1903 | O | info | Alert represents informational activity | 1904 | | | | 1905 | 1 | low | Low severity | 1906 | | | | 1907 | 2 | medium | Medium severity | 1908 | | | | 1909 | 3 | high | High severity | 1910 +------+---------+-----------------------------------------+ 1912 completion 1914 An indication of whether the analyzer believes the attempt that 1915 the event describes was successful or not. The permitted values 1916 are shown below. There is no default value. (See also 1917 Section 10.) 1919 +------+-----------+--------------------------------+ 1920 | Rank | Keyword | Description | 1921 +------+-----------+--------------------------------+ 1922 | 0 | failed | The attempt was not successful | 1923 | | | | 1924 | 1 | succeeded | The attempt succeeded | 1925 +------+-----------+--------------------------------+ 1927 type 1929 The type of attempt represented by this event, in relatively broad 1930 categories. The permitted values are shown below. The default 1931 value is "other." (See also Section 10.) 1933 +------+---------+--------------------------------------------------+ 1934 | Rank | Keyword | Description | 1935 +------+---------+--------------------------------------------------+ 1936 | 0 | admin | Administrative privileges were attempted or | 1937 | | | obtained | 1938 | | | | 1939 | 1 | dos | A denial of service was attempted or completed | 1940 | | | | 1941 | 2 | file | An action on a file was attempted or completed | 1942 | | | | 1943 | 3 | recon | A reconnaissance probe was attempted or | 1944 | | | completed | 1945 | | | | 1946 | 4 | user | User privileges were attempted or obtained | 1947 | | | | 1948 | 5 | other | Anything not in one of the above categories | 1949 +------+---------+--------------------------------------------------+ 1951 All three attributes are optional. The element itself may be empty, 1952 or may contain a textual description of the impact, if the analyzer 1953 is able to provide additional details. 1955 4.2.6.2. The Action Class 1957 The Action class is used to describe any actions taken by the 1958 analyzer in response to the event. Is is represented in the IDMEF 1959 DTD as follows: 1961 1965 1966 1971 Action has one attribute: 1973 category 1975 The type of action taken. The permitted values are shown below. 1976 The default value is "other." (See also Section 10.) 1978 +------+-------------------+----------------------------------------+ 1979 | Rank | Keyword | Description | 1980 +------+-------------------+----------------------------------------+ 1981 | 0 | block-installed | A block of some sort was installed to | 1982 | | | prevent an attack from reaching its | 1983 | | | destination. The block could be a | 1984 | | | port block, address block, etc., or | 1985 | | | disabling a user account. | 1986 | | | | 1987 | 1 | notification-sent | A notification message of some sort | 1988 | | | was sent out-of-band (via pager, | 1989 | | | e-mail, etc.). Does not include the | 1990 | | | transmission of this alert. | 1991 | | | | 1992 | 2 | taken-offline | A system, computer, or user was taken | 1993 | | | offline, as when the computer is shut | 1994 | | | down or a user is logged off. | 1995 | | | | 1996 | 3 | other | Anything not in one of the above | 1997 | | | categories. | 1998 +------+-------------------+----------------------------------------+ 2000 The element itself may be empty, or may contain a textual 2001 description of the action, if the analyzer is able to provide 2002 additional details. 2004 4.2.6.3. The Confidence Class 2006 The Confidence class is used to represent the analyzer's best 2007 estimate of the validity of its analysis. It is represented in the 2008 IDMEF DTD as follows: 2010 2014 2015 2020 The Confidence class has one attribute: 2022 rating 2024 The analyzer's rating of its analytical validity. The permitted 2025 values are shown below. The default value is "numeric." (See 2026 also Section 10.) 2028 +------+---------+--------------------------------------------------+ 2029 | Rank | Keyword | Description | 2030 +------+---------+--------------------------------------------------+ 2031 | 0 | low | The analyzer has little confidence in its | 2032 | | | validity | 2033 | | | | 2034 | 1 | medium | The analyzer has average confidence in its | 2035 | | | validity | 2036 | | | | 2037 | 2 | high | The analyzer has high confidence in its validity | 2038 | | | | 2039 | 3 | numeric | The analyzer has provided a posterior | 2040 | | | probability value indicating its confidence in | 2041 | | | its validity | 2042 +------+---------+--------------------------------------------------+ 2043 This element should be used only when the analyzer can produce 2044 meaningful information. Systems that can output only a rough 2045 heuristic should use "low", "medium", or "high" as the rating value. 2046 In this case, the element content should be omitted. 2048 Systems capable of producing reasonable probability estimates should 2049 use "numeric" as the rating value and include a numeric confidence 2050 value in the element content. This numeric value should reflect a 2051 posterior probability (the probability that an attack has occurred 2052 given the data seen by the detection system and the model used by the 2053 system). It is a floating point number between 0.0 and 1.0, 2054 inclusive. The number of digits should be limited to those 2055 representable by a single precision floating point value, and may be 2056 represented as described in Section 3.2.2. 2058 NOTE: It should be noted that different types of analyzers may 2059 compute confidence values in different ways and that in many 2060 cases, confidence values from different analyzers should not be 2061 compared (for example, if the analyzers use different methods of 2062 computing or representing confidence, or are of different types or 2063 configurations). Care should be taken when implementing systems 2064 that process confidence values (such as event correlators) not to 2065 make comparisons or assumptions that cannot be supported by the 2066 system's knowledge of the environment in which it is working. 2068 4.2.7. The Support Classes 2070 The support classes make up the major parts of the core classes, and 2071 are shared between them. 2073 4.2.7.1. The Reference Class 2075 The Reference class provides the "name" of an alert, or other 2076 information allowing the manager to determine what it is. 2078 The Reference class is composed of two aggregate classes, as shown in 2079 Figure 29. 2081 +----------------+ 2082 | Reference | 2083 +----------------+ +------+ 2084 | STRING origin |<>----------| name | 2085 | STRING meaning | +------+ 2086 | | +------+ 2087 | |<>----------| url | 2088 | | +------+ 2089 +----------------+ 2091 Figure 29: The Reference Class 2093 The aggregate classes that make up Reference are: 2095 name 2097 Exactly one. STRING. The name of the alert, from one of the 2098 origins listed below. 2100 url 2102 Exactly one. STRING. A URL at which the manager (or the human 2103 operator of the manager) can find additional information about the 2104 alert. The document pointed to by the URL may include an in-depth 2105 description of the attack, appropriate countermeasures, or other 2106 information deemed relevant by the vendor. 2108 This is represented in the IDMEF DTD as follows: 2110 2115 2118 2123 The Reference class has two attributes: 2125 origin 2127 Required. The source from which the name of the alert originates. 2128 The permitted values for this attribute are shown below. The 2129 default value is "unknown". (See also Section 10.) 2131 +------+-----------------+------------------------------------------+ 2132 | Rank | Keyword | Description | 2133 +------+-----------------+------------------------------------------+ 2134 | 0 | unknown | Origin of the name is not known | 2135 | | | | 2136 | 1 | vendor-specific | A vendor-specific name (and hence, URL); | 2137 | | | this can be used to provide | 2138 | | | product-specific information | 2139 | | | | 2140 | 2 | user-specific | A user-specific name (and hence, URL); | 2141 | | | this can be used to provide | 2142 | | | installation-specific information | 2143 | | | | 2144 | 3 | bugtraqid | The SecurityFocus ("Bugtraq") | 2145 | | | vulnerability database identifier | 2146 | | | (http://www.securityfocus.com/vdb) | 2147 | | | | 2148 | 4 | cve | The Common Vulnerabilities and Exposures | 2149 | | | (CVE) name (http://www.cve.mitre.org/) | 2150 | | | | 2151 | 5 | osvdb | The Open Source Vulnerability Database | 2152 | | | (http://www.osvdb.org) | 2153 +------+-----------------+------------------------------------------+ 2155 meaning 2157 Optional. The meaning of the reference, as understood by the 2158 alert provider. This field is only valid if the value of the 2159 attribute is set to "vendor-specific" or "user-specific". 2161 4.2.7.2. The Node Class 2163 The Node class is used to identify hosts and other network devices 2164 (routers, switches, etc.). 2166 The Node class is composed of three aggregate classes, as shown in 2167 Figure 31. 2169 +---------------+ 2170 | Node | 2171 +---------------+ 0..1 +----------+ 2172 | STRING ident |<>----------| location | 2173 | ENUM category | +----------+ 2174 | | 0..1 +----------+ 2175 | |<>----------| name | 2176 | | +----------+ 2177 | | 0..* +----------+ 2178 | |<>----------| Address | 2179 | | +----------+ 2180 +---------------+ 2182 Figure 31: The Node Class 2184 The aggregate classes that make up Node are: 2186 location 2188 Zero or one. STRING. The location of the equipment. 2190 name 2192 Zero or one. STRING. The name of the equipment. This 2193 information MUST be provided if no Address information is given. 2195 Address 2197 Zero or more. The network or hardware address of the equipment. 2198 Unless a name (above) is provided, at least one address must be 2199 specified. 2201 This is represented in the IDMEF DTD as follows: 2203 2208 2211 2217 The Node class has two attributes: 2219 ident 2221 Optional. A unique identifier for the node, see Section 3.2.9. 2223 category 2225 Optional. The "domain" from which the name information was 2226 obtained, if relevant. The permitted values for this attribute 2227 are shown in the table below. The default value is "unknown". 2228 (See also Section 10 for extensions to the table.) 2230 +------+----------+------------------------------------------+ 2231 | Rank | Keyword | Description | 2232 +------+----------+------------------------------------------+ 2233 | 0 | unknown | Domain unknown or not relevant | 2234 | | | | 2235 | 1 | ads | Windows 2000 Advanced Directory Services | 2236 | | | | 2237 | 2 | afs | Andrew File System (Transarc) | 2238 | | | | 2239 | 3 | coda | Coda Distributed File System | 2240 | | | | 2241 | 4 | dfs | Distributed File System (IBM) | 2242 | | | | 2243 | 5 | dns | Domain Name System | 2244 | | | | 2245 | 6 | hosts | Local hosts file | 2246 | | | | 2247 | 7 | kerberos | Kerberos realm | 2248 | | | | 2249 | 8 | nds | Novell Directory Services | 2250 | | | | 2251 | 9 | nis | Network Information Services (Sun) | 2252 | | | | 2253 | 10 | nisplus | Network Information Services Plus (Sun) | 2254 | | | | 2255 | 11 | nt | Windows NT domain | 2256 | | | | 2257 | 12 | wfw | Windows for Workgroups | 2258 +------+----------+------------------------------------------+ 2260 4.2.7.2.1. The Address Class 2262 The Address class is used to represent network, hardware, and 2263 application addresses. 2265 The Address class is composed of two aggregate classes, as shown in 2266 Figure 33. 2268 +------------------+ 2269 | Address | 2270 +------------------+ +---------+ 2271 | STRING ident |<>----------| address | 2272 | ENUM category | +---------+ 2273 | STRING vlan-name | 0..1 +---------+ 2274 | INTEGER vlan-num |<>----------| netmask | 2275 | | +---------+ 2276 +------------------+ 2278 Figure 33: The Address Class 2280 The aggregate classes that make up Address are: 2282 address 2284 Exactly one. STRING. The address information. The format of 2285 this data is governed by the category attribute. 2287 netmask 2289 Zero or one. STRING. The network mask for the address, if 2290 appropriate. 2292 This is represented in the IDMEF DTD as follows: 2294 2300 2303 2311 The Address class has four attributes: 2313 ident 2315 Optional. A unique identifier for the address, see Section 3.2.9. 2317 category 2319 Optional. The type of address represented. The permitted values 2320 for this attribute are shown below. The default value is 2321 "unknown". (See also Section 10.) 2323 +------+---------------+--------------------------------------------+ 2324 | Rank | Keyword | Description | 2325 +------+---------------+--------------------------------------------+ 2326 | 0 | unknown | Address type unknown | 2327 | | | | 2328 | 1 | atm | Asynchronous Transfer Mode network address | 2329 | | | | 2330 | 2 | e-mail | Electronic mail address (RFC 822) | 2331 | | | | 2332 | 3 | lotus-notes | Lotus Notes e-mail address | 2333 | | | | 2334 | 4 | mac | Media Access Control (MAC) address | 2335 | | | | 2336 | 5 | sna | IBM Shared Network Architecture (SNA) | 2337 | | | address | 2338 | | | | 2339 | 6 | vm | IBM VM ("PROFS") e-mail address | 2340 | | | | 2341 | 7 | ipv4-addr | IPv4 host address in dotted-decimal | 2342 | | | notation (a.b.c.d) | 2343 | | | | 2344 | 8 | ipv4-addr-hex | IPv4 host address in hexadecimal notation | 2345 | | | | 2346 | 9 | ipv4-net | IPv4 network address in dotted-decimal | 2347 | | | notation, slash, significant bits | 2348 | | | (a.b.c.d/nn) | 2349 | | | | 2350 | 10 | ipv4-net-mask | IPv4 network address in dotted-decimal | 2351 | | | notation, slash, network mask in | 2352 | | | dotted-decimal notation (a.b.c.d/w.x.y.z) | 2353 | | | | 2354 | 11 | ipv6-addr | IPv6 host address | 2355 | | | | 2356 | 12 | ipv6-addr-hex | IPv6 host address in hexadecimal notation | 2357 | | | | 2358 | 13 | ipv6-net | IPv6 network address, slash, significant | 2359 | | | bits | 2360 | | | | 2361 | 14 | ipv6-net-mask | IPv6 network address, slash, network mask | 2362 +------+---------------+--------------------------------------------+ 2364 vlan-name 2366 Optional. The name of the Virtual LAN to which the address 2367 belongs. 2369 vlan-num 2371 Optional. The number of the Virtual LAN to which the address 2372 belongs. 2374 4.2.7.3. The User Class 2376 The User class is used to describe users. It is primarily used as a 2377 "container" class for the UserId aggregate class, as shown in 2378 Figure 35. 2380 +---------------+ 2381 | User | 2382 +---------------+ 1..* +--------+ 2383 | STRING ident |<>----------| UserId | 2384 | ENUM category | +--------+ 2385 +---------------+ 2387 Figure 35: The User Class 2389 The aggregate class contained in User is: 2391 UserId 2393 One or more. Identification of a user, as indicated by its type 2394 attribute (see Section 4.2.7.3.1). 2396 This is represented in the IDMEF DTD as follows: 2398 2402 2405 2411 The User class has two attributes: 2413 ident 2415 Optional. A unique identifier for the user, see Section 3.2.9. 2417 category 2419 Optional. The type of user represented. The permitted values for 2420 this attribute are shown below. The default value is "unknown". 2421 (See also Section 10.) 2423 +------+-------------+------------------------------------+ 2424 | Rank | Keyword | Description | 2425 +------+-------------+------------------------------------+ 2426 | 0 | unknown | User type unknown | 2427 | | | | 2428 | 1 | application | An application user | 2429 | | | | 2430 | 2 | os-device | An operating system or device user | 2431 +------+-------------+------------------------------------+ 2433 4.2.7.3.1. The UserId Class 2435 The UserId class provides specific information about a user. More 2436 than one UserId can be used within the User class to indicate 2437 attempts to transition from one user to another, or to provide 2438 complete information about a user's (or process') privileges. 2440 The UserId class is composed of two aggregate classes, as shown in 2441 Figure 37. 2443 +--------------+ 2444 | UserId | 2445 +--------------+ 0..1 +--------+ 2446 | STRING ident |<>----------| name | 2447 | ENUM type | +--------+ 2448 | STRING tty | 0..1 +--------+ 2449 | |<>----------| number | 2450 | | +--------+ 2451 +--------------+ 2453 Figure 37: The UserId Class 2455 The aggregate classes that make up UserId are: 2457 name 2459 Zero or one. STRING. A user or group name. 2461 number 2463 Zero or one. INTEGER. A user or group number. 2465 This is represented in the IDMEF DTD as follows: 2467 2472 2475 2482 The UserId class has three attributes: 2484 ident 2486 Optional. A unique identifier for the user id, see Section 3.2.9. 2488 type 2490 Optional. The type of user information represented. The 2491 permitted values for this attribute are shown below. The default 2492 value is "original-user". (See also Section 10.) 2494 +------+---------------+--------------------------------------------+ 2495 | Rank | Keyword | Description | 2496 +------+---------------+--------------------------------------------+ 2497 | 0 | current-user | The current user id being used by the user | 2498 | | | or process. On Unix systems, this would | 2499 | | | be the "real" user id, in general. | 2500 | | | | 2501 | 1 | original-user | The actual identity of the user or process | 2502 | | | being reported on. On those systems that | 2503 | | | (a) do some type of auditing and (b) | 2504 | | | support extracting a user id from the | 2505 | | | "audit id" token, that value should be | 2506 | | | used. On those systems that do not | 2507 | | | support this, and where the user has | 2508 | | | logged into the system, the "login id" | 2509 | | | should be used. | 2510 | | | | 2511 | 2 | target-user | The user id the user or process is | 2512 | | | attempting to become. This would apply, | 2513 | | | on Unix systems for example, when the user | 2514 | | | attempts to use "su," "rlogin," "telnet," | 2515 | | | etc. | 2516 | | | | 2517 | 3 | user-privs | Another user id the user or process has | 2518 | | | the ability to use, or a user id assoc- | 2519 | | | iated with a file permission. On Unix | 2520 | | | systems, this would be the "effective" | 2521 | | | user id in a user or process context, and | 2522 | | | the owner permissions in a file context. | 2523 | | | Multiple UserId elements of this type may | 2524 | | | be used to specify a list of privileges. | 2525 | | | | 2526 | 4 | current-group | The current group id (if applicable) being | 2527 | | | used by the user or process. On Unix | 2528 | | | systems, this would be the "real" group | 2529 | | | id, in general. | 2530 | | | | 2531 | 5 | group-privs | Another group id the group or process has | 2532 | | | the ability to use, or a group id | 2533 | | | associated with a file permission. On | 2534 | | | Unix systems, this would be the "effect- | 2535 | | | ive" group id in a group or process | 2536 | | | context, and the group permissions in a | 2537 | | | file context. On BSD-derived Unix | 2538 | | | systems, multiple UserId elements of this | 2539 | | | type would be used to include all the | 2540 | | | group ids on the "group list." | 2541 | | | | 2542 | 6 | other-privs | Not used in a user, group, or process | 2543 | | | context, only used in the file context. | 2544 | | | The file permissions assigned to users who | 2545 | | | do not match either the user or group | 2546 | | | permissions on the file. On Unix systems, | 2547 | | | this would be the "world" permissions. | 2548 +------+---------------+--------------------------------------------+ 2550 tty 2552 Optional. STRING. The tty the user is using. 2554 4.2.7.4. The Process Class 2556 The Process class is used to describe processes being executed on 2557 sources, targets, and analyzers. 2559 The Process class is composed of five aggregate classes, as shown in 2560 Figure 39. 2562 +--------------+ 2563 | Process | 2564 +--------------+ +------+ 2565 | STRING ident |<>----------| name | 2566 | | +------+ 2567 | | 0..1 +------+ 2568 | |<>----------| pid | 2569 | | +------+ 2570 | | 0..1 +------+ 2571 | |<>----------| path | 2572 | | +------+ 2573 | | 0..* +------+ 2574 | |<>----------| arg | 2575 | | +------+ 2576 | | 0..* +------+ 2577 | |<>----------| env | 2578 | | +------+ 2579 +--------------+ 2581 Figure 39: The Process Class 2583 The aggregate classes that make up Process are: 2585 name 2587 Exactly one. STRING. The name of the program being executed. 2588 This is a short name; path and argument information are provided 2589 elsewhere. 2591 pid 2593 Zero or one. INTEGER. The process identifier of the process. 2595 path 2597 Zero or one. STRING. The full path of the program being 2598 executed. 2600 arg 2602 Zero or more. STRING. A command-line argument to the program. 2603 Multiple arguments may be specified (they are assumed to have 2604 occurred in the same order they are provided) with multiple uses 2605 of arg. 2607 env 2609 Zero or more. STRING. An environment string associated with the 2610 process; generally of the format "VARIABLE=value". Multiple 2611 environment strings may be specified with multiple uses of env. 2613 This is represented in the IDMEF DTD as follows: 2615 2618 2623 The Process class has one attribute: 2625 ident 2627 Optional. A unique identifier for the process, see Section 3.2.9. 2629 4.2.7.5. The Service Class 2631 The Service class describes network services on sources and targets. 2632 It can identify services by name, port, and protocol. When Service 2633 occurs as an aggregate class of Source, it is understood that the 2634 service is one from which activity of interest is originating; and 2635 that the service is "attached" to the Node, Process, and User 2636 information also contained in Source. Likewise, when Service occurs 2637 as an aggregate class of Target, it is understood that the service is 2638 one to which activity of interest is being directed; and that the 2639 service is "attached" to the Node, Process, and User information also 2640 contained in Target. If Service occurs in both Source and Target, 2641 then information in both locations should be the same. If 2642 information is the same in both locations and implementers wish to 2643 carry it in only one location, they should specify it as an aggregate 2644 of the Target class. 2646 The Service class is composed of four aggregate classes, as shown in 2647 Figure 41. 2649 +-----------------------------+ 2650 | Service | 2651 +-----------------------------+ 0..1 +----------+ 2652 | STRING ident |<>----------| name | 2653 | INTEGER ip_version | +----------+ 2654 | INTEGER iana_protocol_number| 0..1 +----------+ 2655 | STRING iana_protocol_name |<>----------| port | 2656 | | +----------+ 2657 | | 0..1 +----------+ 2658 | |<>----------| portlist | 2659 | | +----------+ 2660 | | 0..1 +----------+ 2661 | |<>----------| protocol | 2662 | | +----------+ 2663 +-----------------------------+ 2664 /_\ 2665 | 2666 +---------+--------+ 2667 | | 2668 +-------------+ +-------------+ 2669 | SNMPService | | WebService | 2670 +-------------+ +-------------+ 2672 Figure 41: The Service Class 2674 The aggregate classes that make up Service are: 2676 name 2678 Zero or one. STRING. The name of the service. Whenever 2679 possible, the name from the IANA list of well-known ports SHOULD 2680 be used. 2682 port 2684 Zero or one. INTEGER. The port number being used. 2686 portlist 2688 Zero or one. PORTLIST. A list of port numbers being used; see 2689 Section 3.2.8 for formatting rules. If a portlist is given, the 2690 iana_protocol_number and iana_protocol_name MUST apply to all the 2691 elements of the list. 2693 protocol 2694 Zero or one. STRING. Additional information about the protocol 2695 being used. The intent of the protocol field is to carry 2696 additional information related to the protocol being used when the 2697 attributes iana_protocol_number or/and 2698 iana_protocol_name are filed. 2700 A Service MUST be specified as either (a) a name or a port, or (b) a 2701 portlist. The protocol is optional in all cases, but no other 2702 combinations are permitted. 2704 Service is represented in the IDMEF DTD as follows: 2706 2710 2718 The Service class has four attributes: 2720 ident 2722 Optional. A unique identifier for the service, see Section 3.2.9. 2724 ip_version 2726 Optional. INTEGER. The IP version number. 2728 iana_protocol_number 2730 Optional. INTEGER. The IANA protocol number. 2732 iana_protocol_name 2734 Optional. STRING. The IANA protocol name. 2736 4.2.7.5.1. The WebService Class 2738 The WebService class carries additional information related to web 2739 traffic. 2741 The WebService class is composed of four aggregate classes, as shown 2742 in Figure 43. 2744 +-------------+ 2745 | Service | 2746 +-------------+ 2747 /_\ 2748 | 2749 +-------------+ 2750 | WebService | 2751 +-------------+ +-------------+ 2752 | |<>----------| url | 2753 | | +-------------+ 2754 | | 0..1 +-------------+ 2755 | |<>----------| cgi | 2756 | | +-------------+ 2757 | | 0..1 +-------------+ 2758 | |<>----------| http-method | 2759 | | +-------------+ 2760 | | 0..* +-------------+ 2761 | |<>----------| arg | 2762 | | +-------------+ 2763 +-------------+ 2765 Figure 43: The WebService Class 2767 The aggregate classes that make up WebService are: 2769 url 2771 Exactly one. STRING. The URL in the request. 2773 cgi 2775 Zero or one. STRING. The CGI script in the request, without 2776 arguments. 2778 http-method 2780 Zero or one. STRING. The HTTP method (PUT, GET) used in the 2781 request. 2783 arg 2785 Zero or more. STRING. The arguments to the CGI script. 2787 This is represented in the IDMEF DTD as follows: 2789 2792 2796 4.2.7.5.2. The SNMPService Class 2798 The SNMPService class carries additional information related to SNMP 2799 traffic. The aggregate classes composing SNMPService must be 2800 interpreted as described in RFC 3411 [14] and RFC 3584 [15]. 2802 The SNMPService class is composed of eight aggregate classes, as 2803 shown in Figure 45. 2805 +-------------+ 2806 | Service | 2807 +-------------+ 2808 /_\ 2809 | 2810 +-------------+ 2811 | SNMPService | 2812 +-------------+ 0..1 +----------------------+ 2813 | |<>----------| oid | 2814 | | +----------------------+ 2815 | | 0..1 +----------------------+ 2816 | |<>----------|messageProcessingModel| 2817 | | +----------------------+ 2818 | | 0..1 +----------------------+ 2819 | |<>----------| securityModel | 2820 | | +----------------------+ 2821 | | 0..1 +----------------------+ 2822 | |<>----------| securityName | 2823 | | +----------------------+ 2824 | | 0..1 +----------------------+ 2825 | |<>----------| securityLevel | 2826 | | +----------------------+ 2827 | | 0..1 +----------------------+ 2828 | |<>----------| contextName | 2829 | | +----------------------+ 2830 | | 0..1 +----------------------+ 2831 | |<>----------| contextEngineID | 2832 | | +----------------------+ 2833 | | 0..1 +----------------------+ 2834 | |<>----------| command | 2835 | | +----------------------+ 2836 +-------------+ 2838 Figure 45: The SNMPService Class 2840 The aggregate classes that make up SNMPService are: 2842 oid 2844 Zero or one. STRING. The object identifier in the request. 2846 messageProcessingModel 2848 Zero or one. INTEGER. The SNMP version, typically 0 for SNMPv1, 2849 1 for SNMPv2c, 2 for SNMPv2u and SNMPv2* and 3 for SNMPv3, see RFC 2850 3411 [14] section 5 for appropriate values. 2852 securityModel 2854 Zero or one. INTEGER. The identification of the security model 2855 in use, typically 0 for any, 1 for SNMPv1, 2 for SNMPv2c, 3 for 2856 USM, see RFC 3411 [14] section 5 for appropriate values. 2858 securityName 2860 Zero or one. STRING. The object's security name, see RFC 3411 2861 [14] section 3.2.2. 2863 securityLevel 2865 Zero or one. INTEGER. The security level of the SNMP request, 2866 see RFC 3411 [14] section 3.4.3. 2868 contextName 2870 Zero or one. STRING. The object's context name, see RFC 3411 2871 [14] section 3.3.3. 2873 contextEngineID 2875 Zero or one. STRING. The object's context engine identifier, see 2876 RFC 3411 [14] section 3.3.2. 2878 command 2880 Zero or one. STRING. The command sent to the SNMP server (GET, 2881 SET. etc.). 2883 If other fields of an SNMP message are available and should be 2884 incorporated in the IDMEF alert, they must be located in the 2885 additionaldata structure with the meaning being an object definition 2886 defined in RFC 3411 [14] section 5 and the value located within the 2887 additionaldata payload. 2889 This is represented in the IDMEF DTD as follows: 2891 2895 2899 4.2.7.6. The File Class 2901 The File class provides specific information about a file or other 2902 file-like object that has been created, deleted, or modified on the 2903 target. The description can provide either the file settings prior 2904 to the event or the file settings at the time of the event, as 2905 specified using the "category" attribute. 2907 The File class is composed of eleven aggregate classes, as shown in 2908 Figure 47. 2910 +--------------+ 2911 | File | 2912 +--------------+ +-------------+ 2913 | |<>----------| name | 2914 | | +-------------+ 2915 | | +-------------+ 2916 | |<>----------| path | 2917 | | +-------------+ 2918 | | 0..1 +-------------+ 2919 | |<>----------| create-time | 2920 | | +-------------+ 2921 | | 0..1 +-------------+ 2922 | |<>----------| modify-time | 2923 | | +-------------+ 2924 | | 0..1 +-------------+ 2925 | |<>----------| access-time | 2926 | | +-------------+ 2927 | | 0..1 +-------------+ 2928 | |<>----------| data-size | 2929 | | +-------------+ 2930 | | 0..1 +-------------+ 2931 | |<>----------| disk-size | 2932 | | +-------------+ 2933 | | 0..* +-------------+ 2934 | |<>----------| FileAccess | 2935 | | +-------------+ 2936 | | 0..* +-------------+ 2937 | |<>----------| Linkage | 2938 | | +-------------+ 2939 | | 0..1 +-------------+ 2940 | |<>----------| Inode | 2941 | | +-------------+ 2942 | | 0..* +-------------+ 2943 | |<>----------| Checksum | 2944 | | +-------------+ 2945 +--------------+ 2947 Figure 47: The File Class 2949 The aggregate classes that make up File are: 2951 name 2953 Exactly one. STRING. The name of the file to which the alert 2954 applies, not including the path to the file. 2956 path 2958 Exactly one. STRING. The full path to the file, including the 2959 name. The path name should be represented in as "universal" a 2960 manner as possible, to facilitate processing of the alert. 2962 For Windows systems, the path should be specified using the 2963 Universal Naming Convention (UNC) for remote files, and using a 2964 drive letter for local files (e.g., "C:\boot.ini"). For Unix 2965 systems, paths on network file systems should use the name of the 2966 mounted resource instead of the local mount point (e.g., 2967 "fileserver:/usr/local/bin/foo"). The mount point can be provided 2968 using the element. 2970 create-time 2972 Zero or one. DATETIME. Time the file was created. Note that 2973 this is *not* the Unix "st_ctime" file attribute (which is not 2974 file creation time). The Unix "st_ctime" attribute is contained 2975 in the "Inode" class. 2977 modify-time 2979 Zero or one. DATETIME. Time the file was last modified. 2981 access-time 2983 Zero or one. DATETIME. Time the file was last accessed. 2985 data-size 2987 Zero or one. INTEGER. The size of the data, in bytes. Typically 2988 what is meant when referring to file size. On Unix UFS file 2989 systems, this value corresponds to stat.st_size. On Windows NTFS, 2990 this value corres- ponds to VDL. 2992 disk-size 2994 Zero or one. INTEGER. The physical space on disk consumed by the 2995 file, in bytes. On Unix UFS file systems, this value corresponds 2996 to 512 * stat.st_blocks. On Windows NTFS, this value corresponds 2997 to EOF. 2999 FileAccess 3001 Zero or more. Access permissions on the file. 3003 Linkage 3005 Zero or more. File system objects to which this file is linked 3006 (other references for the file). 3008 Inode 3010 Zero or one. Inode information for this file (relevant to Unix). 3012 Checksum 3014 Zero or more. Checksum information for this file. 3016 This is represented in the IDMEF DTD as follows: 3018 3022 3027 3035 The File class has three attributes: 3037 ident 3039 Optional. A unique identifier for this file, see Section 3.2.9. 3041 category 3043 Required. The context for the information being provided. The 3044 permitted values are shown below. There is no default value. 3045 (See also Section 10.) 3047 +------+----------+-------------------------------------------------+ 3048 | Rank | Keyword | Description | 3049 +------+----------+-------------------------------------------------+ 3050 | 0 | current | The file information is from after the reported | 3051 | | | change | 3052 | | | | 3053 | 1 | original | The file information is from before the | 3054 | | | reported change | 3055 +------+----------+-------------------------------------------------+ 3057 fstype 3059 Optional. The type of file system the file resides on. This 3060 attribute governs how path names and other attributes are 3061 interpreted. 3063 file-type 3065 Optional. The type of file, as a mime-type. 3067 4.2.7.6.1. The FileAccess Class 3069 The FileAccess class represents the access permissions on a file. 3070 The representation is intended to be usefule across operating 3071 systems. 3073 The FileAccess class is composed of two aggregate classes, as shown 3074 in Figure 49. 3076 +--------------+ 3077 | FileAccess | 3078 +--------------+ +------------+ 3079 | |<>----------| UserId | 3080 | | +------------+ 3081 | | 1..* +------------+ 3082 | |<>----------| permission | 3083 | | +------------+ 3084 +--------------+ 3086 Figure 49: The FileAccess Class 3088 The aggregate classes that make up FileAccess are: 3090 UserId 3092 Exactly one. The user (or group) to which these permissions 3093 apply. The value of the "type" attribute must be "user-privs", 3094 "group-privs", or "other-privs" as appropriate. Other values for 3095 "type" MUST NOT be used in this context. 3097 permission 3099 One or more. STRING. Level of access allowed. The permitted 3100 values are shown below. There is no default value. (See also 3101 Section 10.) 3103 +------+-------------------+----------------------------------------+ 3104 | Rank | Keyword | Description | 3105 +------+-------------------+----------------------------------------+ 3106 | 0 | noAccess | No access at all is allowed for this | 3107 | | | user | 3108 | | | | 3109 | 1 | read | This user has read access to the file | 3110 | | | | 3111 | 2 | write | This user has write access to the file | 3112 | | | | 3113 | 3 | execute | This user has the ability to execute | 3114 | | | the file | 3115 | | | | 3116 | 4 | search | This user has the ability to search | 3117 | | | this file (applies to "execute" | 3118 | | | permission on directories in UNIX) | 3119 | | | | 3120 | 5 | delete | This user has the ability to delete | 3121 | | | this file | 3122 | | | | 3123 | 6 | executeAs | This user has the ability to execute | 3124 | | | this file as another user | 3125 | | | | 3126 | 7 | changePermissions | This user has the ability to change | 3127 | | | the access permissions on this file | 3128 | | | | 3129 | 8 | takeOwnership | This user has the ability to take | 3130 | | | ownership of this file | 3131 +------+-------------------+----------------------------------------+ 3133 The "changePermissions" and "takeOwnership" strings represent those 3134 concepts in Windows. On Unix, the owner of the file always has 3135 "changePermissions" access, even if no other access is allowed for 3136 that user. "Full Control" in Windows is represented by enumerating 3137 the permissions it contains. The "executeAs" string represents the 3138 set-user-id and set-group-id features in Unix. 3140 This is represented in the IDMEF DTD as follows: 3142 3143 3148 3152 4.2.7.6.2. The Linkage Class 3154 The Linkage class represents file system connections between the file 3155 described in the element and other objects in the file system. 3156 For example, if the element is a symbolic link or shortcut, 3157 then the element should contain the name of the object the 3158 link points to. Further information can be provided about the object 3159 in the element with another element, if appropriate. 3161 The Linkage class is composed of three aggregate classes, as shown in 3162 Figure 51. 3164 +--------------+ 3165 | Linkage | 3166 +--------------+ +------+ 3167 | |<>----------| name | 3168 | | +------+ 3169 | | +------+ 3170 | |<>----------| path | 3171 | | +------+ 3172 | | +------+ 3173 | |<>----------| File | 3174 | | +------+ 3175 +--------------+ 3177 Figure 51: The Linkage Class 3179 The aggregate classes that make up Linkage are: 3181 name 3183 Exactly one. STRING. The name of the file system object. not 3184 including the path. 3186 path 3188 Exactly one. STRING. The full path to the file system object, 3189 including the name. The path name should be represented in as 3190 "universal" a manner as possible, to facilitate processing of the 3191 alert. 3193 File 3195 Exactly one. A element may be used in place of the 3196 and elements if additional information about the file is to 3197 be included. 3199 This is represented in the IDMEF DTD as follows: 3201 3206 3209 3214 The Linkage class has one attribute: 3216 category 3218 The type of object that the link describes. The permitted values 3219 are shown below. There is no default value. (See also 3220 Section 10.) 3222 +------+---------------+--------------------------------------------+ 3223 | Rank | Keyword | Description | 3224 +------+---------------+--------------------------------------------+ 3225 | 0 | hard-link | The element represents another name | 3226 | | | for this file. This information may be | 3227 | | | more easily obtainable on NTFS file | 3228 | | | systems than others. | 3229 | | | | 3230 | 1 | mount-point | An alias for the directory specified by | 3231 | | | the parent's and elements. | 3232 | | | | 3233 | 2 | reparse-point | Applies only to Windows; excludes symbolic | 3234 | | | links and mount points, which are specific | 3235 | | | types of reparse points. | 3236 | | | | 3237 | 3 | shortcut | The file represented by a Windows | 3238 | | | "shortcut." A shortcut is distinguished | 3239 | | | from a symbolic link because of the | 3240 | | | difference in their contents, which may be | 3241 | | | of importance to the manager. | 3242 | | | | 3243 | 4 | stream | An Alternate Data Stream (ADS) in Windows; | 3244 | | | a fork on MacOS. Separate file system | 3245 | | | entity that is considered an extension of | 3246 | | | the main . | 3247 | 5 | symbolic-link | The element represents the file to | 3248 | | | which the link points. | 3249 +------+---------------+--------------------------------------------+ 3251 4.2.7.6.3. The Inode Class 3253 The Inode class is used to represent the additional information 3254 contained in a Unix file system i-node. 3256 The Inode class is composed of six aggregate classes, as shown in 3257 Figure 53. 3259 +--------------+ 3260 | Inode | 3261 +--------------+ +----------------+ 3262 | |<>----------| change-time | 3263 | | +----------------+ 3264 | | +----------------+ 3265 | |<>----------| number | 3266 | | +----------------+ 3267 | | +----------------+ 3268 | |<>----------| major-device | 3269 | | +----------------+ 3270 | | +----------------+ 3271 | |<>----------| minor-device | 3272 | | +----------------+ 3273 | | +----------------+ 3274 | |<>----------| c-major-device | 3275 | | +----------------+ 3276 | | +----------------+ 3277 | |<>----------| c-minor-device | 3278 | | +----------------+ 3279 +--------------+ 3281 Figure 53: The Inode Class 3283 The aggregate classes that make up Inode are: 3285 change-time 3287 Zero or one. DATETIME. The time of the last inode change, given 3288 by the st_ctime element of "struct stat". 3290 number 3291 Zero or one. INTEGER. The inode number. 3293 major-device 3295 Zero or one. INTEGER. The major device number of the device the 3296 file resides on. 3298 minor-device 3300 Zero or one. INTEGER. The minor device number of the device the 3301 file resides on. 3303 c-major-device 3305 Zero or one. INTEGER. The major device of the file itself, if it 3306 is a character special device. 3308 c-minor-device 3310 Zero or one. INTEGER. The minor device of the file itself, if it 3311 is a character special device. 3313 Note that , , and must be given 3314 together, and the and must be given 3315 together. 3317 This is represented in the IDMEF DTD as follows: 3319 3323 3327 4.2.7.6.4. The Checksum class 3329 The Checksum class represents checksum information associated with 3330 the file. This checksum information can be provided by file 3331 integrity checkers, among others. 3333 The checksum class is composed of two aggregate classes, as shown in 3334 Figure 55. 3336 +--------------+ 3337 | Checksum | 3338 +--------------+ +-------+ 3339 | algorithm |<>----------| value | 3340 | | +-------+ 3341 | | 0..1+-------+ 3342 | |<>----------| key | 3343 | | +-------+ 3344 +--------------+ 3346 Figure 55: The Checksum Class 3348 The aggregate classes that make up Checksum are: 3350 value 3352 Exactly one. STRING. The value of the checksum. 3354 key 3356 Zero or one. STRING. The key to the checksum, if appropriate. 3358 This is represented in the IDMEF DTD as follows: 3360 3365 3368 3373 The Checksum class has one attribute: 3375 algorithm 3377 The cryptographic algorithm used for the computation of the 3378 checksum. The permitted values are shown below. There is no 3379 default value. (See also Section 10.) 3380 +------+----------+------------------------------------------+ 3381 | Rank | Keyword | Description | 3382 +------+----------+------------------------------------------+ 3383 | 0 | MD4 | The MD4 algorithm. | 3384 | | | | 3385 | 1 | MD5 | The MD5 algorithm. | 3386 | | | | 3387 | 2 | SHA1 | The SHA1 algorithm. | 3388 | | | | 3389 | 3 | SHA2-256 | The SHA2 algorithm with 256 bits length. | 3390 | | | | 3391 | 4 | SHA2-384 | The SHA2 algorithm with 384 bits length. | 3392 | | | | 3393 | 5 | SHA2-512 | The SHA2 algorithm with 512 bits length. | 3394 | | | | 3395 | 6 | CRC-32 | The CRC algorithm with 32 bits length. | 3396 | | | | 3397 | 7 | Haval | The Haval algorithm. | 3398 | | | | 3399 | 8 | Tiger | The Tiger algorithm. | 3400 | | | | 3401 | 9 | Gost | The Gost algorithm. | 3402 +------+----------+------------------------------------------+ 3404 5. Extending the IDMEF 3406 As intrusion detection systems evolve, the IDMEF data model and DTD 3407 will have to evolve along with them. To allow new features to be 3408 added as they are developed, both the data model and the DTD can be 3409 extended as described in this section. As these extensions mature, 3410 they can then be incorporated into future versions of the 3411 specification. 3413 5.1. Extending the Data Model 3415 There are two mechanisms for extending the IDMEF data model, 3416 inheritance and aggregation: 3418 o Inheritance denotes a superclass/subclass type of relationship 3419 where the subclass inherits all the attributes, operations, and 3420 relationships of the superclass. This type of relationship is 3421 also called a "is-a" or "kind-of" relationship. Subclasses may 3422 have additional attributes or operations that apply only to the 3423 subclass, and not to the superclass. 3425 o Aggregation is a form of association in which the whole is related 3426 to its parts. This type of relationship is also referred to as a 3427 "part-of" relationship. In this case, the aggregate class 3428 contains all of its own attributes and as many of the attributes 3429 associated with its parts as required and specified by occurrence 3430 indicators. 3432 Of the two mechanisms, inheritance is preferred, because it preserves 3433 the existing data model structure and also preserves the operations 3434 (methods) executed on the classes of the structure. 3436 Note that the rules for extending the IDMEF DTD (see below) set 3437 limits on the places where extensions to the data model may be made. 3439 5.2. Extending the IDMEF DTD 3441 There are two ways to extend the IDMEF DTD: 3443 1. The AdditionalData class (see Section 4.2.4.6) allows 3444 implementors to include arbitrary "atomic" data items (integers, 3445 strings, etc.) in an Alert or Heartbeat message. This approach 3446 SHOULD be used whenever possible. See Section 7.4 and 3447 Section 7.5. 3449 2. The AdditionalData class allows implementors to extend the IDMEF 3450 DTD with additional DTD "modules" that describe arbitrarily 3451 complex data types and relationships. The remainder of this 3452 section describes this extension method. 3454 To extend the IDMEF DTD with a new DTD "module," the following steps 3455 MUST be followed: 3457 1. The document declaration MUST define a DTD Location that define 3458 the namespace and contains the location of the extension DTD, and 3459 then reference that namespace. 3461 2. Multiple extensions may be included by defining multiple 3462 namespaces and DTD locations, and referencing them. 3464 3. Extension DTDs MUST declare all of their elements and attributes 3465 in a separate XML namespace. Extension DTDs MUST NOT declare any 3466 elements or attributes in the "idmef" or default namespaces. 3468 4. Extensions MUST only be included in IDMEF alert and heartbeat 3469 messages under an element whose "type" attribute 3470 contains the value "xml". For example: 3472 In this example, the "vendorco" namespace is defined and then 3473 referenced, causing the DTD for the extension to be read by the XML 3474 parser. 3476 3482 3483 ... 3484 3485 3486 3489 content element of example 3490 3491 3492 3493 3494 3496 See Section 7.8 for another example of extending the IDMEF DTD. 3498 6. Special Considerations 3500 This section discusses some of the special considerations that must 3501 be taken into account by implementors of the IDMEF. 3503 6.1. XML Validity and Well-Formedness 3505 It is expected that IDMEF-compliant applications will not normally 3506 include the IDMEF DTD itself in their communications. Instead, the 3507 DTD will be referenced in the document type declaration in the IDMEF 3508 message. Such IDMEF documents will be well-formed and valid as 3509 defined in [3]. 3511 Other IDMEF documents will be specified that do not include the 3512 document prolog (e.g., entries in an IDMEF-format database). Such 3513 IDMEF documents will be well-formed but not valid. 3515 Generally, well-formedness implies that a document has a single 3516 element that contains everything else (e.g., ""), and that all 3517 the other elements nest nicely within each other without any 3518 overlapping (e.g., a "chapter" does not start in the middle of 3519 another "chapter"). 3521 Validity further implies that not only is the document well-formed, 3522 but it also follows specific rules (contained in the Document Type 3523 Definition) about which elements are "legal" in the document, how 3524 those elements nest within other elements, and so on (e.g., a 3525 "chapter" does not begin in the middle of a "title"). A document 3526 cannot be valid unless it references a DTD. 3528 XML processors are required to be able to parse any well-formed 3529 document, valid or not. The purpose of validation is to make the 3530 processing of that document (what's done with the data after it's 3531 parsed) easier. Without validation, a document may contain elements 3532 in nonsense order, elements "invented" by the author that the 3533 processing application doesn't understand, and so forth. 3535 IDMEF documents MUST be well-formed. IDMEF documents SHOULD be valid 3536 whenever both possible and practical. 3538 6.2. Unrecognized XML Tags 3540 On occasion, an IDMEF-compliant application may receive a well- 3541 formed, or even well-formed and valid, IDMEF message containing tags 3542 that it does not understand. The tags may be either: 3544 o Recognized as "legitimate" (a valid document), but the application 3545 does not know the semantic meaning of the element's content; or 3547 o Not recognized at all. 3549 IDMEF-compliant applications MUST continue to process IDMEF messages 3550 that contain unknown tags, provided that such messages meet the well- 3551 formedness requirement of Section 6.1. It is up to the individual 3552 application to decide how to process (or ignore) any content from the 3553 unknown elements(s). 3555 6.3. Analyzer-Manager Time Synchronization 3557 Synchronization of time-of-day clocks between analyzers and managers 3558 is outside the scope of this document. However, the following 3559 comments and suggestions are offered: 3561 1. Whenever possible, all analyzers and managers should have their 3562 time-of-day clocks synchronized to an external source such as NTP 3563 or SNTP [13, 14], GPS/GOES/WWV clocks, or some other reliable 3564 time standard. 3566 2. When external time synchronization is not possible, the IDMEF 3567 provides the element, which may be used to perform 3568 rudimentary time synchronization (see below). 3570 3. IDMEF-compliant applications SHOULD permit the user to enable/ 3571 disable the method of time synchronization as a 3572 configuration option. 3574 A number of caveats apply to the use of for time 3575 synchronization: 3577 1. works best in a "flat" environment where analyzers 3578 report up to a single level of managers. When a tree topology of 3579 high-level managers, intermediate relays, and analyzers is used, 3580 the problem becomes more complex. 3582 2. When intermediate message relays (managers or otherwise) are 3583 involved, two scenarios are possible: 3585 * The intermediaries may forward entire IDMEF messages, or may 3586 perform aggregation or correlation, but MUST NOT inject delay. 3587 In this case, time synchronization is end-to-end between the 3588 analyzer and the highest-level manager. 3590 * The intermediaries may inject delay, due to storage or 3591 additional processing. In this case, time synchronization 3592 MUST be performed at each hop. This means each intermediary 3593 must decompose the IDMEF message, adjust all time values, and 3594 then reconstruct the message before sending it on. 3596 3. When the environment is mixed, with some analyzers and managers 3597 using external time synchronization and some not, all managers 3598 and intermediaries must perform synchronization. 3599 This is because determining whether or not compensation is 3600 actually needed between two parties rapidly becomes very complex, 3601 and requires knowledge of other parts of the topology. 3603 4. If an alert can take alternate paths, or be stored in multiple 3604 locations, the recorded times may be different depending on the 3605 path taken. 3607 The above being said, synchronization is probably 3608 still better than nothing in many environments. To implement this 3609 type of synchronization, the following procedure is suggested: 3611 1. When an analyzer or manager sends an IDMEF message, it should 3612 place the current value of its time-of-day clock in an 3613 element. This should occur as late as possible in 3614 the message transmission process, ideally right before the 3615 message is "put on the wire." 3617 2. When a manager receives an IDMEF message, it should compute the 3618 difference between its own time-of-day clock and the time in the 3619 element of the message. This difference should 3620 then be used to adjust the times in the and 3621 elements (NTP timestamps should also be adjusted). 3623 3. If the manager is an intermediary and sends the IDMEF message on 3624 to a higher-level manager, and hop-by-hop synchronization is in 3625 effect, it should regenerate the value to contain 3626 the value of its own time-of-day clock. 3628 6.4. NTP Timestamp Wrap-Around 3630 From [8]: 3632 Note that, since some time in 1968 (second 2,147,483,648) the most 3633 significant bit (bit 0 of the integer part) has been set and that 3634 the 64-bit field will overflow some time in 2036 (second 3635 4,294,967,296). Should NTP or SNTP be in use in 2036, some 3636 external means will be necessary to qualify time relative to 1900 3637 and time relative to 2036 (and other multiples of 136 years). 3638 There will exist a 200-picosecond interval, henceforth ignored, 3639 every 136 years when the 64-bit field will be 0, which by 3640 convention is interpreted as an invalid or unavailable timestamp. 3642 IDMEF-compliant applications MUST NOT send a zero-valued NTP 3643 timestamp unless they mean to indicate that it is invalid or 3644 unavailable. If an IDMEF-compliant application must send an IDMEF 3645 message at the time of rollover, the application should wait for 200 3646 picoseconds until the timestamp will have a non-zero value. 3648 Also from [8]: 3650 As the NTP timestamp format has been in use for the last 17 years, 3651 it remains a possibility that it will be in use 40 years from now 3652 when the seconds field overflows. As it is probably inappropriate 3653 to archive NTP timestamps before bit 0 was set in 1968, a 3654 convenient way to extend the useful life of NTP timestamps is the 3655 following convention: 3657 If bit 0 is set, the UTC time is in the range 1968-2036 and UTC 3658 time is reckoned from 0h 0m 0s UTC on 1 January 1900. 3660 If bit 0 is not set, the time is in the range 2036-2104 and UTC 3661 time is reckoned from 6h 28m 16s UTC on 7 February 2036. 3663 Note that when calculating the correspondence, 2000 is not a leap 3664 year. Note also that leap seconds are not counted in the 3665 reckoning. 3667 IDMEF-compliant applications in use after 2036-02-07T06:28:16Z MUST 3668 adhere to the above convention. 3670 6.5. Digital Signatures 3672 Standard XML digital signature processing rules and syntax are 3673 specified in [11]. XML Signatures provide integrity, message 3674 authentication, and/or signer authentication services for data of any 3675 type, whether located within the XML that includes the signature or 3676 elsewhere. 3678 The IDMEF requirements document [2] assigns responsibility for 3679 message integrity and authentication to the communications protocol, 3680 not the message format. However, in situations where IDMEF messages 3681 are exchanged over other, less secure protocols, or in cases where 3682 the digital signatures must be archived for later use, the inclusion 3683 of digital signatures within an IDMEF message itself may be 3684 desirable. 3686 Specifications for the use of digital signatures within IDMEF 3687 messages are outside the scope of this document. However, if such 3688 functionality is needed, use of the XML Signature standard is 3689 RECOMMENDED. 3691 7. Examples 3693 The examples shown in this section demonstrate how the IDMEF is used 3694 to encode alert data. These examples are for illustrative purposes 3695 only, and do not necessarily represent the only (or even the "best" 3696 way to encode these particular alerts). These examples should not be 3697 taken as guidelines on how alerts should be classified. 3699 7.1. Denial of Service Attacks 3701 The following examples show how some common denial of service attacks 3702 could be represented in the IDMEF. 3704 7.1.1. The "teardrop" Attack 3706 Network-based detection of the "teardrop" attack. This shows the 3707 basic format of an alert. 3709 3711 3713 3714 3715 3716 Headquarters DMZ Network 3717 analyzer01.example.com 3718 3719 3720 3721 2000-03-09T10:01:25.93464-05:00 3722 3723 3724 3725 badguy.example.net 3726 3728 192.0.2.50 3729 255.255.255.255 3730 3731 3732 3733 3734 3735 3736 0xde796f70 3737 3738 3739 3740 3741 3742 124 3743 http://www.securityfocus.com/bid/124 3744 3745 3746 3747 3749 7.1.2. The "ping of death" Attack 3751 Network-based detection of the "ping of death" attack. Note the 3752 identification of multiple targets, and the identification of the 3753 source as a spoofed address. 3755 NOTE: The url has been cut to fit the IETF formating requirements. 3757 3759 3761 3762 3763 3764 sensor.example.com 3765 3766 3767 3768 2000-03-09T10:01:25.93464Z 3769 3770 3771 3772 3773 192.0.2.200 3774 3775 3776 3777 3778 3779 3780 192.0.2.50 3781 3782 3783 3784 3785 3786 lollipop 3787 3788 3789 3790 3791 Cabinet B10 3792 Cisco.router.b10 3793 3794 3795 3796 3797 CVE-1999-128 3798 http://www.cve.mitre.org/cgi-bin/ 3799 cvename.cgi?name=CVE-1999-128 3800 3801 3802 3803 3805 7.2. Port Scanning Attacks 3807 The following examples show how some common port scanning attacks 3808 could be represented in the IDMEF. 3810 7.2.1. Connection To a Disallowed Service 3812 Host-based detection of a policy violation (attempt to obtain 3813 information via "finger"). Note the identification of the target 3814 service, as well as the originating user (obtained, e.g., through 3815 RFC1413). 3817 3819 3821 3822 3823 3824 sensor.example.com 3825 3826 3827 3828 2000-03-09T18:47:25+02:00 3829 3830 3831 3832 3833 192.0.2.200 3834 3835 3836 3837 3838 badguy 3839 3840 3841 3842 31532 3843 3844 3845 3846 3847 myhost 3848 3849 192.0.2.50 3850 3851 3852 3853 finger 3854 79 3855 3856 3857 3858 3859 finger 3860 http://www.vendor.com/finger 3861 3862 3864 Distributed attack 3865 http://www.vendor.com/distributed 3866 3867 3868 3869 3871 7.2.2. Simple Port Scanning 3873 Network-based detection of a port scan. This shows detection by a 3874 single analyzer; see Example 8.5 for the same attack as detected by a 3875 correlation engine. Note the use of to show the ports 3876 that were scanned. 3878 3880 3882 3883 3884 3885 Headquarters Web Server 3886 analyzer62.example.com 3887 3888 3889 3890 2000-03-09T15:31:00-08:00 3891 3892 3893 3894 3895 192.0.2.200 3896 3897 3898 3899 3900 3901 www.example.com 3902 3903 192.0.2.50 3904 3905 3906 3907 5-25,37,42,43,53,69-119,123-514 3908 3909 3910 3911 3912 3913 portscan 3914 http://www.vendor.com/portscan 3915 3916 3917 3918 3920 7.3. Local Attacks 3922 The following examples show how some common local host attacks could 3923 be represented in the IDMEF. 3925 7.3.1. The "loadmodule" Attack 3927 Host-based detection of the "loadmodule" exploit. This attack 3928 involves tricking the "loadmodule" program into running another 3929 program; since "loadmodule" is set-user-id "root," the executed 3930 program runs with super-user privileges. Note the use of and 3931 to identify the user attempting the exploit and how he's 3932 doing it. 3934 3936 3938 3939 3940 3941 fileserver.example.com 3942 3943 3944 monitor 3945 8956 3946 monitor 3947 -d 3948 -m 3949 idmanager.example.com 3950 -l 3951 /var/logs/idlog 3952 3953 3954 3955 2000-03-09T08:12:32.3-05:00 3956 3957 3958 3959 3961 joe 3962 13243 3963 3964 3965 3966 loadmodule 3967 /usr/openwin/bin 3968 3969 3970 3971 3972 fileserver.example.com 3974 3975 3976 3978 3979 33 3980 http://www.securityfocus.com 3981 3982 3983 3984 3986 The IDS could also indicate that the target user is the "root" user, 3987 and show the attempted command; the alert might then look like: 3989 3991 3993 3994 3995 3996 fileserver.example.com 3997 3998 3999 monitor 4000 8956 4001 monitor 4002 -d 4003 -m 4004 idmanager.example.com 4005 -l 4006 /var/logs/idlog 4007 4008 4009 4010 2000-03-09T08:12:32.3-05:00 4011 4012 4013 4014 4015 joe 4016 13243 4017 4018 4019 4020 loadmodule 4021 /usr/openwin/bin 4023 4024 4025 4026 4027 fileserver.example.com 4028 4029 4030 4031 root 4032 0 4033 4034 4035 4036 sh 4037 25134 4038 /bin/sh 4039 4040 4041 4043 4044 4045 4047 Note that the identification of the classification is used. 4049 7.3.2. The "phf" Attack 4051 Network-based detection of the "phf" attack. Note the use of the 4052 element to provide more details about this particular 4053 attack. 4055 4057 4059 4060 4061 4062 sensor.example.com 4063 4064 4065 4066 2000-03-09T08:12:32-01:00 4067 4068 4069 4070 4072 192.0.2.200 4073 4074 4075 4076 21534 4077 4078 4079 4080 4081 www.example.com 4082 4084 192.0.2.100 4085 4086 4087 4088 8080 4089 4090 4091 http://www.example.com/cgi-bin/phf?/etc/group 4092 4093 /cgi-bin/phf 4094 GET 4095 4096 4097 4098 4099 4100 629 4101 4102 http://www.securityfocus.com/bid/629 4103 4104 4105 4106 4107 4109 7.3.3. File Modification 4111 Host-based detection of a race condition attack. Note the use of the 4112 to provide information about the files that are used to 4113 perform the attack. 4115 4117 4120 4121 4124 4125 etude 4126 4127 192.0.2.1 4128 4129 4130 4131 4132 2000-03-09T08:12:32-01:00 4133 4134 4135 4136 console 4137 4138 192.0.2.1 4139 4140 4141 4142 4143 4144 local 4145 4146 192.0.2.1 4147 4148 4149 4150 4151 456 4152 4153 4154 fred 4155 456 4156 4157 4158 456 4159 4160 4161 4162 xxx000238483 4163 /tmp/xxx000238483 4164 4165 4166 alice 4167 777 4169 4170 4171 4172 4173 4174 4175 4176 4177 user 4178 42 4179 4180 4181 4182 4183 4184 4185 4186 world 4187 4188 4189 4190 4191 passwd 4192 /etc/passwd 4193 4194 4195 4196 4197 4198 DOM race condition 4199 file://attack-info/race.html 4200 4201 4202 4203 4204 4206 7.4. System Policy Violation 4208 In this example, logins are restricted to daytime hours. The alert 4209 reports a violation of this policy that occurs when a user logs in a 4210 little after 10:00pm. Note the use of to provide 4211 information about the policy being violated. 4213 4215 4218 4219 4220 4221 dialserver.example.com 4222 4223 4224 4225 2000-03-09T22:18:07-05:00 4226 4227 4228 4229 4230 127.0.0.1 4231 4232 4233 4234 4325 4235 4236 4237 4238 4239 mainframe.example.com 4240 4241 4242 4243 louis 4244 501 4245 4246 4247 4248 login 4249 23 4250 4251 4252 4253 4254 out-of-hours activity 4255 http://my.company.com/policies 4256 4257 4258 4259 4261 2000-03-09T07:00:00-05:00 4262 4263 4265 2000-03-09T19:30:00-05:00 4267 4268 4269 4271 7.5. Correlated Alerts 4273 The following example shows how the port scan alert from 4274 Section 7.2.2 could be represented if it had been detected and sent 4275 from a correlation engine, instead of a single analyzer. 4277 4279 4281 4282 4283 4284 correlator01.example.com 4285 4286 4287 4288 2000-03-09T15:31:07Z 4289 4290 4291 4292 4293 192.0.2.200 4294 4295 4296 4297 4298 4299 www.example.com 4300 4301 192.0.2.50 4302 4303 4304 4305 5-25,37,42,43,53,69-119,123-514 4306 4307 4308 4309 4310 4311 portscan 4312 http://www.vendor.com/portscan 4313 4314 4315 4316 multiple ports in short time 4317 123456781 4318 123456782 4319 123456783 4320 123456784 4321 123456785 4322 123456786 4323 987654321 4324 4325 987654322 4326 4327 4328 4329 4331 7.6. Analyzer Assessments 4333 Host-based detection of a successful unauthorized acquisition of root 4334 access through the eject buffer overflow. Note the use of 4335 to provide information about the analyzer's evaluation 4336 of and reaction to the attack. 4338 4340 4342 4343 4344 4345 4346 2000-03-09T08:12:32-01:00 4347 4348 4349 4350 console 4351 4352 192.0.2.1 4353 4354 4355 4356 4357 4358 local 4359 4360 192.0.2.1 4361 4362 4363 4364 4365 456 4366 4367 4368 root 4369 0 4370 4371 4372 0 4373 4374 4375 4376 eject 4377 32451 4378 /usr/bin/eject 4379 \x90\x80\x3f\xff...\x08/bin/sh 4380 4381 4382 4384 4385 Unauthorized user to superuser 4386 file://attack-info/u2s.html 4387 4388 4389 4390 4392 4393 page 4394 4395 4396 disabled user (fred) 4397 4398 4399 logout user (fred) 4400 4401 4402 4403 4404 4406 7.7. Heartbeat 4408 This example shows a heartbeat message that provides "I'm alive and 4409 working" information to the manager. Note the use of 4410 elements, with "meaning" attributes, to provide some 4411 additional information. 4413 4415 4417 4418 4419 4420 Headquarters DMZ Network 4421 analyzer01.example.com 4422 4423 4424 4425 2000-03-09T14:07:58Z 4426 4427 4428 62.5 4429 4430 4431 87.1 4432 4433 4434 4436 7.8. XML Extension 4438 The following example shows how to extend the IDMEF DTD. In the 4439 example, the VendorCo company has decided it wants to add geographic 4440 information to the Node class. To do this, VendorCo creates a 4441 Document Type Definition or DTD that defines how their class will be 4442 formatted: 4444 4449 4450 4451 Intrusion Detection Message Exchange Format (IDMEF) Extension 4452 for geographic information 4453 4454 4456 4457 4458 4460 4463 4467 4468 4471 4473 4475 4477 The VendorCo:NodeGeography class will contain the geographic data in 4478 three aggregate classes, VendorCo:latitude, VendorCo:longitude, and 4479 VendorCo:elevation. To associate the information in this class with 4480 a particular node, the "VendorCo:node-ident" attribute is provided; 4481 it must contain the same value as the "ident" attribute on the 4482 relevant Node element. 4484 To make use of this DTD now, VendorCo follows the rules in 4485 Section 5.2 and defines a parameter entity called "x-vendorco" within 4486 the Document Type Declaration, and then references this entity. In 4487 the alert, the Vendorco elements are included under the 4488 AdditionalData element, with a "type" attribute of "xml", as shown 4489 below. 4491 4493 4499 4500 4501 4502 Headquarters DMZ Network 4503 analyzer01.example.com 4504 4505 4506 4507 2000-03-09T10:01:25.93464-05:00 4508 4509 4510 4511 badguy.example.net 4512 4513 192.0.2.50 4514 255.255.255.255 4515 4516 4517 4518 4519 4520 4521 0xde796f70 4522 4523 4524 4525 4526 4527 124 4528 http://www.securityfocus.com/bid/124 4529 4530 4531 4532 4533 4537 38.89 4538 -77.02 4539 4540 4541 4542 4543 4545 8. The IDMEF Document Type Definition (Normative) 4547 4549 4561 4567 4573 4577 4582 4591 4598 4601 4605 4608 4614 4617 4622 4625 4629 4632 4636 4640 4643 4648 4651 4655 4658 4663 4666 4671 4674 4679 4682 4687 4691 4695 4698 4702 4705 4709 4713 4717 4724 4727 4732 4737 4742 4746 4751 4758 4761 4765 4768 4772 4775 4779 4787 4793 4799 4807 4810 4822 4825 4830 4833 4840 4843 4850 4853 4857 4864 4867 4872 4875 4881 4885 4893 4898 4906 4907 4912 4915 4919 4923 4927 4930 4935 4938 4943 4946 4951 4955 4963 4967 4971 4974 4980 4983 4990 4993 4997 5004 5005 5010 5011 5016 5017 5023 5024 5029 5030 5035 5036 5043 5044 5049 5056 5057 5059 5060 5062 5063 5065 5066 5068 5069 5071 5072 5074 5075 5076 5077 5079 5080 5082 5083 5085 5086 5088 5089 5091 5092 5094 5095 5097 5098 5100 5101 5103 5104 5106 5107 5109 5110 5112 5113 5115 5116 5118 5119 5121 5122 5123 5124 5126 5127 5129 5130 5132 5133 5135 5136 5138 5139 5141 5142 5144 5145 5147 5148 5150 5151 5153 5154 5156 5157 5159 5160 5162 5163 5165 5166 5168 5169 5170 5171 5173 5174 5176 5177 5179 5180 5182 5183 5185 5186 5188 5189 5191 5192 5194 5195 5197 5199 9. Security Considerations 5201 This Internet-Draft describes a data representation for exchanging 5202 security-related information between intrusion detection system 5203 implementations. Although there are no security concerns directly 5204 applicable to the format of this data, the data itself may contain 5205 security-sensitive information whose confidentiality, integrity, 5206 and/or availability may need to be protected. 5208 This suggests that the systems used to collect, transmit, process, 5209 and store this data should be protected against unauthorized use, and 5210 that the data itself should be protected against unauthorized access. 5211 The means for achieving this protection are outside the scope of this 5212 document. 5214 Section 5 of [2] describes the required and recommended security 5215 characteristics of the transmission protocol that will be used to 5216 deliver IDMEF data from analyzers to managers. These requirements 5217 include message confidentiality, message integrity, non-repudiation, 5218 and avoidance of duplicate messages. Both standard and proposed 5219 protocols exist that provide these features. 5221 Where a protocol that does not meet the requirements of Section 5 of 5222 [2] is used to exchange IDMEF messages, it may be desirable to use 5223 digital signatures to certify the integrity of these messages; this 5224 is discussed in Section 6.5 of this document. 5226 10. IANA Considerations 5228 Section 5 describes how to use the AdditionalData class to include 5229 arbitrary "atomic" data items in an IDMEF message, as well as how 5230 AdditionalData may be used to extended the DTD itself by adding new 5231 classes and attributes. 5233 From time to time, it may be desirable to move an extension from its 5234 private or local use status (as all extensions made via the above 5235 mechanism are) to "standard" status that should be supported by all 5236 implementations. 5238 This may be accomplished as described in this section. 5240 10.1. Adding Values to Existing Attributes 5242 Several of the attributes specified in this document have lists of 5243 permissible values that they may contain. To allow the addition of 5244 new values to these lists, the IANA will create a repository for 5245 attribute values called "IDMEF Attribute Values." 5247 Following the policies outlined in [9], this repository is 5248 "Specification Required" by RFC. Section 10.1.1 describes the 5249 initial values for this repository. 5251 To create a new attribute, you MUST publish an RFC to document the 5252 type. In the RFC, include a copy of the registration template found 5253 in Section 10.1.2 of this document. Put the template in your IANA 5254 Considerations section, filling in the appropriate fields. You MUST 5255 describe any interoperability and security issues in your document. 5257 When adding a new attribute value to the repository, the IANA shall 5258 assign the next rank number in numerical sequence for the value. 5260 10.1.1. Attribute Registrations 5262 IDMEF Class Name: Reference 5264 IDMEF Attribute Name: origin 5266 Registered Values: 5268 +------+-----------------+------------------------------------------+ 5269 | Rank | Keyword | Description | 5270 +------+-----------------+------------------------------------------+ 5271 | 0 | unknown | Origin of the name is not known | 5272 | | | | 5273 | 1 | vendor-specific | A vendor-specific name (and hence, URL); | 5274 | | | this can be used to provide | 5275 | | | product-specific information | 5276 | | | | 5277 | 2 | user-specific | A user-specific name (and hence, URL); | 5278 | | | this can be used to provide | 5279 | | | installation-specific information | 5280 | | | | 5281 | 3 | bugtraqid | The SecurityFocus ("Bugtraq") | 5282 | | | vulnerability database identifier | 5283 | | | (http://www.securityfocus.com/vdb) | 5284 | | | | 5285 | 4 | cve | The Common Vulnerabilities and Exposures | 5286 | | | (CVE) name (http://cve.mitre.org/) | 5287 | | | | 5288 | 5 | osvdb | The Open Source Vulnerability Database | 5289 | | | (http://www.osvdb.org) | 5290 +------+-----------------+------------------------------------------+ 5292 IDMEF Class Name: Source 5294 IDMEF Attribute Name: spoofed 5296 Registered Values: 5298 +------+---------+----------------------------------------+ 5299 | Rank | Keyword | Description | 5300 +------+---------+----------------------------------------+ 5301 | 0 | unknown | Accuracy of source information unknown | 5302 | | | | 5303 | 1 | yes | Source is believed to be a decoy | 5304 | | | | 5305 | 2 | no | Source is believed to be "real" | 5306 +------+---------+----------------------------------------+ 5308 IDMEF Class Name: Target 5310 IDMEF Attribute Name: decoy 5312 Registered Values: 5314 +------+---------+----------------------------------------+ 5315 | Rank | Keyword | Description | 5316 +------+---------+----------------------------------------+ 5317 | 0 | unknown | Accuracy of target information unknown | 5318 | | | | 5319 | 1 | yes | Target is believed to be a decoy | 5320 | | | | 5321 | 2 | no | Target is believed to be "real" | 5322 +------+---------+----------------------------------------+ 5324 IDMEF Class Name: AdditionalData 5326 IDMEF Attribute Name: type 5328 Registered Values: 5330 +------+-------------+----------------------------------------------+ 5331 | Rank | Keyword | Description | 5332 +------+-------------+----------------------------------------------+ 5333 | 0 | boolean | The element contains a boolean value, i.e., | 5334 | | | the strings "true" or "false" | 5335 | | | | 5336 | 1 | byte | The element content is a single 8-bit byte | 5337 | | | (see Section 3.2.4) | 5338 | | | | 5339 | 2 | character | The element content is a single character | 5340 | | | (see Section 3.2.3) | 5341 | | | | 5342 | 3 | date-time | The element content is a date-time string | 5343 | | | (see Section 3.2.6) | 5344 | | | | 5345 | 4 | integer | The element content is an integer (see | 5346 | | | Section 3.2.1) | 5347 | | | | 5348 | 5 | ntpstamp | The element content is an NTP timestamp (see | 5349 | | | Section 3.2.7) | 5350 | | | | 5351 | 6 | portlist | The element content is a list of ports (see | 5352 | | | Section 3.2.8) | 5353 | | | | 5354 | 7 | real | The element content is a real number (see | 5355 | | | Section 3.2.2) | 5356 | | | | 5357 | 8 | string | The element content is a string (see | 5358 | | | Section 3.2.3) | 5359 | | | | 5360 | 9 | byte-string | The element content is a byte[] (see | 5361 | | | Section 3.2.4) | 5362 | 10 | xml | The element content is XML-tagged data (see | 5363 | | | Section 5.2) | 5364 +------+-------------+----------------------------------------------+ 5366 IDMEF Class Name: Impact 5368 IDMEF Attribute Name: severity 5370 Registered Values: 5372 +------+---------+-----------------+ 5373 | Rank | Keyword | Description | 5374 +------+---------+-----------------+ 5375 | 0 | low | Low severity | 5376 | | | | 5377 | 1 | medium | Medium severity | 5378 | | | | 5379 | 2 | high | High severity | 5380 +------+---------+-----------------+ 5382 IDMEF Class Name: Impact 5384 IDMEF Attribute Name: completion 5386 Registered Values: 5388 +------+-----------+--------------------------------+ 5389 | Rank | Keyword | Description | 5390 +------+-----------+--------------------------------+ 5391 | 0 | failed | The attempt was not successful | 5392 | | | | 5393 | 1 | succeeded | The attempt succeeded | 5394 +------+-----------+--------------------------------+ 5396 IDMEF Class Name: Impact 5398 IDMEF Attribute Name: type 5400 Registered Values: 5402 +------+---------+--------------------------------------------------+ 5403 | Rank | Keyword | Description | 5404 +------+---------+--------------------------------------------------+ 5405 | 0 | admin | Administrative privileges were attempted or | 5406 | | | obtained | 5407 | | | | 5408 | 1 | dos | A denial of service was attempted or completed | 5409 | | | | 5410 | 2 | file | An action on a file was attempted or completed | 5411 | | | | 5412 | 3 | recon | A reconnaissance probe was attempted or | 5413 | | | completed | 5414 | | | | 5415 | 4 | user | User privileges were attempted or obtained | 5416 | | | | 5417 | 5 | other | Anything not in one of the above categories | 5418 +------+---------+--------------------------------------------------+ 5420 IDMEF Class Name: Action 5422 IDMEF Attribute Name: category 5424 Registered Values: 5426 +------+-------------------+----------------------------------------+ 5427 | Rank | Keyword | Description | 5428 +------+-------------------+----------------------------------------+ 5429 | 0 | block-installed | A block of some sort was installed to | 5430 | | | prevent an attack from reaching its | 5431 | | | destination. The block could be a | 5432 | | | port block, address block, etc., or | 5433 | | | disabling a user account. | 5434 | | | | 5435 | 1 | notification-sent | A notification message of some sort | 5436 | | | was sent out-of-band (via pager, | 5437 | | | e-mail, etc.). Does not include the | 5438 | | | transmission of this alert. | 5439 | | | | 5440 | 2 | taken-offline | A system, computer, or user was taken | 5441 | | | offline, as when the computer is shut | 5442 | | | down or a user is logged off. | 5443 | | | | 5444 | 3 | other | Anything not in one of the above | 5445 | | | categories. | 5446 +------+-------------------+----------------------------------------+ 5447 IDMEF Class Name: Confidence 5449 IDMEF Attribute Name: rating 5451 Registered Values: 5453 +------+---------+--------------------------------------------------+ 5454 | Rank | Keyword | Description | 5455 +------+---------+--------------------------------------------------+ 5456 | 0 | low | The analyzer has little confidence in its | 5457 | | | validity | 5458 | | | | 5459 | 1 | medium | The analyzer has average confidence in its | 5460 | | | validity | 5461 | | | | 5462 | 2 | high | The analyzer has high confidence in its validity | 5463 | | | | 5464 | 3 | numeric | The analyzer has provided a posterior | 5465 | | | probability value indicating its confidence in | 5466 | | | its validity | 5467 +------+---------+--------------------------------------------------+ 5469 IDMEF Class Name: Node 5471 IDMEF Attribute Name: category 5473 Registered Values: 5475 +------+----------+------------------------------------------+ 5476 | Rank | Keyword | Description | 5477 +------+----------+------------------------------------------+ 5478 | 0 | unknown | Domain unknown or not relevant | 5479 | | | | 5480 | 1 | ads | Windows 2000 Advanced Directory Services | 5481 | | | | 5482 | 2 | afs | Andrew File System (Transarc) | 5483 | | | | 5484 | 3 | coda | Coda Distributed File System | 5485 | | | | 5486 | 4 | dfs | Distributed File System (IBM) | 5487 | | | | 5488 | 5 | dns | Domain Name System | 5489 | | | | 5490 | 6 | hosts | Local hosts file | 5491 | | | | 5492 | 7 | kerberos | Kerberos realm | 5493 | | | | 5494 | 8 | nds | Novell Directory Services | 5495 | | | | 5496 | 9 | nis | Network Information Services (Sun) | 5497 | | | | 5498 | 10 | nisplus | Network Information Services Plus (Sun) | 5499 | | | | 5500 | 11 | nt | Windows NT domain | 5501 | | | | 5502 | 12 | wfw | Windows for Workgroups | 5503 +------+----------+------------------------------------------+ 5505 IDMEF Class Name: Address 5507 IDMEF Attribute Name: category 5509 Registered Values: 5511 +------+---------------+--------------------------------------------+ 5512 | Rank | Keyword | Description | 5513 +------+---------------+--------------------------------------------+ 5514 | 0 | unknown | Address type unknown | 5515 | | | | 5516 | 1 | atm | Asynchronous Transfer Mode network address | 5517 | | | | 5518 | 2 | e-mail | Electronic mail address (RFC 822) | 5519 | | | | 5520 | 3 | lotus-notes | Lotus Notes e-mail address | 5521 | | | | 5522 | 4 | mac | Media Access Control (MAC) address | 5523 | | | | 5524 | 5 | sna | IBM Shared Network Architecture (SNA) | 5525 | | | address | 5526 | | | | 5527 | 6 | vm | IBM VM ("PROFS") e-mail address | 5528 | | | | 5529 | 7 | ipv4-addr | IPv4 host address in dotted-decimal | 5530 | | | notation (a.b.c.d) | 5531 | | | | 5532 | 8 | ipv4-addr-hex | IPv4 host address in hexadecimal notation | 5533 | | | | 5534 | 9 | ipv4-net | IPv4 network address in dotted-decimal | 5535 | | | notation, slash, significant bits | 5536 | | | (a.b.c.d/nn) | 5537 | | | | 5538 | 10 | ipv4-net-mask | IPv4 network address in dotted-decimal | 5539 | | | notation, slash, network mask in | 5540 | | | dotted-decimal notation (a.b.c.d/w.x.y.z) | 5541 | | | | 5542 | 11 | ipv6-addr | IPv6 host address | 5543 | | | | 5544 | 12 | ipv6-addr-hex | IPv6 host address in hexadecimal notation | 5545 | | | | 5546 | 13 | ipv6-net | IPv6 network address, slash, significant | 5547 | | | bits | 5548 | | | | 5549 | 14 | ipv6-net-mask | IPv6 network address, slash, network mask | 5550 +------+---------------+--------------------------------------------+ 5552 IDMEF Class Name: User 5554 IDMEF Attribute Name: category 5555 Registered Values: 5557 +------+-------------+------------------------------------+ 5558 | Rank | Keyword | Description | 5559 +------+-------------+------------------------------------+ 5560 | 0 | unknown | User type unknown | 5561 | | | | 5562 | 1 | application | An application user | 5563 | | | | 5564 | 2 | os-device | An operating system or device user | 5565 +------+-------------+------------------------------------+ 5567 IDMEF Class Name: UserId 5569 IDMEF Attribute Name: category 5571 Registered Values: 5573 +------+---------------+--------------------------------------------+ 5574 | Rank | Keyword | Description | 5575 +------+---------------+--------------------------------------------+ 5576 | 0 | current-user | The current user id being used by the user | 5577 | | | or process. On Unix systems, this would | 5578 | | | be the "real" user id, in general. | 5579 | | | | 5580 | 1 | original-user | The actual identity of the user or process | 5581 | | | being reported on. On those systems that | 5582 | | | (a) do some type of auditing and (b) | 5583 | | | support extracting a user id from the | 5584 | | | "audit id" token, that value should be | 5585 | | | used. On those systems that do not | 5586 | | | support this, and where the user has | 5587 | | | logged into the system, the "login id" | 5588 | | | should be used. | 5589 | | | | 5590 | 2 | target-user | The user id the user or process is | 5591 | | | attempting to become. This would apply, | 5592 | | | on Unix systems for example, when the user | 5593 | | | attempts to use "su," "rlogin," "telnet," | 5594 | | | etc. | 5595 | | | | 5596 | 3 | user-privs | Another user id the user or process has | 5597 | | | the ability to use, or a user id | 5598 | | | associated with a file permission. On | 5599 | | | Unix systems, this would be the | 5600 | | | "effective" user id in a user or process | 5601 | | | context, and the owner permissions in a | 5602 | | | file context. Multiple UserId elements of | 5603 | | | this type may be used to specify a list of | 5604 | | | privileges. | 5605 | | | | 5606 | 4 | current-group | The current group id (if applicable) being | 5607 | | | used by the user or process. On Unix | 5608 | | | systems, this would be the "real" group | 5609 | | | id, in general. | 5610 | | | | 5611 | 5 | group-privs | Another group id the group or process has | 5612 | | | the ability to use, or a group id | 5613 | | | associated with a file permission. On | 5614 | | | Unix systems, this would be the | 5615 | | | "effective" group id in a group or process | 5616 | | | context, and the group permissions in a | 5617 | | | file context. On BSD-derived Unix | 5618 | | | systems, multiple UserId elements of this | 5619 | | | type would be used to include all the | 5620 | | | group ids on the "group list." | 5621 | | | | 5622 | 6 | other-privs | Not used in a user, group, or process | 5623 | | | context, only used in the file context. | 5624 | | | The file permissions assigned to users who | 5625 | | | do not match either the user or group | 5626 | | | permissions on the file. On Unix systems, | 5627 | | | this would be the "world" permissions. | 5628 +------+---------------+--------------------------------------------+ 5630 IDMEF Class Name: File 5632 IDMEF Attribute Name: category 5634 Registered Values: 5636 +------+----------+-------------------------------------------------+ 5637 | Rank | Keyword | Description | 5638 +------+----------+-------------------------------------------------+ 5639 | 0 | current | The file information is from after the reported | 5640 | | | change | 5641 | | | | 5642 | 1 | original | The file information is from before the | 5643 | | | reported change | 5644 +------+----------+-------------------------------------------------+ 5646 IDMEF Class Name: File 5648 IDMEF Attribute Name: fstype 5650 Registered Values: 5652 +------+---------+-------------------------------------+ 5653 | Rank | Keyword | Description | 5654 +------+---------+-------------------------------------+ 5655 | 0 | ufs | Berkeley UNIX Fast File System | 5656 | | | | 5657 | 1 | efs | Linux "efs" file system | 5658 | | | | 5659 | 2 | nfs | Network File System | 5660 | | | | 5661 | 3 | afs | Andrew File System | 5662 | | | | 5663 | 4 | ntfs | Windows NT File System | 5664 | | | | 5665 | 5 | fat16 | 16-bit Windows FAT File System | 5666 | | | | 5667 | 6 | fat32 | 32-bit Windows FAT File System | 5668 | | | | 5669 | 7 | pcfs | "PC" (MS-DOS) file system on CD-ROM | 5670 | | | | 5671 | 8 | joliet | Joliet CD-ROM file system | 5672 | | | | 5673 | 9 | iso9660 | ISO 9660 CD-ROM file system | 5674 +------+---------+-------------------------------------+ 5676 IDMEF Class Name: FileAccess 5678 IDMEF Attribute Name: permission 5680 Registered Values: 5682 +------+-------------------+----------------------------------------+ 5683 | Rank | Keyword | Description | 5684 +------+-------------------+----------------------------------------+ 5685 | 0 | noAccess | No access at all is allowed for this | 5686 | | | user | 5687 | | | | 5688 | 1 | read | This user has read access to the file | 5689 | | | | 5690 | 2 | write | This user has write access to the file | 5691 | | | | 5692 | 3 | execute | This user has the ability to execute | 5693 | | | the file | 5694 | | | | 5695 | 4 | search | This user has the ability to search | 5696 | | | this file (applies to "execute" | 5697 | | | permission on directories in UNIX) | 5698 | | | | 5699 | 5 | delete | This user has the ability to delete | 5700 | | | this file | 5701 | | | | 5702 | 6 | executeAs | This user has the ability to execute | 5703 | | | this file as another user | 5704 | | | | 5705 | 7 | changePermissions | This user has the ability to change | 5706 | | | the access permissions on this file | 5707 | | | | 5708 | 8 | takeOwnership | This user has the ability to take | 5709 | | | ownership of this file | 5710 +------+-------------------+----------------------------------------+ 5712 IDMEF Class Name: Linkage 5714 IDMEF Attribute Name: category 5716 Registered Values: 5718 +------+---------------+--------------------------------------------+ 5719 | Rank | Keyword | Description | 5720 +------+---------------+--------------------------------------------+ 5721 | 0 | hard-link | The element represents another name | 5722 | | | for this file. This information may be | 5723 | | | more easily obtainable on NTFS file | 5724 | | | systems than others. | 5725 | | | | 5726 | 1 | mount-point | An alias for the directory specified by | 5727 | | | the parent's and elements. | 5728 | | | | 5729 | 2 | reparse-point | Applies only to Windows; excludes symbolic | 5730 | | | links and mount points, which are specific | 5731 | | | types of reparse points. | 5732 | | | | 5733 | 3 | shortcut | The file represented by a Windows | 5734 | | | "shortcut." A shortcut is distinguished | 5735 | | | from a symbolic link because of the | 5736 | | | difference in their contents, which may be | 5737 | | | of importance to the manager. | 5738 | | | | 5739 | 4 | stream | An Alternate Data Stream (ADS) in Windows; | 5740 | | | a fork on MacOS. Separate file system | 5741 | | | entity that is considered an extension of | 5742 | | | the main . | 5743 | | | | 5744 | 5 | symbolic-link | The element represents the file to | 5745 | | | which the link points. | 5746 +------+---------------+--------------------------------------------+ 5748 IDMEF Class Name: Checksum 5750 IDMEF Attribute Name: algorithm 5752 Registered Values: 5754 +------+----------+------------------------------------------+ 5755 | Rank | Keyword | Description | 5756 +------+----------+------------------------------------------+ 5757 | 0 | MD4 | The MD4 algorithm. | 5758 | | | | 5759 | 1 | MD5 | The MD5 algorithm. | 5760 | | | | 5761 | 2 | SHA1 | The SHA1 algorithm. | 5762 | | | | 5763 | 3 | SHA2-256 | The SHA2 algorithm with 256 bits length. | 5764 | | | | 5765 | 4 | SHA2-384 | The SHA2 algorithm with 384 bits length. | 5766 | | | | 5767 | 5 | SHA2-512 | The SHA2 algorithm with 512 bits length. | 5768 | | | | 5769 | 6 | CRC-32 | The CRC algorithm with 32 bits length. | 5770 | | | | 5771 | 7 | Haval | The Haval algorithm. | 5772 | | | | 5773 | 8 | Tiger | The Tiger algorithm. | 5774 | | | | 5775 | 9 | Gost | The Gost algorithm. | 5776 +------+----------+------------------------------------------+ 5778 10.1.2. Registration Template 5780 IDMEF Class Name: 5782 5785 IDMEF Attribute Name: 5787 5790 New Attribute Value to be Defined: 5792 5795 Meaning of New Attribute Value: 5797 5801 Contact Person and E-Mail Address: 5803 5805 10.2. Adding New Attributes and Classes 5807 To the extent possible, the IDMEF classes and attributes specified in 5808 this document have been designed to accomodate all current and near- 5809 future needs. Although it is recognized that the addition of new 5810 classes, as well as the addition of new attributes to existing 5811 classes, will be necessary in the future, these actions should not be 5812 taken lightly. 5814 Any addition of new attributes or classes should only be undertaken 5815 when the current classes and attributes simply cannot be used to 5816 represent the information in a "clean" way -- and such additions 5817 should only be made to represent generally-useful types of data. 5818 Vendor-specific information, obscure information provided by only a 5819 particular type of analyzer or used only by a particular type of 5820 manager, "pet" attributes, and the like are not good reasons to make 5821 class and attribute additions. 5823 At the time this RFC was written, the first anticipated case for 5824 which new classes and attributes will need to be added is to handle 5825 host-based intrusion detection systems. However, such additions 5826 should not be made until some level of consensus has been reached 5827 about the set of data that will be provided by these systems. 5829 Following the policies outlined in [9], the addition of new classes 5830 and attributes to the IDMEF requires "IETF Consensus." 5832 To add new attributes or classes, you MUST publish an RFC to document 5833 them, and get that RFC approved by the IESG. Typically, the IESG 5834 will seek input on prospective additions from appropriate persons 5835 (e.g., a relevant Working Group if one exists). You MUST describe 5836 any interoperability and security issues in your document. 5838 11. References 5840 11.1. Normative References 5842 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 5843 Levels", BCP 14, RFC 2119, March 1997. 5845 [2] Wood, M. and M. Erlinger, "Intrusion Detection Mesage Exchange 5846 Requirements", draft-ietf-idwg-requirements-10 (work in 5847 progress), October 2002. 5849 [3] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, 5850 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 5851 FirstEdition REC-xml-20001006, October 2000. 5853 [4] Hollander, D., Bray, T., and A. Layman, "Namespaces in XML", 5854 W3C REC REC-xml-names-19990114, January 1999. 5856 [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 5857 Resource Identifiers (URI): Generic Syntax", RFC 2396, 5858 August 1998. 5860 [6] International Organization for Standardization, "Data elements 5861 and interchange formats - Information interchange - 5862 Representation of dates and times", ISO Standard 8601, Second 5863 Edition, December 2000. 5865 [7] Mills, D., "Network Time Protocol (Version 3) Specification, 5866 Implementation", RFC 1305, March 1992. 5868 [8] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for 5869 IPv4, IPv6 and OSI", RFC 2030, October 1996. 5871 [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 5872 Considerations Section in RFCs", BCP 26, RFC 2434, 5873 October 1998. 5875 [10] Alvestrand, H., "Tags for the Identification of Languages", 5876 BCP 47, RFC 3066, January 2001. 5878 11.2. Informational References 5880 [11] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 5881 Language) XML-Signature Syntax and Processing", RFC 3275, 5882 March 2002. 5884 [12] Rumbaugh, J., Jacobson, I., and G. Booch, "The Unified Modeling 5885 Language Reference Model", ISBN 020130998X, 1998. 5887 [13] Freed, N. and J. Postel, "IANA Charset Registration 5888 Procedures", BCP 19, RFC 2278, January 1998. 5890 [14] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture 5891 for Describing Simple Network Management Protocol (SNMP) 5892 Management Frameworks", STD 62, RFC 3411, December 2002. 5894 [15] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence 5895 between Version 1, Version 2, and Version 3 of the Internet- 5896 standard Network Management Framework", BCP 74, RFC 3584, 5897 August 2003. 5899 Appendix A. History of Significant Changes 5901 The RFC Editor should remove this section and its corresponding TOC 5902 references prior to publication. 5904 A.1. Things to do before publication 5906 Remove this section. 5908 A.2. Response to IESG comments 5910 A.2.1. Comment on Section 3.1.3 5912 A.2.1.1. Comment 5914 I'm not sure that this is a good thing to say: "If no language is 5915 specified for an IDMEF message, English SHALL be assumed." (RFC1766 5916 --and 3066?-- has some words about i-default) 5918 A.2.1.2. Response 5920 Changed "IDMEF-compliant applications SHOULD" to "IDMEF-compliant 5921 applications MUST" and drop the 2 other paragraphs in the section. 5923 A.2.2. Comment on Section A.3.4 5925 A.2.2.1. Comment 5927 "As a note of interest, XML Schemas, currently being developed by the 5928 W3C, will provide support for inheritance, as well as stronger data 5929 typing and other useful features. Future versions of the IDMEF will 5930 probably use XML Schemas instead of DTDs; this is not currently 5931 possible because the XML Schema Recommendation has not been 5932 finalized." 5934 How *old* is this document? XML schema was approved as a W3C > 5935 Recommendation (approximately their equivalent to IETF full standard) 5936 > over 18 months ago -- http://www.w3.org/XML/Schema 5938 A.2.2.2. Response 5940 The paragraph has been dropped and the document includes an XML 5941 schema equivalent to the DTD. The normative reference is now the 5942 schema. 5944 A.2.3. Comment on Section 3.2 5945 A.2.3.1. Comment 5947 Data typing should make reference to XML schema datatypes [2]. Even 5948 > among those who promote alternatives to XML schema, most folks use 5949 the XML schema datatypes as defined. [2] 5950 http://www.w3.org/TR/xmlschema-2/ 5952 A.2.3.2. Response 5954 This has been realized with the creation of the schema. 5956 A.2.3.3. Comment 5958 Also, the number notations are muddling encoding issues with 5959 presentation issues (cf. use of '.' and ',' in numbers). 5961 A.2.3.4. Response 5963 I do not think this is the case. We're trying to solve the EU/US 5964 input problem, not pretty-print. 5966 A.2.4. Comment on section 3.2.4 5968 A.2.4.1. Comment 5970 My earlier comment was this: "Using XML character references to 5971 encode binary data seems seriously broken to me. Character 5972 references in XML denote Unicode code points, *not* byte values. I 5973 suggest looking to the XML encryption work for ways to encode binary 5974 data in XML." Now I haven't a clue what this document is 5975 specifiying. There is a reference to a BYTE datatype, but no 5976 description I can see of how it is encoded in XML. 5978 A.2.4.2. Response 5980 The comment is right. This has been changed to base64 encoding, 5981 reflecting current practice. 5983 A.2.5. Comment on 3.2.5 Enumerated Types 5985 A.2.5.1. Comment 5987 "Enumerated types are represented by the ENUM data type, and consist 5988 of an ordered list of acceptable values. Each value has a rank 5989 (number) and a representing keyword. Within IDMEF XML messages, the 5990 enumerated type keywords are used as attribute values, and the ranks 5991 are ignored. However, those IDMEF-compliant applications that choose 5992 to represent these values internally in a numeric format MUST use the 5993 rank values identified in this memo." What right has a spec of this 5994 type to tell an application to do internally? 5996 A.2.5.2. Response 5998 Paragraph dropped, replaced by: 6000 Enumerated types are represented by the ENUM data type, and consist 6001 of an ordered list of acceptable values. 6003 A.2.6. Comment on Section 4.* 6005 A.2.6.1. Comment 6007 I think the UML-based data modelling could usefully be separated from 6008 XML DTD definitions; I'd go far as to suggest the UML data model 6009 should be a separate document in its own right. This would serve to 6010 separate the essential data design from its representation in XML. 6012 A.2.6.2. Response 6014 There is a WG concensus for having one draft. There were two before, 6015 and it was decided to merge them to ensure that there would not be 6016 any divergence between the model and the normative spec (DTD or 6017 schema). 6019 A.2.6.3. Comment 6021 This part contains a number of enumerated string values. It seems to 6022 me that these could more usefully be assigned URIs (maybe, URNs). 6023 Using XML namespaces, these could then become element names, with all 6024 but the last part of the URI being the namespace URI. I think this 6025 would better support the claimed requirement (section 2.1.1) for easy 6026 extensibility. 6028 A.2.6.4. Response 6030 The schema does this. 6032 A.2.7. Comment on Section 5 6034 Section 5 is now section 6 because of the addition of the schema. 6036 A.2.7.1. Comment 6038 I'm uneasy about the approach to extensibility, particularly DTD 6039 extensions. For an Internet standard it feels rather fragile, 6040 depending on things like XML parameter-entity references within a 6041 DTD-declaration. This is a gut feel, which I cannot substantiate. 6043 A.2.7.2. Response 6045 As far as I can tell, this only impacts 6.2. Including XML in the 6046 additionaldata structure is correct, at least in the schema. 6048 A.2.7.3. Comment 6050 I could not find a definition of the namespace URI. 6052 A.2.7.4. Response 6054 It is now on both the schema and the DTD. The schema is clearly 6055 better in defining this. 6057 A.2.7.5. Comment 6059 Section 2.2.1 claims that IDMEF elements will be in an XML namespace, 6060 but the examples given have no namespace declaration, so the elements 6061 used there are not namespace qualified. I think the use of a 6062 namespace is correct. A simple fix is to use a default namespace 6063 declaration in the examples. 6065 A.2.7.6. Response 6067 The namespace has been added to the examples. 6069 A.2.8. Comment on Section 7.8 6071 A.2.8.1. Comment 6073 The example contains what I think is an incorrect attempt to use XML 6074 namespace prefix 'VendorCo:'. Specifically, there is no xmlns: 6075 VendorCo declaration in the XML data. I don't think the attempt to 6076 define the namespace in the DTD is valid ... or if it is, I don't 6077 think it's advisable, because it means the namespace cannot be 6078 identified without access to the DTD. (I'm not certain about this, 6079 and think it should be run by an XML expert.) 6081 A.2.8.2. Response 6083 After verification with an XML expert, and according to the XML 6084 documents on w3c.org, this is - at least for the schema - the correct 6085 procedure for including XML in an IDMEF message. 6087 A.3. Significant Changes Since idmef-10 6089 [BF] Converted memo to RFC2629-compliant XML. 6091 [BF] Added Appendix A. 6093 [HD] Changed examples to have diverse urls. 6095 [HD] Changed Dave Curry contact info. 6097 [HD] Altered language setting. 6099 [HD] Simplified enumerated types. 6101 [HD] Added name attribute to analyzer. 6103 [HD] Changed ident in Alert and Heartbeat to messageid and added 6104 description in "Unique Identifiers" section, because we really mean 6105 something different than the ident in the other classes. 6107 [HD] Made fstype an optional attribute rather than a required one, 6108 because it's difficult to get to in some situations, and it's not 6109 provided by many systems. 6111 [HD] Added checksum class. 6113 [HD] Cleaned & errors in document. 6115 [HD] Important change to transform the classification class as 6116 Classification-Reference (carrying the former classification 6117 information). 6119 [HD] Added recursive path to the analyzer. 6121 [HD] Completed recursive path to the analyzer. 6123 [HD] Specified better definition for additionaldata.meaning - this 6124 may be temporary pending the definition of a list of meaning 6125 keywords. The encoding keyword has not been added. 6127 [HD] Added IANA number/name for service class. 6129 [HD] Added info to low/medium/high severity. 6131 [HD] Reference new XML digital sigs standard. 6133 [HD] Changed IANA STRING -> INTEGER 6135 [HD] Reformat 6137 [HD] Suppressed FileList 6139 [HD] Added Heartbeat.Heartbeatinterval 6141 [HD] Added byte-string of xsd:hexBinary 6143 [HD] Added file-type attribute 6145 [HD] Corrected Hybrid IDS project 6147 [HD] Reformat the document 6149 [HD] Corrected choice imbrication in service class in schema 6151 [HD] Reworded definition of spoofed in source class 6153 [HD] Homogenous representation of additionaldata between dtd and 6154 schema 6156 [HD] Corrected missing analyzer name in schema 6158 [HD] Corrected missing analyzer recursion in schema 6160 [HD] Removed UML/XML primer, look at W3C site for documentation ! 6162 [HD] Fixed cardinality of Alert/Heartbeat in schema 6164 [HD] Cleaned extension, works properly and validates 6166 [HD] Changed SNMPService 6168 Appendix B. Acknowledgements 6170 The following individuals contributed substantially to this document 6171 and should be recognized for their efforts. This document would not 6172 exist without their help: 6174 Dominique Alessandri, IBM Corporation 6175 Spencer Allain, Teknowledge Corporation 6176 James L. Burden, California Independent Systems Operator 6177 Marc Dacier, IBM Corporation 6178 Oliver Dain, MIT Lincoln Laboratory 6179 Nicolas Delon, Prelude Hybrid IDS project 6180 David J. Donahoo, AFIWC 6181 Michael Erlinger, Harvey Mudd College 6182 Reinhard Handwerker, Internet Security Systems, Inc. 6183 Ming-Yuh Huang, The Boeing Company 6184 Joe McAlerney, Silicon Defense 6185 Cynthia McLain, MIT Lincoln Laboratory 6186 Glenn Mansfield, Cyber Solutions, Inc. 6187 Paul Osterwald, Intrusion.com 6188 Jean-Philippe Pouzol, 6189 James Riordan, IBM Corporation 6190 Stephane Schitter, IBM Corporation 6191 Michael J. Slifcak, Trusted Network Technologies, Inc. 6192 Paul Sangree, Cisco Systems 6193 Michael Steiner, University of Saarland 6194 Steven R. Snapp, CyberSafe Corporation 6195 Stuart Staniford-Chen, Silicon Defense 6196 Maureen Stillman, Nokia IP Telephony 6197 Yoann Vandoorselaere, Prelude Hybrid IDS project 6198 Vimal Vaidya, AXENT 6199 Andy Walther, Harvey Mudd College 6200 Andreas Wespi, IBM Corporation 6201 John C. C. White, MITRE 6202 Eric D. Williams, Information Brokers, Inc. 6203 S. Felix Wu, University of California Davis 6205 Appendix C. The IDMEF Schema Definition (Non-normative) 6207 6208 6213 6214 6215 Intrusion Detection Message Exchange Format (IDMEF) Version 1.0 6216 6217 6219 6220 6223 6225 6228 6229 6230 6231 6232 6233 6234 6235 6237 6240 6241 6242 6243 6244 6245 6246 6247 6248 6249 6250 6251 6252 6253 6254 6255 6256 6257 6258 6260 6263 6264 6265 6266 6267 6268 6269 6270 6272 6275 6276 6277 6278 6279 6280 6282 6285 6286 6287 6288 6289 6290 6291 6292 6293 6294 6296 6299 6300 6301 6302 6303 6304 6306 6309 6310 6311 6312 6313 6314 6315 6316 6317 6318 6319 6320 6321 6323 6326 6327 6328 6329 6330 6331 6332 6333 6334 6335 6336 6338 6341 6342 6343 6344 6345 6346 6347 6348 6350 6351 6353 6356 6357 6358 6359 6360 6361 6362 6363 6364 6365 6366 6367 6368 6369 6371 6374 6375 6376 6377 6378 6379 6380 6381 6382 6383 6384 6385 6386 6387 6388 6389 6390 6392 6395 6396 6397 6398 6399 6400 6401 6402 6403 6404 6406 6409 6410 6411 6412 6413 6414 6415 6416 6418 6421 6422 6423 6424 6425 6426 6427 6429 6432 6433 6434 6435 6436 6437 6438 6439 6440 6441 6442 6443 6444 6445 6447 6449 6453 6454 6455 6456 6457 6458 6459 6461 6462 6463 6464 6465 6467 6468 6469 6471 6472 6473 6474 6475 6477 6478 6479 6480 6482 6485 6486 6487 6488 6489 6490 6492 6493 6495 6496 6497 6499 6501 6505 6509 6513 6517 6519 6523 6524 6526 6528 6530 6531 6535 6536 6539 6540 6542 6543 6544 6545 6547 6551 6555 6559 6560 6563 6565 6568 6571 6572 6573 6575 6579 6580 6582 6583 6584 6586 6588 6590 6591 6593 6594 6595 6597 6601 6605 6606 6608 6612 6613 6614 6616 6618 6619 6620 6621 6622 6623 6624 6625 6626 6628 6630 6632 6634 6636 6638 6640 6642 6643 6645 6647 6649 6653 6654 6655 6659 6663 6667 6668 6671 6673 6675 6677 6679 6681 6684 6686 6688 6689 6690 6694 6698 6702 6706 6707 6710 6713 6715 6717 6718 6719 6723 6727 6731 6735 6739 6740 6743 6746 6748 6750 6753 6754 6755 6757 6761 6762 6765 6768 6770 6772 6774 6775 6776 6781 6785 6789 6790 6792 6793 6794 6796 6798 6799 6802 6804 6806 6807 6808 6812 6813 6816 6819 6821 6822 6823 6825 6827 6831 6835 6839 6843 6847 6851 6855 6859 6863 6864 6867 6870 6873 6875 6876 6877 6880 6882 6883 6884 6886 6890 6891 6893 6894 6895 6899 6900 6902 6904 6906 6907 6908 6910 6912 6913 6914 6916 6917 6918 6919 6920 6921 6922 6923 6924 6927 6929 6930 6931 6933 6937 6938 6941 6943 6944 6945 6949 6950 6952 6954 6955 6959 6960 6963 6966 6968 6969 6970 6973 6977 6981 6985 6989 6990 6993 6995 6996 6997 6998 6999 7001 7005 7006 7007 7009 7013 7014 7016 7017 7022 7026 7030 7031 7034 7036 7038 7040 7042 7043 7044 7046 7050 7054 7058 7059 7061 7062 7063 7067 7071 7075 7079 7083 7087 7091 7095 7096 7098 7099 7100 7104 7105 7108 7111 7113 7114 7115 7116 7119 7123 7124 7125 7127 7131 7132 7133 7136 7139 7141 7143 7146 7147 7148 7149 7152 7153 7154 7156 7157 7158 7159 7162 7163 7164 7166 7167 7168 7169 7172 7173 7174 7176 7177 7178 7179 7181 7183 7185 7186 7187 7189 7190 7191 7192 7194 7195 7196 7198 7199 7200 7201 7202 7206 7207 7208 7209 7211 7213 Authors' Addresses 7215 Herve Debar 7216 France Telecom R & D 7217 42 Rue des Coutures 7218 Caen 14000 7219 FR 7221 Phone: +33 2 31 75 92 61 7222 Email: herve.debar@francetelecom.com 7223 URI: http://www.francetelecom.fr/ 7225 David A. Curry 7226 Guardian Life Insurance Company of America 7227 7 Hanover Square, 24th Floor 7228 New York, NY 10004 7229 US 7231 Phone: +1 212 919-3086 7232 Email: david_a_curry@glic.com 7233 URI: http://www.glic.com/ 7235 Benjamin S. Feinstein 7236 Trusted Network Technologies, Inc. 7237 3600 Mansell Road 7238 Suite 200 7239 Alpharetta, GA 30022 7240 US 7242 Phone: +1 678 990-5345 7243 Email: bfeinstein@acm.org 7244 URI: http://www.trustednetworktech.com/ 7246 Intellectual Property Statement 7248 The IETF takes no position regarding the validity or scope of any 7249 Intellectual Property Rights or other rights that might be claimed to 7250 pertain to the implementation or use of the technology described in 7251 this document or the extent to which any license under such rights 7252 might or might not be available; nor does it represent that it has 7253 made any independent effort to identify any such rights. Information 7254 on the procedures with respect to rights in RFC documents can be 7255 found in BCP 78 and BCP 79. 7257 Copies of IPR disclosures made to the IETF Secretariat and any 7258 assurances of licenses to be made available, or the result of an 7259 attempt made to obtain a general license or permission for the use of 7260 such proprietary rights by implementers or users of this 7261 specification can be obtained from the IETF on-line IPR repository at 7262 http://www.ietf.org/ipr. 7264 The IETF invites any interested party to bring to its attention any 7265 copyrights, patents or patent applications, or other proprietary 7266 rights that may cover technology that may be required to implement 7267 this standard. Please address the information to the IETF at 7268 ietf-ipr@ietf.org. 7270 Disclaimer of Validity 7272 This document and the information contained herein are provided on an 7273 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 7274 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 7275 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 7276 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 7277 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 7278 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 7280 Copyright Statement 7282 Copyright (C) The Internet Society (2006). This document is subject 7283 to the rights, licenses and restrictions contained in BCP 78, and 7284 except as set forth therein, the authors retain all their rights. 7286 Acknowledgment 7288 Funding for the RFC Editor function is currently provided by the 7289 Internet Society.